Add exception for ARIA role="text"

[greenc05]

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.'

[utandon]

This exception would be very useful. Please add this asap :)

[straker]

Thanks for bringing this to our attention. I've started internal discussions about this and we'll see what it would take to implement.

[greenc05]

Wonderful thank you @straker

[straker]

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 w3c/html-aria#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": []
}

[greenc05]

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

[greenc05]

@straker would adding this exception also stop the following error as well? GoogleChrome/lighthouse#9337

[straker]

@greenc05 So I tested the provided HTML using the latest axe v3.3.0 and it didn't give a violation for the link not having a discernible name. The presence of the role should only fail the aria-roles rule.

[greenc05]

Thanks @straker maybe Lighthouse uses a different version of axe, I will ask them...

[greenc05]

@straker any idea if or when this might be worked on please?

[straker]

@greenc05 we haven't scheduled it yet. #601 would have to be implemented first so we can use the same check to look for nested interactive roles. Once that is merged we can look at this one.

[greenc05]

Thank you @straker

[JoeMorgan]

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").

[straker]

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.

[straker]

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.

[straker]

We finished this and it will be part of the 4.2 release.

[greenc05]

Thank you so much @straker What a start to the new year!

[padmavemulapati]

Verified aria-text rule with the latest axe-core develop branch code base (dated 12th Jan 2021),
Test snippet for fail criteria:
<div role="text" id="fail1"> Still an <a href="#">interactive link</a> because of the author error.
</div>
<div role="text" id="fail2">
<a href="#" role="none">Flattened text</a> because of the explicit role.
</div>
<div role="text" id="fail3">
<a href="#" tabindex="-1" role="none">Flattened text</a> because of the explicit role.
</div>
<p role="text" id="fail4"><button>Hello</button></p>

Test snippet for pass criteria:
<h1> <span role="text" id="pass1">Digital accessibility, <br />
for everyone.
</span> </h1>
<a href="#"><span role="text" id="pass2">Buy <strong>t-shirts</strong> now</span></a>
<div role="text" id="pass3">Some text<span> and some more text</span></div>

[WilcoFiers]

Update, for future reference. Safari is pulling support for role="text". Here is the issue for it:
w3c/aria#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.