You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
WebKit does not fall back to 'nameFrom: contents' on aria-describedby reference when referenced element contains role="status" thus not announcing content via VoiceOver
#2381
Open
gjellin opened this issue
Nov 20, 2024
· 5 comments
Nothing is announced when focus is placed on an input with an aria-describedby reference and the referenced node contains role=status, role=alert or aria-live. Occurs on Safari and Firefox, but works on Chrome.
In the following codepen, the first example has the role=status and the second one does not. Only the second one announces the referenced content: https://codepen.io/A11yGreg/pen/dyxazYY
I submitted a bug to WebKit and Tyler Wilcock advised me to submit a bug here. He believes the issue is caused by the following:
When WebKit needs to resolve the text behind aria-describedby, it combines the "accessible names" for each element-by-id pointed to in the aria-describedby. WebKit computes the accessible name for an element by either using the nameFrom: author algorithm, or the nameFrom: contents algorithm (https://w3c.github.io/aria/#namecalculation), or computes no name for the role (see "prohibited" in the spec link). Because role="status" is nameFrom: author, that means we do not consider descendants when computing the name, only author-provided markup on the role="status" element like aria-label.
I don't know why this works in Chrome. It's possible they've noticed how this behavior can be unintuitive, and workaround the spec to provide a better user experience. But probably the best solution is for an issue to be filed on the WAI-ARIA spec so all browsers can become aligned.
I've noticed this before as well, it's definitely caused frustration to developers. But this is not unique to aria-describedby, as we've similarly talked about this in the context of trying to name elements as well.
For roles that are nameFrom: author, Chrome will prefer to expose that. But if there is no nameFrom: author for the element, Chrome falls back to exposing nameFrom: contents, while WebKit and Gecko don't. This behavior seems reasonable to me — I wonder if it should be specified (is it already?), and / or codified in an accname WPT.
And for what it's worth, WebKit and Gecko match Chrome's behavior in this testcase if aria-describedby is swapped with aria-labelledby, i.e.:
<inputtype="text" aria-describedby="message"><divid="message" role="status">Complete this field</div>
All three engines fallback to exposing nameFrom:contents (which is "Complete this field") because the role="status" doesn't have a nameFrom: author. So really, Chrome is consistent between in how it computes aria-describedby and aria-labelledby, while WebKit and Gecko aren't (at least in testing these basic examples).
Description of bug or feature request
Nothing is announced when focus is placed on an input with an aria-describedby reference and the referenced node contains role=status, role=alert or aria-live. Occurs on Safari and Firefox, but works on Chrome.
Example:
In the following codepen, the first example has the role=status and the second one does not. Only the second one announces the referenced content: https://codepen.io/A11yGreg/pen/dyxazYY
I submitted a bug to WebKit and Tyler Wilcock advised me to submit a bug here. He believes the issue is caused by the following:
Will this require a change to CORE-AAM?
Will this require a change to the ARIA authoring guide?
The text was updated successfully, but these errors were encountered: