Screen reader support is an essential component of web accessibility. When you’re developing content, your goal is to provide screen reader users with the same essential experience as visual users — and in certain situations, that might mean hiding content from the accessibility API (application programming interface).
Of course, you shouldn’t hide anything from users unless you’ve got a very, very good reason. However, modern websites often have elements that cannot (or should not) be conveyed to assistive technologies.
What content should be hidden from screen readers?
Content may be hidden from assistive technologies by using display: none in CSS; the HTML5 hidden attribute; or aria-hidden=’true' in WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) markup.
Using CSS or HTML will hide the content visually and remove it from the accessibility tree. These attributes should only be used when you need to hide content from all users.
The aria-hidden attribute works differently. It removes the content from the accessibility tree, but does not change the visual appearance of your website. Assistive technologies may still announce the presence of the element.
You might use aria-hidden if your content falls into one of the following categories:
- Content that is purely decorative, such as dividers, non-essential images, and icons
- Repetitive or duplicated content
- Content that appears offscreen, including collapsed menus
Only use aria-hidden when content is visibly rendered. If you use HTML hidden or the CSS display:none, you don’t need aria-hidden, since the content isn’t visible on the page — the content is already removed from the accessibility tree, so aria-hidden is redundant.
Related: How CSS Benefits Accessibility
Exercise caution when using aria-hidden
Remember, while WAI-ARIA is helpful for accessibility, you’ll need to follow the best practices of ARIA when creating your content. Otherwise, you may unintentionally introduce accessibility barriers — particularly when using aria-hidden to prevent users from accessing something important.
Misusing aria-hidden may violate Success Criteria 4.1.2 of the Web Content Accessibility Guidelines (WCAG). This criterion requires all user interface components to have a name and role that can be programmatically determined.
Some tips to keep in mind:
- Only hide content with ARIA when doing so will improve the user experience. For example, if an icon has an appropriate accessible name, you may hide the icon character, which would prevent screen readers from announcing the icon along with the accessible name.
- Not all screen reader users have visual impairments, and visible content should be consistent with the screen reader output.
- aria-hidden=”true" removes the element and its child elements from the accessibility tree. Adding aria-hidden=”false" to a child element will not make the child element visible.
- Never use aria-hidden on focusable elements (for instance, hyperlinks or buttons). This might prevent users from perceiving important controls, and screen readers will generally ignore aria-hidden on these types of elements.
- Don’t confuse aria-hidden with role=”none" or its synonym, role=”presentation". While aria-hidden hides content, role=”none" declares that the element is purely for presentation, which removes the element’s ARIA semantics without hiding the content.
For more guidance, review MDN Web Docs' WAI-ARIA guide.
Using aria-hidden may trigger errors within some automated accessibility tests
Generally speaking, it’s a bad idea to hide content, but as we’ve discussed, there are defensible reasons for taking that step. Unfortunately, most automated accessibility tests aren’t capable of understanding the context of the aria-hidden attribute.
As such, automated tests will often flag aria-hidden as a potential accessibility issue. This doesn’t mean that you need to remove the attribute — you’ll simply need to evaluate each instance individually to make sure that you’re using it correctly.
Related: What WAI-ARIA “Hidden" Warnings Mean For Your Website
Before hiding content, think about your users
Remember, hidden content should always support the screen reader user’s experience. You might decide to hide logos, icons, or repetitive text, but you should never remove useful content. Assistive technology users deserve an equivalent experience, and it’s your responsibility to provide that experience.
We strongly recommend working with a digital accessibility partner if you’re inexperienced with ARIA, as poor markup can cause major usability issues. Your partner can use automated and manual testing to ensure that every hidden element is handled correctly.
The Bureau of Internet Accessibility can help you understand ARIA and build a long-term compliance strategy for your content. Send us a message to connect with our team.
