User agent implementation expectations for name-prohibited roles with names? (agenda)

[joanmarie]

Section 5.2.8 Accessible Name Calculation states:

prohibited: the element has no name. Authors MUST NOT use the aria-label or aria-labelledby attributes to name the element.

My questions:

Let's say an author does that (bad author!). What do we expect the user agents to do?

• Nuke the name 100% of the time?
• Expose the name 100% of the time?
• Expose the name, but only if it makes sense as a recovery step (e.g. focusable div, div with contenteditable, etc.)
• Whatever they want?
• Something else?

I ask first and foremost for CR Exit Criteria 1.2 tests: Do we even need tests for this?

But for now I'm assuming that we might want user agents to actually stop exposing the name. But then we have (at least) focusable div and div with contenteditable.

I think we can solve the div with contenteditable issue in the HTML-AAM by saying something a la contenteditable trumps the generic role.

[JAWS-test]

Related: w3c/accname#120 (comment)

[jnurthen]

https://w3c.github.io/aria/#document-handling_author-errors_states-properties states "User Agents MUST NOT expose an ARIA attribute to the platform accessibilty API when the element's computed role prohibits use of the attribute."

[joanmarie]

As I commented in w3c/html-aam#324 (comment):

Operating under the assumption that this is going to land, I'm working on making the change in Chromium. (This is independent of the name prohibition code changes btw.) Running Chromium's tests to see what broke led to me finding another thing we need to handle somewhere:

The group role does allow naming BUT from author; not from content. So some things which were generic lost their names as a consequence of becoming a group with no author-provided name. Oops!

Thoughts?

[scottaohara]

Trying to get this all sorted over in HTML AAM, and then speaking separately with @joanmarie and @jnurthen about this topic, I think we need to have a hard look at https://w3c.github.io/aria/#namecalculation - item 5

5. prohibited: the element has no name. Authors MUST NOT use the aria-label or aria-labelledby attributes to name the element.

My recollection of prohibiting the naming of generic elements was NOT to prevent UAs from being able to name an element if need be (e.g., making a generic element focusable so something can be announced). Rather, it was to stop authors from naming generic elements and the like because of the rampant inconsistency of whether such practices would expose the name as the author intended.

The second part of the prohibited item tracks with what I recall being the intent here. The first part "the element has no name." is the bit that I think is unclear/problematic. Does "the element has no name" really mean "UAs you are prevented from giving this a name" or "Authors you are prevented from giving this a name". The latter tracks with the second sentence for that item.

[joanmarie]

Thanks for writing this up @scottaohara!

I have a question for the group to consider. Let's say the intent is what we're looking to have implemented. In fact, let's pretend for a moment that we've removed "the element has no name," leaving simply "Authors MUST NOT use the aria-label or aria-labelledby attributes to name the element."

What do we expect implementors to do given <div tabindex="0" aria-label="foo">bar</div>?

The choices to me appear to be:

1. Name is ""
2. Name is "bar"
3. Name is "foo"

I think the first will be rejected by implementors on the grounds that it makes the user experience really bad: Screen reader has little/nothing to present when that div gets focus.

I think the second will likely be rejected on the grounds that it is confusing. Yeah, the author MUST NOT use aria-label, but the author did. Given that they did, does it make sense to ignore what they provided and use different fallback content?

I think the third stands a good chance of being seen as the best choice and what implementors will settle on. BUT the spec says:

https://w3c.github.io/aria/#document-handling_author-errors_states-properties states "User Agents MUST NOT expose an ARIA attribute to the platform accessibilty API when the element's computed role prohibits use of the attribute."

If I'm right about this, even if we remove the text "the element has no name" from the spec, is this ARIA 1.2 change "implementable" as written?

[jnurthen]

@aleventhal @jcsteh @cookiecrook would you reject (2) as an option? It seems the best choice to me.

[scottaohara]

if we do a focusable generic needs to be remapped to a group, then 3.
if we do not need to remap a generic because UAs will still expose something when the div is focused, then 2.

talking this out more between the convos we've had and the discussion in the HTML AAM issue, with all the adjustments to computed role that would need to be made if authors added different attributes to generic elements (or naming prohibited elements), i'm starting to think that there shouldn't be role swapping if it can be helped. long way of saying i agree with James or Aaron depending on what we decide regarding if such attributes can change the role of an element.

[joanmarie]

if we do a focusable generic needs to be remapped to a group, then 3.

Right. Because then we have a group which supports name from author, and we have an author-provided name.

if we do not need to remap a generic because UAs will still expose something when the div is focused, then 2.

Right, in terms of what the spec states, assuming we all agree that "the element has no name" doesn't actually mean "the element has no name," but instead "the element is not allowed to be named by aria-label or aria-labelledby and user agents seeking to correct this authoring error MAY expose a name based on the contents." This would be testable because we'd be simply be testing that the name isn't "foo".

