Consider prohibiting author naming certain roles

[joanmarie]

At the present time, 5.2.7.4 Roles Supporting Name from Author says:

All roles support name from author with two exceptions. The roles that do not support name from author are presentation and none.

Prior to role parity, that might have been fine. But as we work on the "generic" (real name to be confirmed) role and similar roles, I question whether or not we want the author to be able to name everything (e.g. what about paragraph?).

Related: I personally don't think a div or span element which lacks an ARIA role should be able to be given a name via aria-label or aria-labelledby. But I'm pretty sure the language of the AccName spec and the HTML-AAM permit doing so. (To what avail, who knows? Screen readers might not see fit to present -- or even check for -- a name on a div or span. And if they do, I am not aware of any guidance regarding the expected presentation.)

[jnurthen]

(comments welcome - this is only my personal opinion - no group consensus is implied)

Taking the current ARIA Roles I would propose we prohibit names on the following

• blockquote
• caption
• listitem
• paragraph
• presentation (already prohibited)
• none (already prohibited)

Potentially add the following after resolving other issues

• definition (filed issue Definition description and aria-labelledby #836 ) - potentially move to prohibited list based on outcome

[carmacleod]

Agree with most, but not sure about listitem? For example, a list containing icon font characters might use aria-label (or labelledby) to give a pronounceable name to each listitem?
Of course, the author could just add a span with role "img" as a child of the listitem and put aria-label on the span, so if we prohibit names on listitems, we need an example to show how to do this.

<li>
 <span role="img" class="unpronounceable-symbol" aria-label="The Artist Formerly Known as Prince">
 </span>
</li>

[carmacleod]

Is name currently prohibited on presentation/none?

The Presentational Roles Conflict Resolution section says (twice!):

Host languages elements, having implicit presentational roles for which no roles, may be applied, MUST never be exposed to in the accessibility tree. With this exception, user agents MUST always expose global WAI-ARIA states and properties to accessibility APIs. In this case, the user agent ignores the presentation role and exposes the element according to its implicit native semantics.

and again:

User agents MUST always expose global WAI-ARIA states and properties to accessibility APIs, even if an element has an explicit or inherited role of presentation. In this case, the user agent ignores the presentation role and exposes the element according to its implicit native semantics.

(We should remove one of those paragraphs because it's redundant), however the point is that even if they are prohibited on presentation/none, aria-label, aria-labelledby and aria-describedby, being global WAI-ARIA properties, are supposed to be exposed, which puts them in some kind of grey area (not-allowed-but-used-anyhow).

[jnurthen]

Is name currently prohibited on presentation/none?

I understand I was being a little simplistic with my already prohibited comment for none/presentation. Labelling none/presentation causes ARIA to move into an author error correction case and the element falls back to its native role.

[jnurthen]

Agree with most, but not sure about listitem? For example, a list containing icon font characters might use aria-label (or labelledby) to give a pronounceable name to each listitem?
Of course, the author could just add a span with role "img" as a child of the listitem and put aria-label on the span, so if we prohibit names on listitems, we need an example to show how to do this.

<li>
 <span role="img" class="unpronounceable-symbol" aria-label="The Artist Formerly Known as Prince">
 </span>
</li>

I don't see why this is any different than for paragraph. The main issue which I see people using this to resolve is that there is no way of excluding content from ::before and ::after from the accessible name calculation even if it should be excluded. IMO if we solve this problem then we solve the majority of use cases for adding names to "blocks of text"

[carmacleod]

Right.

But more to the point of this issue, the section on Global States and Properties says:

Some states and properties are applicable to all host language elements regardless of whether a role is applied.

So maybe the easiest way to spec "prohibiting author naming certain roles" is to remove aria-label, aria-labelledby and aria-describedby from the list of global attributes, and then list them separately on all of the roles that don't prohibit their use?

That would solve the "grey-ness" of authors incorrectly giving a presentation/none a name, because in the same conflict resolution section for presentation, it is also stated (twice! :) that:

However, user agents MUST ignore any non-global, role-specific WAI-ARIA states and properties, unless it is on an inherited presentational role where an explicit role is applied.

So anything like: <ul role="presentation" aria-label="My List"> would be both prohibited and ignored, which would be more consistent/predictable (i.e. not grey).

[carmacleod]

Regarding aria-describedby specifically, can anyone think of legitimate use cases for having aria-describedby on a plain (without a role) div or span? Perhaps to add a tooltip? Or an error or warning message?

[jcsteh]

Generally, I think author naming of text containers is potentially problematic. Whether it should be prevented altogether is tricky, though.

Two edge cases come to mind.

First, take a message in some messaging app:

<div role="listitem" aria-labelledby="author message">
  <span id="author">Jamie</span>
  <span id="message">Some message <a href="#">with a link</a></span>
  <button>Reply</button>
  <button>Delete</button>
</div>

The app might provide shortcut keys to focus each message (listitem). Using screen reader as an example, it's nicer for users to just hear a short summary in this case, rather than hearing "Reply Delete" appended to the message text (which isn't useful in this context). However, we don't want authors to think this will completely override the content of the listitem; screen reader users still need to be able to access those controls.

Second, take a configuration system where font weight is used to indicate a non-default value:

<div role="table">
  <div role="row">
    <div role="cell">browser.urlbar.autoFill</div>
    <div role="cell"><b>false</b></div>
  </div>
</div>

The author needs some way to indicate to non-visual users that this is a non-default value. The intuitive approach is to use aria-label (ug):

<div role="cell" aria-label="false (user specified)">false</div>

At least with NVDA, this doesn't work as expected; see #756 (comment) to understand why. While cell isn't being considered for label prevention here, this example can be generalised to any text container; cell isn't "special" in this respect. So, if this change were made, the spec itself would prevent this from working as expected.

Personally, I tend to think we need some way of separating the idea of "label" and "content" for text containers. A listitem might have a "label" which is different from its "content" as per the first example above. It doesn't make sense for an author to set a paragraph's "label", but they may want to override its "content" as per the second example above.

[pkra]

Personally, I tend to think we need some way of separating the idea of "label" and "content" for text containers. A listitem might have a "label" which is different from its "content" as per the first example above. It doesn't make sense for an author to set a paragraph's "label", but they may want to override its "content" as per the second example above.

+1

More use cases for this can be found in SVG descriptions and equation layout, including the reverse situation where the "label" (in Jamie's sense) might need to be more than the sum of its parts - and even both more and less.

For the OP, text with PUA codepoints comes to mind as something that might need a aria-label but no role; this occurs fairly reliably in scientific content. But I'm guessing the generic role in #699 could be added to such an aria-label.

[aleventhal]

Could we:

1. In the spec, disallow names on role-less elements, so that tools spit out an error.
   and 2) Provide language in an AAM or somewhere, on what browsers should do in the error case, e.g. treat it like a role of group when there was a name but no role.

[mcking65]

Consider prohibitting naming of insertion and deletion added for issue #526.