Automated accessibility tests can be useful for finding barriers that affect people with disabilities, but they’re not always 100% accurate. This is especially true when tools try to evaluate WAI-ARIA (Web Accessibility Initiative — Accessible Rich Applications, also referred to as ARIA).
One of the most common automated accessibility warnings is “ARIA Hidden,” which occurs when the aria-hidden attribute is set to aria-hidden=”true.” The attribute hides content from the accessibility API, which can be useful in some circumstances, but it can also create serious usability concerns.
With that said, automated tools can’t always interpret context. If you’ve received an ARIA Hidden warning, you might not need to make any changes to your website. However, you’ll need to understand why the warning occurred.
Related: Introduction to ARIA for Web Accessibility
Why Automated Accessibility Tools Report ARIA Hidden Warnings
ARIA is a technical specification that provides semantic context for screen readers and other assistive technologies. As we’ve discussed in other articles, ARIA can be extremely useful, but it can also cause problems — particularly when developers use ARIA as a replacement for semantic HTML.
Many screen readers will assume that ARIA markup is accurate, and because ARIA is fairly powerful, misusing certain attributes can affect the user experience in unpredictable ways.
aria-hidden is one example: The attribute tells assistive technologies to hide content from the user. If that content is important — for instance, an interactive element that enables the user to navigate the website — the user might become confused or frustrated. They may be unable to complete forms, read text, or stop multimedia playback.
Needless to say, these are serious accessibility concerns. Misuse of aria-hidden can violate the Web Content Accessibility Guidelines (WCAG) Success Criteria 4.1.2, “Name, Role, Value,” which requires all user interface components to have a name and role that can be programmatically determined.
Because aria-hidden is a powerful, important attribute, many accessibility tests will identify all instances of aria-hidden and provide a warning. An ARIA Hidden warning doesn’t necessarily indicate a problem, but developers should make sure that they’re using the attribute intentionally.
Related: 5 Common Misconceptions About WAI-ARIA and Accessibility
Fixing an ARIA Hidden Warning
To resolve an ARIA Hidden warning, you’ll simply need to remove aria-hidden=”true" from your website’s HTML, then check your ARIA implementation to make sure you’ve provided correct attributes for every element that requires one.
Before taking this step, you’ll need to determine why your content is hidden — and whether it should remain hidden for certain users.
Here are a few considerations to keep in mind:
- If content is purely decorative (it doesn’t provide any new functionality or content) and it could create issues for people who use assistive technologies, hiding the content might be appropriate.
- Likewise, if interactive elements (such as form controls or text) have an equivalent alternative, you might decide to hide the less-accessible version of those elements.
- Offscreen content and collapsed menus should usually be hidden.
If the hidden content falls into any of those categories, you can ignore the ARIA Hidden warning. However, if the content is important to the user’s experience of the website, you might need to use WAI-ARIA to provide semantic context. Misusing the hidden attribute can cause serious accessibility issues.
Related: WCAG 2.2 Introduces New Requirements for Hidden Controls
When using aria-hidden, avoid common mistakes
If you’ve decided to hide content from assistive technologies, make sure you have a good reason. Remember, using aria-hidden isn’t a shortcut — visitors who access your site with screen readers and other technologies should enjoy an equivalent experience to other users.
Some tips for using aria-hidden:
- The aria-hidden=”true" attribute should not be used on any focusable element.
- Remember that aria-hidden=”true" applies to all child elements — regardless of whether you use aria-hidden=”false" for those child elements.
- In some cases, the role=”presentation" and role=”none" attributes are more appropriate than aria-hidden=”true.”
Finally, don’t rely on automated tools alone to evaluate your ARIA implementation. The Bureau of Internet Accessibility offers a comprehensive free website audit using our A11y platform, which can identify many common accessibility issues — but like all automated tools, it can’t provide proof of WCAG conformance or proper ARIA usage.
To make sure your website is accessible, combine automated testing with manual reviews performed by people who use screen readers regularly. Our website accessibility audits utilize a four-point hybrid testing methodology, which can help your site meet its accessibility goals — and build better practices for long-term success.
