Tentative: update point E. Host Language Label of the Acc Name algorithm

[giacomo-petri]

Closes: w3c/accname#108

This change clarifies the following:

• The term "element" in "unless the element is marked as presentational" is replaced with "current node" for clarity.
• The ambiguity regarding presentational role conflicts is removed by replacing "marked as decorative" with "exposed as decorative." Replacing this eliminates the need for additional notes, where we would need to clarify that "marked as decorative" could cause presentational role conflicts, which, for this point of the algorithm, should be resolved by ignoring the "marked as decorative" bit. Moreover, this would introduce complexity, as the statement "If exposing the explicit role causes the accessibility tree to be malformed, the expected results are undefined" adds further complications.

Should this be marked as editorial?

[netlify]

✅ Deploy Preview for wai-aria ready!

Name	Link
🔨 Latest commit	4f53d85
🔍 Latest deploy log	https://app.netlify.com/sites/wai-aria/deploys/6769518c4f490a000842dd8b
😎 Deploy Preview	https://deploy-preview-2405--wai-aria.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[giacomo-petri]

@giacomo-petri to create a wpt test

[scottaohara]

i think the examples you have in your issue / wpt are confusing me.

because with this change you're making it clear that unless the current node (so the input in your examples) is marked as presentational, then the element should be named from its attribute or element.

but your wpt puts the role=presentation on the label. I agree with the expected name/label outcomes of those examples, but per this change i would have expected the input to be the thing that was tested with role=presentation on it.... and also in that case because it's focusable, i'd expect the conflict resolution to kick in and the presentation role to be ignored.

it seems to me that the original text is more about something like:
<img alt=foo src=# role=none>
and saying that should be role=none even though there's an alt. i personally don't think that's right, since the element is named by the alt, so i would have thought that should win out... but, eh?

the inclusion of input/label here is at odds with how this text is probably expected to work for svgs / imgs.

sorry if i've completely missed the point on this. i agree there's something weird here, but i'm confused if it's being solved or not with this pr / wpt

[giacomo-petri]

Hmm...

I didn't get your point either initially...

When I raised the issue, I was specifically referring to examples such as:

<label role="presentation" for="test">First Name</label>
<input id="test" type="text">

Specs says:

Otherwise, if the current node's native markup provides an attribute (e.g. alt) or element (e.g. HTML label or SVG title) that defines a text alternative, return that alternative in the form of a flat string as defined by the host language, unless the element is marked as presentational (role="presentation" or role="none").

In this particular case, it would be

Otherwise, if the current node's (input) native markup provides an attribute (e.g. alt) or element (e.g. HTML label or SVG title) that defines a text alternative, return that alternative in the form of a flat string as defined by the host language, unless the * element * (the first ambiguity is whether it refers to the element or the original input) is marked ("marked" differs from "exposed," as "marked" indicates that the author explicitly designated the element as presentational using role="presentation" or role="none". In contrast, "exposed" takes into account presentational conflict resolution. Without this distinction, a scenario with input with role presentation would not fit with this part of the algorithm, raising the question: what is the accessible name in this case?) as presentational (role="presentation" or role="none").

But now I see what you mean.

i personally don't think that's right, since the element is named by the alt, so i would have thought that should win out... but, eh?

Honestly, I thought the opposite, that presentation takes precedence over alt. 😄

Edit: "my scenario would not fit with this part of the algorithm" replaced with "a scenario with input with role presentation would not fit with this part of the algorithm"

[scottaohara]

yeah, i agree that the switching between current node and element is awkward, since the first use of element indicates it's separate from the current node whose name is being calculated, but then the second instance of element 'could' be interpreted as the separate element or the current node...

Otherwise, if the current node's native markup provides an attribute (e.g. alt) or element (e.g. HTML label or SVG title) that defines a text alternative, return that alternative in the form of a flat string as defined by the host language, unless the element is marked as presentational (role="presentation" or role="none").

but assuming element = element and not current node, reading from the current text in a bit more of plain language:
an input (current node) is named from a label (element) then the content of the label (element) will be returned as the name for the input, unless the element (label?) is marked as presentational...

so this is why i was saying i agree with the expected labels you have in your wpt PR - because marking a label as role=presentation shouldn't impact it naming the input - under this interpretation this is a normative spec change - and it looks like unfortunately Firefox will not use a label to name an input if it's given a role=none

