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)

Most upvoted comments

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 on span and div 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 of role=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 on span and div elements. As role=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:

<!-- no longer announces as link, just text -->
<span role="text"><a href="/site.html">Click here</a></span> 

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.

{
  "id": "text-role",
  "selector": "span, div",
  "tags": ["cat.aria", "best-practice"],
  "metadata": {
    "description": "Ensures role=text is used correctly",
    "help": "role=text should only be used on span and div elements with no interactive children"
  },
  "all": ["no-interactive-children"],
  "any": [],
  "none": []
}

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.