1616833 - Support for (ARIA) role=text (parity with all the other major browsers)

Status: UNCONFIRMED

(Core :: Disability Access APIs, enhancement, P3)

Description

[brennan]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.106 Safari/537.36

Steps to reproduce:

Visit this test page with a screen reader or AT running (e.g. Narrator or NVDA) and browse the page.

https://carmacleod.github.io/playground/role-text-tests.html

Actual results:

The aria-label attributes for character sequences wrapped with role=text are ignored. These characters are announced in an arbitrary way depending on speech synth, browser language and too many other variables to be predictable.

Expected results:

Firefox should represent elements with role=text in the accessibility tree as 'flat' text derived from their aria-label attribute. (i.e. the substitution of the aria-label should occur 'seamlesly', so that in the accessibility tree, the element is replaced by the aria-label text as part of any surrounding text nodes.

While FF's behavior conforms strictly to the current ARIA spec, role=text was intended to be part of the latest finalised ARIA, but was removed at the last minute, apparently over concerns about content authors putting hyperlinks inside. These concerns have been addressed (the consensus is that operable roles such as links inside elements with role=text should not be represented in the accessibility tree). This role is only for text content, including unicode glyphs and the like.

Briefly, role=text, primarily intended for span elements, allows an ambiguous character sequence such as "IV" to be interpreted by assistive technology in a consistent and predictable way, via an aria-label, without the additional 'noise' of announcing a role such as "image" or "graphic". This is especially important for domain-specific content. In our case (medical domain) we want "IV" to be announced as the two letter abbreviation for "intravenous", as a seamless part of the text but in practice, we hear "Four" or "Roman Four" which is just wrong. Browser language and speech synthesizers (even from the same vendor) also distort the interpretation in various unpredictable ways. The abbr element is not a viable solution to this problem. I don't necessarily want the abbreviation expanded or explained, and it might not even be an abbreviation (e.g. I might want "✓" pronounced as "correct" rather than "check" or whatever else). Content authors will want to be sure that when various interpretations for a character sequence (such as "IV" or "4x4") exist, a specific idiom is used, rather than being at the mercy of the opaque guesswork performed by speech synthesizer, browser language etc.

There is ongoing discussion about the many use cases for role=text here: https://github.com/w3c/aria/issues/870

The only really viable alternative to role=text which works on Firefox today is role=img, which introduces unnecessary and unwelcome chattiness: The image role is announced (as "image" or "graphic"), even though a character sequence with a specific text interpretation is not an image at all - the semantics are wrong. Also, if you get your AT to view 'all images' you'll get these character sequences too, which is just unwelcome noise for those that want to inspect the actual images.

More to the point, ALL other major browsers, including the new Edge, support role=text in a consistent way. The use case is strong, and it has real value to both content creators and AT users. Firefox is the last major browser not to support this useful feature which will no doubt be part of the next version of ARIA. Please don't wait for that version. Add support for role=text sooner, rather than later.

Note that people are already using role="text img" to work around Firefox's outdated/cautious implementation. (Firefox will fall back on the image role). This practice is recommended within the accessibility community, but it would be much better if we could simply rely on role=text 'everywhere'.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[James Teh [:Jamie]]

Ug. There are significant problems with this and I really hope it doesn't make it into the spec in its current form. I'll comment on the GitHub issue, since a spec debate doesn't belong here, but I'm not willing to consider this for implementation at this point.