-
Notifications
You must be signed in to change notification settings - Fork 123
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
I think we need a definition of "User Interface Element" #815
Comments
Good points @DavidMacDonald. I think at a minimum, it would help for the spec to mention scenarios where aria-label should be used to give an acc name (e.g., on elements that are 'natively focusable,' 'made focusable' like widgets, and structures like data tables). |
Just to add some insanity to the discussion, :) there may be some scenarios where allowing aria-label/aria-labelledby on a div, for example, could be useful. Consider the following markup (also available in div-with-label.html on github):
The author made an attempt to provide an accessible name, and the Chrome Accessibility Tree did expose the aria-label as "Price: $4.99", however both NVDA and JAWS say "Price: $499" instead of "Price: $4.99" (a significant difference in price that is only apparent visually). We are looking at other ways to make it possible for authors to communicate styling that affects how text should be spoken, however allowing aria-label/aria-labelledby on div would be an easy thing for authors to understand and use. What I don't know is how allowing accessible names on all of these elements would affect AT performance. Seems like it could take some time to check all divs/spans/etc for accessible names. |
@carmacleod this is role=static which was discussed and previously rejected. |
I think the upcoming CSS Speech Module will address this better. |
Interesting - thank-you. With my author hat on, I like the power and simplicity of @DavidMacDonald, thank-you for bringing this up. It may have implications for #699, so quite timely. For fun, here's another one seen in the wild:
Maybe we could use
We could also say strictly "contents", which would mean author-supplied labels aren't allowed. That may only be part of the story, though, because if the author makes an element interactive (and adds aria-haspopup, say), then maybe an author-provided aria-label would be allowed.
Thanks - wow: |
Can someone dig through this and determine if this is still necessary with the new name prohibited on "generic" elements. Also noting that https://www.w3.org/TR/css3-speech/ is not a thing - the spec is obsolete. If someone determines it is still necessary a PR with a proposed definition would help speed things up - otherwise I'm going to need to move this to 1.3 |
I do not think this is necessary anymore. The naming prohibited as well as work being done on role parity essentially does away with the question of what roles should allow for naming. Updating ARIA in HTML and HTML AAM to further note what HTML elements can receive naming will also help to add further clarity. |
Recently, a Twitter thread got pretty interesting.
https://twitter.com/davidmacd/status/1040194227181780994
https://twitter.com/patrick_h_lauke/status/1041272243018522624
So I did some testing
http://davidmacd.com/blog/does-aria-label-override-static-text.html
AT is all over the map on it.
Then I dug into the spec to try to figure out what is supposed to happen in the accessible name calculation or in the aria-spec, when aria-label is on static content. the spec says the aria-label is to provide an "ACCESSIBLE NAME" and the glossary definition for an ACCESSIBLE NAME says it is for a "user interface element".
But there does not appear to be a definition for "user interface element" in the HTML spec, in the ARIA spec, the NAME COMPUTATION spec.
So would the following HTML elements be "user interface elements" to which the accessible name calculations should apply?
Its probably dumb to place an aria-label on any of these, but its happening in the wild. Some clarity here would help direct screen reader manufacturers.
The text was updated successfully, but these errors were encountered: