fix(aria-allowed-attr): pass aria-label on some HTML elements - #2935
Conversation
Allow aria-label and aria-labelledby on the following elements, if those elements have no role. - audio - applet - canvas - dl - embed - iframe - input - label - meter - object - span - svg - video
| "label", | ||
| "meter", | ||
| "object", | ||
| "span", |
There was a problem hiding this comment.
I don't think span should be allowed
There was a problem hiding this comment.
@straker Are you able to link to the specific section of the ARIA spec that disallows aria-label on span? I'm looking through https://www.w3.org/TR/html-aria/, but I can't find anything that disallows it. It appears as though span allows "Global aria-* attributes", of which aria-label is one (per https://www.w3.org/TR/wai-aria-1.2/#global_states). Of course that list has the carve-out "Except where prohibited" for aria-label, but I can't find anything that prohibits aria-label for span or more generally for role-less elements.
FWIW, I generally agree with disallowing aria-label on span, but I'm not sure if it's a strict ARIA conformance violation.
There was a problem hiding this comment.
So there is no spec documented reason for this (although it's coming). You can see where we got most of the concept in this pr #2764. As it stands though, it's also a mix of a best practice since no screen reader supports it (#2712 (comment)).
Edit: looks like it's been updated since I last looked. The generic role now prevents aria-label/ledby.
02f41d5 to
bd072b2
Compare
bd072b2 to
6c9bc79
Compare
07aab35 to
332d338
Compare
332d338 to
d0087cf
Compare
* fix(aria-allowed-attr): pass aria-label on some HTML elements Allow aria-label and aria-labelledby on the following elements, if those elements have no role. - audio - applet - canvas - dl - embed - iframe - input - label - meter - object - span - svg - video * chore: Deal with IE * chore: Address feedback * chore: Maybe like this... * chore: Random guessing stuff * chore: Update doc/check-options.md
|
I'm seeing the same issue on an Markup that is failing: Message from Axe:
|
|
@andrewleith |
|
Interesting. Thanks for the info @straker :) |
|
I'm not sure what you mean by formally, but Leonie Watson wrote an excellent article on this behavior, which was the basis of this rule. |
|
@straker @WilcoFiers Someone on the A11y Slack (external) channel today mentioned getting an error for aria-labelledby on a |
…low label and body from being named (#5259) After looking over the HTML in ARIA spec, I realized that we could better handle how we determine when an attribute is prohibited. Basically if the element doesn't have an explicit role, then we use the `htmlElm` spec to determine prohibited attrs and naming, otherwise we use the `ariaRoles` spec to determine that. This should allow us to eliminate the `elementsAllowedAriaLabel` option that was [introduced to fix which elements allowed naming](#2935) and then modified when we [added Chromium roles](#2948) to fix conflict name resolution. However the option still has the `applet` element which isn't in our html spec so I'm leaving it for now. Elements which allow naming now include: `section`, `blockquote`, `address`, `hgroup`, `ruby`. This also adds enforcement for elements that are not allowed any aria-* attribute (which has never been used in our code) by changing the `noAriaAttrs` spec property to an empty `allowedAriaAttrs` so that they now throw in the rule `aria-allowed-attr`. Closes: #5185 Closes: #3410
5 participants
Allow aria-label and aria-labelledby on the following elements, if those elements have no role.
Closes issue: #2933, #2926
I did a bunch of testing with JAWS, NVDA and VoiceOver to come to this list, here are my test results:
https://codepen.io/wilcofiers/pen/WNpwMNj?editors=1000
"label" is the only one that isn't supported that I added anyway, because if you do
<label aria-label="foo" for="bar"></label>, that label will be used in the accessible name of whatever form control hasid="bar".dlis on the list (unlike ul, and ol) because it doesn't have an implicit role.