Role=”text” is (presently) kinda not a thing, sorta.

Posted: 08 December 2017
View site topics/tags

this is my new favorite "why did you do this?" bit of code:

<span role="text" tabindex="0"> Text goes here </span>

— Scott O'Hara (@scottohara) December 4, 2017

That tweet contains some of my new favorite code to find, when poking through the source of websites and applications.

<span role="text" tabindex="0">
  Text goes here
</span>

It’s a perfect example of a developer trying to make something accessible (appreciate the effort), but unfortunately it widely misses the mark on what one should be doing with ARIA attributes.

Just a little bit of code can say a lot

Let’s break down the previously mentioned code snippet…

tabindex="0" does not belong on text elements. By themselves, text elements are not expected to receive keyboard focus from the tab key. A tabindex="0" would break this expectation.

In certain circumstances, a tabindex may be found on text elements, or wrapping containers, but typically they will have a tabindex="-1". The -1 will allow for keyboard focus to be programmatically set to the element, but will not place the element in the standard focus order of the document (this is a good thing).

Really, you should only need a tabindex="0" on elements that have been modified into standard focusable elements. Like a <span role="button" tabindex="0">. And you should really only be doing something like that if you have an absolutely good reason to not be using a native <button> element in the first place.

There may be other instances where a tabindex="0" would be necessary, like when dealing the roving tabindexes. But now this is becoming a piece about the tabindex, and we need to get back on track here.
role="text" isn’t (presently) part of the ARIA specification.

While that might be a surprise, as the idea of role="text" has been around since at least 2011, it was never fully agreed upon or adopted into the ARIA 1.1 specification.

So, outside of Webkit browsers, which did implement role="text" to some degree, the role won’t be understood in all browser + screen reader pairings, and thus shouldn’t presently be relied on.
The usage is just wrong in the example, as even if the role were fully supported, there’s no reason for it to be used there. Screen readers would already interpret the <span>Text goes here</span> as text… because that’s what it is.

An appropriate use of the role="text" would be in an example like this:
```
<p>
  Who you going to call?
  <img src="ghostbusters-logo.jpg" alt="GhostBusters!" role="text">
</p>
```
Where the role="text" would tell the assistive technology to announce the alt without conveying the fact it’s an image. Resulting in an announcement like “Who you going to call? GhostBusters!”

Put down the ARIA

It bares repeating, again and again, but please adhere to The first rule of ARIA.

If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible**, then do so**.

Adding onto that statement, for fundamental elements of the web, e.g. text, links, buttons, lists, etc., there is absolutely no reason to double up ARIA roles on top of preexisting native semantics.

So next time you’re about to add a <button role="button">, <a href="..." role="link">, or use an unsupported role like <span role="text", instead just go grab another cup of coffee or something. As getting that extra cup of coffee will have the same effect on the accessibility of your element, as adding redundant roles will.

Previous: Words have power
Next: Pet pigs aren’t service animals