search

w3c / aria

Accessible Rich Internet Applications (WAI-ARIA)
https://w3c.github.io/aria/
Other
652 stars 125 forks source link

WebKit intends to drop its never-standardized `text` role implementation #2011

Closed cookiecrook closed 1 year ago

cookiecrook commented 1 year ago

WebKit intends to drop its never-standardized role="text" implementation. This issue is an FYI to the ARIA Working Group. If there are any concerns, please comment here or on the Bugzilla issue.

Details here: https://webkit.org/b/260641

cookiecrook commented 1 year ago

Some Working Group history on this matter called out in this comment:

cookiecrook commented 1 year ago

FYI to a handful of people that may be interested (and maybe supportive?) @stevefaulkner @joanmarie @aleventhal @jcsteh

rahimabdi commented 1 year ago

In case this change impacts automated a11y checkers:

The aria-text rule in axe-core checks for the presence of role="text" for elements with focusable descendants. FYI @WilcoFiers

(I believe it's the only a11y automation library that includes a rule related to role="text")

stevefaulkner commented 1 year ago

👋 @cookiecrook do you know if the VO behaviour, that appears to be the main use case for role=text in the wild, will be modified?

cookiecrook commented 1 year ago

👋 @stevefaulkner I think you're referring to VoiceOver pausing on elements with different style properties, which is a standard feature of VoiceOver. A sighted user sees these differently, so a VO user can inspect the differences when relevant. I mainly hear non-VoiceOver users (web developers testing VO) objecting to this, which I think is due to lack of experience, as an experienced VoiceOver user would likely press VO+A or two-finger swipe down if they wanted VO to read continuously until explicitly paused.

So I'm not aware of a plan to change VoiceOver's behavior there, but I do want to know about cases where WebKit may be exposing irrelevant style blocks separately when role="text" is not applied. If there is a heuristic correction that can be made in the browser engine, that seems like a worthwhile effort. Likewise, if there is some pattern that where both behaviors are useful in different contexts, perhaps we should reconsider something like aria-combinecontents. I recall we discussed something similar previously, though I can't immediately find it in the issue tracker.

cookiecrook commented 1 year ago

In the places where it differs between platform (e.g. VO Mac versus VO iOS), I think we can address that as a bug.