but with the change you made in this PR - the text would now read:

Otherwise, if the current node's native markup provides an attribute or element or SVG title that defines a text alternative, return that alternative in the form of a flat string..., unless the current node is exposed as presentational.

so to simply put it this time: if the input (current node) has a label (element) that defines its text alternative, return that alternative unless the input (current node) is exposed as presentational.

per that text, i would have expected the wpt to also contain the following, because while i think it's important to rectify the example you're calling out - the spec text is now talking specifically about this markup:

<label for=f>test</label>
<input role=none id=f>

which... doesn't really work out well, imo, for inputs - since it states something that also introduces the conflict resolution (unless the input was also made disabled / not focusable).

this revised text makes more sense (to me) if this was just about img / svg elements - but that's maybe where we disagree a bit (which i also realize might be a bit off topic...), as i think it's contradictory to say img alt=foo src=# role=none should be treated as presentational but img aria-label=foo role=none should not - they're both being inconsistently marked as presentational AND named. If someone couldn't remove the alt text for whatever reason, they should use aria-hidden to hide the image, and we shouldn't have this contradiction in how some naming mechanisms undo role=none, while some don't.

hopefully this clarifies where i'm coming from futher

[scottaohara]

imo, what would make more sense here per the original text, is if the naming items were hidden (not presentational) then they'd return no name.

so

<label hidden for=f>...</label>
<input id=f>  <!-- has no name because label is hidden -->

<svg>  <!-- is not named because title is hidden -->
  <title hidden>...</title>
</svg>

<img src=# alt=f hidden> 
<!-- is entirely hidden, so nothing to expose here -->

or, though i don't like the inconsistency, if ARIA was more explicit in saying that role=none is essentially a weird way of writing aria-hidden=true on img elements specifically, then

<img src=# alt=foo role=none> 
<!-- is also entirely hidden even though it's a presentational element that's named... -->

[giacomo-petri]

but assuming element = element and not current node, reading from the current text in a bit more of plain language:
an input (current node) is named from a label (element) then the content of the label (element) will be returned as the name for the input, unless the element (label?) is marked as presentational...

When I read this, the way the sentence is structured led me to assume the opposite, similar to how WebKit and Chromium interpreted it. However, the phrasing is ambiguous, so it also supports the opposite interpretation, which is how Gecko handled it.

so to simply put it this time: if the input (current node) has a label (element) that defines its text alternative, return that alternative unless the input (current node) is exposed as presentational.

Here’s where it gets a bit nuanced: I’ve changed the term "marked" to "exposed." Even if the input is marked as presentational, it isn’t necessarily exposed as such due to presentational role conflict resolution.

In your example:

<label for=f>test</label>
<input role=none id=f>

the input doesn’t meet the "unless" condition because it's marked as presentational but is not exposed as such. It will still retain the accessible name provided by its label. (It might be helpful to link to the presentational role conflict resolution section for further clarification and specify somehow that it's by itself a violation - but there is a fallback to manage these scenarios consistently.)

I think it’s reasonable to account for presentational role conflicts in the accessible name computation specs, so implementors can handle them consistently.

---

As for the second comment: I'm also ok with it, but implementing it would require significant changes.

[scottaohara]

Here’s where it gets a bit nuanced: I’ve changed the term "marked" to "exposed." Even if the input is marked as presentational, it isn’t necessarily exposed as such due to presentational role conflict resolution.

i get what you're saying. but again that's why i'd say the wpt should have that example in it, to demonstrate the conflict resolution at play / have the example that matches the step (role=none on current node).

and per your comment:

I think it’s reasonable to account for presentational role conflicts in the accessible name computation specs, so implementors can handle them consistently.

i think you agree?

to be super duper clear - my biggest confusion with this came from the fact the wpt PR is checking what i would have assumed to check from the prior wording. the wpt PR misses what i'd expect it to be checking from the updated spec text. I think the wpt example is good and should be tested - i'm trying to say (as well as trying to determine if we were coming to the same conclusions) that it also needs this updated example as well.

you could also put in the following in as another test, since it won't be focusable and browsers aren't all handing it the same:

<label for=t>test</label>
<input id=t disabled role=none>

