Bug 260641 – AX: intent to remove non-standard role=text feature

• Status: NEW
• Component: Accessibility

[James Craig]

AX: Consider dropping role=text (non-standard, WebKit-only implementation, that the ARIA WG declined to specify)

WebKit's role=text was never in a shipping version of ARIA, and WebKit's implementation pre-dated any spec discussion. Once the feature was discussed, the ARIA Working Group had a variety of concerns and declined to adopt it. As far as I know, it has never shipped in any other engine.

1. The original use case (workaround) is no longer used in a high-profile product. (That product was the reason we couldn't originally drop support when ARIA declined to standardize it.) 
2. The implementation makes any interactive descendants entirely inaccessible, which is often not the intention of authors, and unknown to them when they don’t test in VoiceOver, etc. This could potentially be fixed, but we think the fix is riskier and has a higher performance cost than dropping support.
3. There are other, standard ways to achieve combined content label... The primary benefit of WebKit's `role=text` implementation.
4. There are some sites still using it, mostly due to legacy support of a jQuery Ratings widget, but we don't believe removing this support will break anything... A VO user might just hear a slightly more verbose label in places.


So it seems like the right time for WebKit to drop support for the non-standard `role=text` feature.

Current plan-of-record is to leave support behind a deselected runtime flag... Providing a temporary user workaround in case some high-traffic site is relying on this for some reason.

I'm posting this intent-to-remove-non-standard-text-role here so we can shop the idea around, in case others have concerns.

[Radar WebKit Bug Importer]

<rdar://problem/114354058>

[James Craig]

Patch up at https://webkit.org/b/260684

[James Craig]

Tracker to remove entirely at some point in the future is https://webkit.org/b/260685

[Yegor]

Consider not removing role=text. When text is rendered into a 2d, WebGL, or WebGPU canvas a DOM overlay is necessary to communicate to a screen reader such as VoiceOver what text is rendered in the canvas. Currently, thanks to role=text in Safari there's a clean way to annotate it (and VoiceOver does a good job of reading it). Other browsers require hacks to make text work, such as artificially giving the text a different role (e.g. heading, or group, even when the text is neither).

I filed a feature request for Chromium to adopt role=text with more detail: https://issues.chromium.org/issues/40875151

I hope you reconsider and instead push for the standards committee to adopt the text role.

[Yegor]

For an example of a high-traffic site, earth.google.com uses it in Safari (transitively via Flutter).

[Yegor]

I wish I knew about this intent earlier, but this went through way too quickly. I posted more detail in https://bugs.webkit.org/show_bug.cgi?id=260641, but I think it's better to push other browsers to adopt this role rather than remove it. There's an important use-case for the text role.

[Yegor]

Sorry, I meant to post my last message in https://bugs.webkit.org/show_bug.cgi?id=260685, not here.