Clarify use of aria-label on elements with no role

[jnurthen]

From https://www.w3.org/Bugs/Public/show_bug.cgi?id=28413

Developers are confused about what should happen if you put an aria-label on an element with no role, like an empty <div> element. While most browsers do interpret the aria-label and expose it, some screen readers ignore it. For example:

<div aria-label="Label">Text</div> Firefox exposes "Label" as the accName, but "Text" as the IAccessibleText, and Windows screen readers read out "Text". Safari+VoiceOver is different, VoiceOver reads out "Label".

Do you think the current Windows end-user behavior is correct, or not? Should we clarify the spec to make it crystal-clear that adding aria-label on any random element does not necessarily override that element's text, or should we change the current behavior?

Note that elements without an ARIA role can still get a label, it depends on computed role, not the ARIA role. As an example:

<h3 aria-label="ARIA Heading">Text Heading</h3> Every browser and screen reader combination I tested read out "ARIA Heading" here, not "Text Heading".

[carmacleod]

My 2c. I think aria-label[ledby] should always override, to keep things consistent and simple. By providing an aria-label, the author obviously intended it to override. If we try to "make it crystal-clear that adding aria-label on any random element does not necessarily override that element's text", then we may just end up making things muddy. :)

[devarshipant]

To add, currently:

• chrome 68 / nvda 2018 supports aria-label even on non-interactive elements.
• chrome 68 / JAWS 18 / JAWS 2018 do not fully read aria-label on non-interactive elements.

Some tests: https://codepen.io/devpant/pen/VxjEvZ

Guidance in spec on where to use aria-label would benefit those who may think aria-label is additive, which is not true, as it takes over.

Another article -- https://developer.paciellogroup.com/blog/2017/07/short-note-on-aria-label-aria-labelledby-and-aria-describedby/

[jcsteh]

I think aria-label[ledby] should always override, to keep things consistent and simple. By providing an aria-label, the author obviously intended it to override.

I wish it were this simple. I've struggled for years to get people to understand why it isn't. I've pretty much given up trying.

For simple controls such as links, buttons, check boxes, radio buttons, headings, images, tabs, etc., this makes total sense. The content of the control is generally the only dimension to consider when thinking about text. So, it makes sense for aria-label to override the content.

For text boxes, it partially makes sense, but there needs to be some clarification. There are two dimensions to consider here: the label and the value. The text of the control is actually the value, so it's not correct to say that aria-label should override the text. In this case, screen readers must report both.

For landmarks, the label must be reported in addition to the content.

For almost everything else, it's quite complicated and undefined. Let's take the rule "the label should override the content". Now let's consider a div:

<div aria-label="label">
  <h1>Heading</h1>
  <button>Button</button>
</div>

Oops. The aria-label just overrode everything inside the div, so all of that stuff is invisible to the user. Now, let's take a list item with aria-labelledby:

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

The author wanted to make the label of the list item friendlier so it didn't include "Reply". But using the rule above, screen readers would just present the label. Now they can't see the button. Also, text alternative computation flattens the text, so the semantics of the link are lost; the user can no longer activate the link. They also can't see the formatting of the text, since again, it's flattened into plain text.

I can't emphasise this enough: accessibility is more than just labels, descriptions, roles and states. There are values, formatting and descendants with semantics.

Just to make things messier, you've also got websites in the wild like GitHub doing ridiculously silly stuff like this:

    <span class="timeline-comment-label tooltipped tooltipped-multiline tooltipped-s" aria-label="This user has previously committed to the nvda repository.">
      Contributor
    </span>

Awesome. As a user, I now get spammed with that verbose text instead of just "Contributor". Authoring error? Almost certainly. Do we want the spec to break the web? No.

For more background, see my blog post: Woe-ARIA: The Surprisingly but Ridiculously Complicated World of aria-label/ledby.

[jcsteh]

* chrome 68 / nvda 2018 supports aria-label even on non-interactive elements.

This is incorrect. It does report aria-label on headings as your test shows, since headings have only a single dimension of possible content. However, it doesn't report it on a plain div or span, for example:

<div aria-label="label">Text</div>

NVDA will just say "text" in that case. See the examples in my previous comment to understand why.

[jnurthen]

@jcsteh I would love your comments on https://github.com/w3c/aria/issues/833

[jcsteh]

NVDA added support for reporting aria-label on divs, spans, etc. in nvaccess/nvda#8886. It was reverted soon after in nvaccess/nvda#8899 because it caused all sorts of pain in the wild. And that was with the label being reported preceding the content, not overriding the content. If it had overridden the content, it would have broken users even more.

[jongund]

aria-label and aria-labelledby should only be used on elements and roles that can have labels. I don't think they should be used to change the text content of other elements and roles that do not require a label due to the issues raised by James Teh. There are other was to achieve what people want to do with aria-label and the ARIA Authoring Practices should demonstrate those techniques.

[prlbr]

Do I understand correctly that https://www.w3.org/TR/WCAG20-TECHS/ARIA6.html does not work in practice and it is better to leave aria-label away in the dicussed cases?

[DavidMacDonald]

I very much appreciate explanation of choices for NVDA from @jcsteh. I have a testing page of many roles and no roles with aria-label, aria-labelledby, (Accessible Name) and aria-describedby (Accessible Description).

I definitely think we have to write some guidance and have discussions with screen reader manufacturers and see if we can come to a unified approach.

PS @prlbr Labels are OK on div elements IF they have role=navigation, search, main, img.

This is related to #815

[DavidMacDonald]

aria-label and aria-labelledby should only be used on elements and roles that can have labels. I don't think they should be used to change the text content of other elements and roles that do not require a label due to the issues raised by James Teh.

@jongund Should we try to put together a list? Currently, they apply to a "user interface element" but we have no definition of that in ARIA, HTML, WCAG, or elsewhere, which is issue #815

[Siemenskun]

As a web developer, I expect to override all text content in elements by an aria-label on an element if

1. The node has not any child or
2. All children of the node are text nodes.

It allows to drop awkward CSS class .screen-reader-text in some cases:

<span aria-label="Hello, I'm some text for screen reader users."></span>

instead of

<span class="screen-reader-text">Hello, I'm some text for screen reader users.</span>

If we have turned off CSS on a page that uses the second one technique, it will be full of double content: for sighted users and not. For the first one CSS turned off does not have any impact on the page except its presentation.

Another examples:

<div aria-label="an ASCII-art kitten">ASCII-art here</div>

webmaster<span class="at-image hide-inner-text" aria-label="@">goawayrandommailcrawler</span>example<span class="dot-image hide-inner-text" aria-label=".">34534gfd</span>com

[garconvacher]

Another example of the need for an override: International Phonetic Alphabet (IPA).

<p>[<span aria-label="IPA: banana">bəˈnɑːnə</span>] est la prononciation du mot "banane" en anglais.</p>

I don't want screen readers say: "B, N, N", "B, unknown symbol, N, ..." or "B, U+0259, N, ...". At least the content will not be completely lost (braille is another story).

BTW, aria-label on span isn't read on Firefox but is read on Chrome and Safari if the zombie role (role="text") is added.

[prlbr]

Sometimes aria-label[ledby] shall override the content and sometimes, as in some landmark cases, it shall come additionally to the text content. These are two different behaviours. How about having two distinct attributes for these two different cases?

[mellerjakub88]

What then we should do in case, when the website supposed to work on many languages and is expected to use a different date format based of language, but screen readers are able to read just one format of date as a date, not a string? Aria-label is the only solution in this case

[scottaohara]

Closing this issue as #833, prohibiting the naming of certain roles, directly address the issue of "Clarify use of aria-label on elements with no role", in that it will be prohibited.