chrome completely ignores the above, marking it as entirely ignored in the a11y tree.
gecko still treats it as a textbox and still gives it a name (which doesn't match the updated spec text)
webkit gives it role=none / marked as ignored. it's still named by the label, but VO can't reach the textbox - so effectively the same as chrome to the end user.

Finally, the wpt should probably also have other tests to account for other markup patterns that this applies to. such as:

• img role=none alt=foo
• svg with a <title role=none>
• <fieldset role=none><legend>foo</legend>...</fieldset> and <fieldset><legend role=none>foo</legend>...</fieldset> (similar expectations to the input test)
• table / caption, similar to the fieldset/legend test

---

As for the second comment: I'm also ok with it, but implementing it would require significant changes.

yeah... i wasn't really expecting anything to change there - more just voicing what i see as an unfortunate inconsistency.

[giacomo-petri]

Of course!

I'd be happy to include this example with and without the disabled attribute.

I'll have it added by the end of the day.

[giacomo-petri]

@scottaohara,

I'm almost done with the disabled examples, but I'm a bit unclear on the expected output for some cases.

For instance, what should be the output in terms of acc name of the following scenario?

<label for="t">test</label>
<input id="t" disabled role="none">

The input is disabled and presentational, so it doesn't trigger the presentational role and is not exposed. Given this, what should the acc name be (in terms of data-expectedlabel)? Would it still be "test"? Would it be empty? Does it matter?

This question also applies to the other examples you provided:

• img role=none alt=foo
• svg with a <title role=none>
• <fieldset role=none><legend>foo</legend>...</fieldset> and <fieldset><legend role=none>foo</legend>...</fieldset> (similar expectations to the input test)
• table / caption, similar to the fieldset/legend test

[scottaohara]

per the spec update you did, the first example input disabled role=none should have no name now - since 'current node' is exposed as presentational.

• img alt=foo role=none - i already mentioned my personal opinion on this. the reality is that this is essentially making the img aria-hidden=true. which kinda stinks if a graphic breaks or if rendering of graphics is disabled, because then the text can be seen, but it's hidden from the a11y tree....
• svg w/ title role=none would mean the svg is still named by the title. if the svg had role=none, then it'd have no name because it is exposed as presentational
• <fieldset role=none><legend>foo</legend>...</fieldset> - no name because the fieldset (current node) is exposed as presentational
• <fieldset><legend role=none>foo</legend>...</fieldset> - same as input with label role=none - the fieldset is still named even though the legend role is overwritten
• same logic applies to table/caption, per the above two points.

[giacomo-petri]

@scottaohara,

Test cases have been updated based on your recommendation and should align with what we discussed, except for the image. The image matches the PR but may not align with how you envision it should work. I'm happy to raise this with the group if we decide to make a change.

Note: since this is also impacting presentational roles conflict resolution, I've also added some check about the role.

Thanks!

[accdc]

This took me a while to untangle.

First, if the use of the word "element" is being used within the spec to indicate something specific like the starting point of the algorithm process, this is wrong and we need to change this to "root node" which is what that is meant to be. No matter how deep the current node traverses or is sent elsewhere using aria-describedby or aria-labelledby, the root node is always the top level starting point for that process. In this case that would be the input element.

If an element like an image has role="presentation"/"none" on it, I would expect that element to be removed from the accessibility tree, and then no longer available to be included within the naming computation when the current node is traversing. With the exception of course, when that element is exposed because it also has an attribute that causes the presentational role to be ignored. E.G. Any valid attribute beginning with "aria-" such as aria-label and so on.

This also seems to expose confusion about the order of precedence, such as if the AccName algorithm is parsed before or after the browser removes or updates the accessibility tree. Logically it can only be applied after the browser finishes changing the tree, which would mean that hidden or removed nodes would not be encountered by the current node traversal when computing the name.

This is just my understanding though, so if others would like to chime in please do.

We should probably talk about this during the meeting though, it seems more complicated than can be easily hashed out.

[MelSumner]

Thinking this through (mostly for myself TBH):

• "marked" is explicit author intent
• "exposed" is what browsers decide to do (and is irrespective of author's intent)

I want to make sure that we're all really clear about what changing this wording means.

[giacomo-petri]

if this is a concern (and I got your point), what about "marked by the author and exposed by UA..."

[scottaohara]

imo, simpler is better. intent vs not is probably a topic better clarified outside of an algorithm step. as then there can be nuances about whether that intent was even valid, hence why an author could mark something as presentational, but the browser is like "nope. not on that element you're not"