-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WebKit intends to drop its never-standardized text
role implementation
#2011
Comments
Some Working Group history on this matter called out in this comment: |
FYI to a handful of people that may be interested (and maybe supportive?) @stevefaulkner @joanmarie @aleventhal @jcsteh |
In case this change impacts automated a11y checkers: The aria-text rule in axe-core checks for the presence of (I believe it's the only a11y automation library that includes a rule related to |
👋 @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? |
👋 @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 |
In the places where it differs between platform (e.g. VO Mac versus VO iOS), I think we can address that as a bug. |
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
The text was updated successfully, but these errors were encountered: