In the world of web accessibility, it is a critical best practice that elements marked as presentational should not contain focusable content. This issue often arises from a misunderstanding of ARIA roles, particularly the misuse of the invalid `role=”text”`. Including interactive elements like links or buttons inside a container that is meant to be non-interactive creates a confusing and frustrating experience for users of assistive technologies.
Think of your website as a library. You expect a book to be for reading, not for pushing buttons. If you open a book and find a random assortment of interactive controls inside, it breaks the experience. The same is true for your website. By ensuring your non-interactive containers are truly non-interactive, you can create a more accessible and user-friendly experience for everyone. For a deeper dive into the world of accessibility, see our article on accessibility.
What Was `role=”text”` Meant to Do?
First, it is important to state that `role=”text”` is not, and has never been, a valid ARIA role. You can see the full list of valid roles in the official WAI-ARIA specification. Its misuse likely stems from a confusion with `role=”textbox”` (for text inputs) or, more commonly, an attempt to make a block of content “plain text” by removing its semantics. The correct ARIA role for removing an element’s semantics is `role=”presentation”` or its synonym, `role=”none”`.
Correctly Handling Non-Interactive Content
The core of the issue is placing a focusable element (like an `<a>` tag) inside a container that has been marked as presentational. This creates a contradiction for screen readers. The correct approach is to separate your interactive elements from your presentational containers.
<!-- Before: A focusable link inside a container marked as non-semantic -->
<div role="presentation">
This is some text, and here is a <a href="/more-info">link</a>.
</div>
<!-- After: The focusable link is moved outside the presentational container -->
<div>
<span role="presentation">This is some text, and here is a </span>
<a href="/more-info">link</a>.
</div>For more on how to create a winning on-page strategy, see our article on on-page SEO.
Frequently Asked Questions
Is `role=”text”` a valid ARIA role?
No, `role=\”text\”` is not a valid ARIA role according to the official WAI-ARIA specification. Its use is a common mistake. The role for a text input field is `role=\”textbox\”`, and the role to remove semantics from an element is `role=\”presentation\”` or `role=\”none\”`.
Why shouldn’t presentational elements have focusable descendants?
When you mark an element as presentational, you are telling assistive technologies to ignore its semantic meaning. Including focusable elements like links or buttons inside it creates a contradiction. A screen reader user might be able to tab to the link, but the context of the surrounding element would be hidden, creating a confusing experience.
What should I use instead of the invalid `role=”text”`?
The correct attribute depends on your goal. If you want to completely hide a decorative element from screen readers, use `aria-hidden=\”true\”`. If you want to remove the semantics of an element (like a list or table used for layout) but still have its content read, use `role=\”presentation\”`.