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 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!

[jnurthen]

@jcsteh & @cookiecrook what is your opinion on making a change here to align with chrome?

[spectranaut]

discussed in today's meeting: https://www.w3.org/2024/12/05-aria-minutes#8798

[jcsteh]

This comes back to the question of when elements should be traversed for name computation even when they only permit name from author. An attempt was made to address this in #1821 (comment), but that seems to have stalled.

As I explained in that comment, my concern with Chromium's behaviour (falling back to name from contents regardless of role) is that you could end up with extremely long names/descriptions. It also makes the behaviour inconsistent between aria-labelledby/describedby vs name from contents traversals.

The more restrictive fix here would be to treat role status as name from author + always traverse (using the terminology from the issue linked above). I think that's reasonable in this case, given that status is not likely to be as big as, say, a massive table.

[jcsteh]

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 can't reproduce this. Gecko is consistent with aria-labelledby and aria-describedby here: no label, no description. I agree that isn't intuitive, but it is currently consistent.