-
Notifications
You must be signed in to change notification settings - Fork 126
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
Comments
My 2c. I think |
To add, currently:
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/ |
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:
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:
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:
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. |
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:
NVDA will just say "text" in that case. See the examples in my previous comment to understand why. |
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. |
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. |
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 |
I very much appreciate explanation of choices for NVDA from @jcsteh. 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 |
@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 |
As a web developer, I expect to override all text content in elements by an aria-label on an element if
It allows to drop awkward CSS class .screen-reader-text in some cases:
instead of
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:
|
Another example of the need for an override: International Phonetic Alphabet (IPA).
I don't want screen readers say: "B, N, N", "B, unknown symbol, N, ..." or "B, U+0259, N, ...". BTW, |
Sometimes |
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 |
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. |
From https://www.w3.org/Bugs/Public/show_bug.cgi?id=28413
The text was updated successfully, but these errors were encountered: