Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify use of aria-label on elements with no role #756

Closed
jnurthen opened this issue May 14, 2018 · 15 comments
Closed

Clarify use of aria-label on elements with no role #756

jnurthen opened this issue May 14, 2018 · 15 comments
Milestone

Comments

@jnurthen
Copy link
Member

jnurthen commented May 14, 2018

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
Copy link
Contributor

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
Copy link

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
Copy link

jcsteh commented Dec 13, 2018

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
Copy link

jcsteh commented Dec 13, 2018

* 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
Copy link
Member Author

@jcsteh I would love your comments on #833

@jcsteh
Copy link

jcsteh commented Dec 13, 2018

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
Copy link
Contributor

jongund commented Dec 13, 2018

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
Copy link

prlbr commented Dec 16, 2018

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
Copy link

DavidMacDonald commented Dec 18, 2018

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
Copy link

DavidMacDonald commented Dec 18, 2018

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
Copy link

Siemenskun commented Dec 18, 2018

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

@jnurthen jnurthen added this to the ARIA 1.2 milestone Jan 8, 2019
@garconvacher
Copy link

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
Copy link

prlbr commented Feb 20, 2019

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
Copy link

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests