WebKit does not fall back to 'nameFrom: contents' on aria-describedby reference when referenced element contains role="status" thus not announcing content via VoiceOver

[gjellin]

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:

<input maxlength="255" name="Name" required="" type="text" aria-describedby="help-message-1503">

<div id="help-message-1503" role="status">Complete this field.</div>

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.

Will this require a change to CORE-AAM?

Will this require a change to the ARIA authoring guide?

[scottaohara]

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.

see: https://codepen.io/scottohara/pen/YzmoxXJ

[twilco]

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.

[twilco]

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.:

<input type="text" aria-describedby="message">
<div id="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).

[cookiecrook]

Thanks for the thorough diagnosis @twilco!

[spectranaut]

Discussed in today's working group meeting: https://www.w3.org/2024/11/21-aria-minutes#bae2

[JAWS-test]

I think it's a big misunderstanding on the part of browsers that they don't transmit the text content as a description for role=status, for example, if it is referred to via aria-describedby. A div element, for example, may not be labelled at all (https://www.w3.org/TR/wai-aria-1.3/#generic) - consequently, according to this logic, I should never refer to a div via aria-labelledby or aria-describedby.

The ‘Name From’ specification in the ARIA specification, however, means something different: If I am at the element (i.e. do not refer to the element via aria-labelledby or aria-describedby), then a div, for example, cannot be labelled (but still has its text content), whereas a role=status can be labelled and has its text content. A screen reader should first output the labelling of the live region for role=status and then the text content.

Unfortunately, this is not formulated clearly enough in AccName, which leads to absurd misunderstandings. This must be fixed!

[JAWS-test]

Related: w3c/accname#153 (comment) and w3c/accname#120. The problem has been known for several years and unfortunately nothing has been done so far. I would very much welcome it if this could finally change!