axe-core: Add exception for ARIA role="text"
Invalid ARIA role="text"
can be used to stop ‘text splitting’ in VoiceOver iOS https://axesslab.com/text-splitting/ This improves the user experience and does not negatively affect accessibility.
Please add an exception, so that the presence of ARIA role="text"
does not cause the following failure: ‘[role] values are not valid - ARIA roles must have valid values in order to perform their intended accessibility functions.’
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 16
- Comments: 18 (8 by maintainers)
Alright, just a heads up for everyone. We have this planned for the 4.1.0 release. I’m going to start working on this so should be able to have it into develop within the next couple of weeks. Thank you for your patience.
We finished this and it will be part of the 4.2 release.
tl;dr; I propose we create a new rule for
role=text
and only support it onspan
anddiv
elements, and only if the element does not contain any interactive children.After doing further investigation I believe we can support
role=text
but in a very strcit capacity. Since it didn’t make it into ARIA 1.1, we can only make our best judgment guess as to its uses. Based on the original discussion ofrole=text
https://github.com/w3c/html-aria/issues/26 and the linked article about text-splitting, here are my thoughts.First, we should only allow
role=text
onspan
anddiv
elements. Asrole=text
would override the native semantic of any element, we should only allow it for elements without implicit roles. The limited uses cases we have show it mostly on these two elements to fix the split-text problem of VoiceOver.However, this does not stop someone from wrapping an anchor element with an element with
role=text
, thus removing the anchors semantics:There was talk about UAs ignoring
role=text
if the descendants of the element contain interactive elements. I certainly think we should do something similar. We already have plans for a new rule to flag nested interactive elements as a problem, so we could share that logic here as well.Adding the exception about interactive children takes it outside the scope of how we normally handle allowed aria roles, so we would probably have to create a new rule where we add the check we need.
Would love to see this make its way in. Right now I have to choose between losing 9 points in the audit or giving my non-sighted users a sub-optimal experience (my primary page header reads “heading level 1 2 items” instead of just “heading level 1” without role=“text”).
Sounds good @straker I can think of one other use case for role text in addition to allowing this on div and span elements, that is to also allow this on paragraph elements as that’s their native role (as long as they don’t have nested interactive elements)? Such as:
<p role="text" class="copyright"><span class="VisuallyHiddenText">Image source, </span>Reuters</p>
I assume that in addition to checking for interactive elements that you can’t check if the descendants of the element contain elements with semantics e.g. headings
Update, for future reference. Safari is pulling support for role=“text”. Here is the issue for it: https://github.com/w3c/aria/issues/2011
Talked this over with @dbjorge and @straker. We’re going to keep this in axe-core for the time being as there really is no better solution to accomplish what it is doing.
We didn’t quite have enough time to get this rule into the 4.1.0 release, but we were finally able to work on #601 and now have a PR for this rule.