accname
accname copied to clipboard
w3c
Tests should not use name from <span role="presentation" aria-label="something">
Not sure where to file issues on accname tests, but the current accname tests that were just landed in Chrome were based on assume that aria-label should force a role="presentation" to be exposed. On the surface, it makes sense because it's a global property, as they ARIA spec says: "If an element has global WAI-ARIA states or properties, user agents MUST ignore the presentation role and expose the element with its implicit role."
However, if you look at the list of global states and properties, for aria-label/labelledby it says except where prohibited. And under role=presentation, it lists aria-label and aria-labelledby as prohibited. Further, role=presentation is listed under roles which cannot be named . Given the above, I believe these tests, which use aria-label on role=presentation, have incorrect test expectations, because they are using a name from the role=presentation element. All/DumpAccessibilityAccNameTest.DescFromContentOfDescribedbyElement/blink All/DumpAccessibilityAccNameTest.NameFromContent/blink All/DumpAccessibilityAccNameTest.NameFromContentOfLabel/blink All/DumpAccessibilityAccNameTest.NameFromContentOfLabelledbyElement/blink All/DumpAccessibilityAccNameTest.NameLinkMixedContent/blink
I agree it's not clear. Personally, I'm in favor of honoring the role and ignoring the name when cases like this are encountered, instead of the other way around.
I remember asking Joseph Scheuhammer about this years ago, and he asked me "how can an element that doesn't exist have a name?" Which I thought was a good point. It never made sense to me that it would.
IMO it could be clearer, but I can't see how it allows a name, otherwise it wouldn't say name prohibited. Therefore, I think the tests are wrong.
I think we should probably disallow a description too, but that would be an ARIA spec change.
WIP for Chrome: https://chromium-review.googlesource.com/c/chromium/src/+/2818800
Under role presentation, it also says this as one of the example use cases:
An image that is in a container with the img role and where the full text alternative is available and is marked up with aria-labelledby and (if needed) aria-describedby;
It also says that role="presentation" is prohibited from being named:
https://www.w3.org/TR/wai-aria-1.2/#namefromprohibited
So we might want to look at this from a few different angles (while we're looking at it)
An image that is in a container with the img role and where the full text alternative is available and is marked up with aria-labelledby and (if needed) aria-describedby;
I think they mean the label is on the <div role="img" aria-label="label"> that is parenting an <img role="presentation">
Agree with @aleventhal - that is what is meant but I had to read it 7 times to realise what was being said. That example needs rewording. Filed https://github.com/w3c/aria/issues/1455
@jnurthen Or just remove it? If role=img is used, aren't the children automatically presentational?
The AccName tests which I added to Chromium as content browser tests were taken from expectations written during ARIA 1.1 when name prohibition wasn't yet a thing.
I agree with Aaron that the expectations are now wrong and should reflect the change he's making in Chromium.
Thanks, I will add this to my todo for updating the live algorithm test code to reflect this change soon.
It has been clarified in the ARIA spec that an aria-label will undo any presentational roles. So, I think that the tests are correct as they were originally written, after talking with Aaron about this. See the following two discussions:
- https://github.com/w3c/aria/issues/1824#issuecomment-1269921652
- https://github.com/w3c/aria/issues/2072#issuecomment-1792657628
Blink will reflect this change in this PR.