I just want to be sure that:

1. The implementors agree to not expose "foo" even though it's there, and instead either expose the empty string or "bar" as the name.
2. The WG members concur that "the element has no name" doesn't actually mean "the element has no name." And that a potential lack of interoperability regarding what name is exposed is fine because the authoring is invalid.

[MelSumner]

What do we expect implementors to do given <div tabindex="0" aria-label="foo">bar</div>

I would say that implementors should ignore invalid attributes (is there a way to throw an error for the author? that would be nice.)

[aleventhal]

I think (3) makes sense because the computedRole should be "group", which allows a name.
Secondly, if we are going to have a name, accname would see that aria-label overrides name from contents.

[jnurthen]

As group doesn't allow name from Contents, wouldn't that then require a change to Accname to allow name from contents in 2F in certain cases (perhaps if the node is currently focused?) - so something could be exposed when the author hasn't supplied an accessible name?

[aleventhal]

I suppose then maybe group is not the right role to use.
Or, we can just add to one of the specs, if group was done as a repair, then name from contents is allowed.

[joanmarie]

Here is my current proposal, having worked on implementing this in Chromium (which covers all OSes and platform accessibility APIs) and also having discussions with various stakeholders:

1. We change the definition of "prohibited" under Accessible Name Calculation:
   the element has no name
   the element does not support name from author

2. We change the User Agent prohibition under Handling Author Errors, which currently states:

   User Agents MUST NOT expose an ARIA attribute to the platform accessibilty (sic) API when the element's computed role prohibits use of the attribute.

   Perhaps:

   When the element's computed role prohibits use of an ARIA attribute, User Agents MUST NOT expose that attribute to the platform accessibility APIs unless not exposing it would worsen the accessibility of that element.

3. We try to make these changes without having to exit and re-enter CR. The first change is arguably editorial. The second change is handling author errors. But if we have to exit CR and re-enter, I think that is preferable to the trump-the-generic-role via host-language properties because we don't have consensus amongst ourselves. And there may be unexpected side effects of the new role mapping that also need consideration, discussion, and resolution.

4. We continue to discuss, as a separate topic, if a tab-focusable generic object should have a different implicit role. If it should, we worry about that implementation change after ARIA 1.2 has gone to REC.

5. We continue to discuss, as a separate topic, if the presence of contenteditable on a generic object should have a different implicit role -- and what role that should be. If it should, we worry about that implementation change after ARIA 1.2 has gone to REC.

[JAWS-test]

unless not exposing it would worsen the accessibility of that element.

This is a definition with a lot of room for interpretation and should possibly be concretized

[joanmarie]

That's fair. But what's tricky is that statement appears in a very generic context, namely that user agents MUST NOT expose any prohibited ARIA attribute. There are going to be cases where user agents do expose a prohibited attribute to compensate for bad authoring, and I'm not sure we can come up with language which is concrete and covers all possible bad authoring.

That said, if you've got suggestions that will get this thing resolved, please make them here. And thank you!!

[jcsteh]

Here is my current proposal, having worked on implementing this in Chromium (which covers all OSes and platform accessibility APIs) and also having discussions with various stakeholders:

This proposal seems very sensible to me. A question, though:

   > When the element's computed role prohibits use of an ARIA attribute, User Agents MUST NOT expose that attribute to the platform  accessibility APIs unless not exposing it would worsen the accessibility of that element.

This is specific to ARIA attributes. But what about the HTML title attribute? There are cases in the wild where there is a span with a title attribute and no content, but not exposing that span would make things less accessible. Firefox was tweaked relatively recently to expose these due to breakage in the wild. (Chrome already exposed these.)

To be clear, I'm not saying this should be considered good authoring. This is about facilitating repair.

[JAWS-test]

@joanmarie

That said, if you've got suggestions that will get this thing resolved, please make them here. And thank you!!

I don't think user agents are currently able to tell when accessibility is improving or degrading with one exception: when an element gets focus and doesn't have a name. Then I would be fine with outputting a name that is in the aria-label, for example, even if the aria-label is not allowed. For all other ARIA attributes, I think that they should not be output by the user agent if they are not allowed.

However, with your example, the question would be whether it makes sense to determine the names from the aria-label or from the text content. I would only be in favor of aria-label if it is ensured that the text content then remains accessible for assistive technology, e.g. can be read with the virtual cursor of the screen reader.

[MelSumner]

+1 to change the definition of "prohibited" under Accessible Name Calculation to say "the element does not support name from author".

[joanmarie]

It turns out that the "User Agents MUST NOT ...." statement isn't in 1.2 CR; it was added to 1.3. So we still have a problem, but we no longer have an emergency. 😁 I've opened #1476 for tweaking/qualifying that normative statement.