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?

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

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.

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.

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.)

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?

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.

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

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!!

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.

@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.