A growing number of developers are using role=”text" to improve mobile screen reader output. However, the “text" role isn’t technically part of WAI-ARIA, and it should be used with extreme caution.
WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications), often referred to as ARIA, is a technical specification intended to provide semantic definitions for dynamic or complex web content.
The World Wide Web Consortium (W3C) publishes the specification — but web browsers, screen readers, and other software may interpret ARIA differently, and some software doesn’t fully support certain ARIA attributes. That’s one of the reasons that the W3C strongly recommends using semantic HTML wherever possible; ARIA should only be used when HTML can’t provide an adequate semantic definition for a certain element.
In this article, we’ll explain some of the nuances to consider when using the “text" role — starting with its association with WAI-ARIA 1.1.
“Text" is not officially included in ARIA 1.1
In 2011, role=”text" was proposed for inclusion in ARIA 1.1, but as of December 2021, it’s not included in the specification. The purpose of “text" is to indicate that an element should be read as text without mentioning other roles within the markup.
Ultimately, role=”text" didn’t become part of ARIA 1.1, but some applications have proprietary support for the role. One of those applications is Apple’s VoiceOver, a popular screen reader available on iOS.
When testing mobile websites with VoiceOver, many developers have noticed something unusual: Apple’s screen reader pauses when handling sentences with inline markup. For example:
<p>This sentence <span>contains inline markup</span>.</p>
VoiceOver reads the segments of the sentence one at a time, which isn’t the best user experience; users must gesture repeatedly to hear all of the text. Other screen readers like JAWS and NVDA read the sentence without interruption. By using the “text" role, developers can solve this issue:
<p role=”text”>This sentence <span>contains inline markup.</span></p>
This would tell VoiceOver (and other applications that support role=”text") to read the sentence without pausing or requiring user input. Screen readers that do not support role=”text" will simply ignore the attribute.
Related: Introduction to ARIA for Web Accessibility
The “text" role can override semantic values
While using role=”text” may improve the user experience, it can also introduce new issues. The role may remove semantic values of elements within markup, which may prevent users from perceiving important content.
For instance:
<p role=”text">This sentence <a href=”##”>contains a link.</a></p>
VoiceOver (and other applications that support role=”text") might read that markup without mentioning the link. This would be a serious accessibility issue; the W3C’s Web Content Accessibility Guidelines (WCAG) Success Criterion 4.1.2 requires all user interface components to be programmatically determined.
Since role=”text" isn’t officially part of ARIA — and since the role could hide the purpose of user interface components — using it improperly could result in a WCAG failure. More importantly, it would impact the experience of real-world users.
Related: 5 Common Misconceptions About WAI-ARIA and Accessibility
When using the “text" role, be prepared to test your content
The best practice is to avoid using the “text" role. While the attribute gives developers more control over screen reader output, many VoiceOver users expect the application to pause to indicate new segments. Developers don’t necessarily need to fix the issue.
If your website’s screen reader output is extremely fragmented, you might consider simplifying your code and using less inline markup. However, if that’s not possible, using role=”text" is acceptable in some circumstances — provided that you’re willing to review your content carefully.
Test with multiple screen readers to make sure that the output is correct. If possible, work with an independent accessibility partner; by auditing your content, your partner may be able to recommend alternative remediation methods and identify other issues that affect users.
To discuss a specific usage of role=”text" or WAI-ARIA attributes, contact the Bureau of Internet Accessibility for a free consultation. Our experts can help you provide the best possible experience for all users — and realize the full benefits of accessibility-first mobile development.
