Managing Content Visibility With aria-hidden

Web accessibility is often overlooked in the hustle of development, but its importance cannot be overstated. One common issue many screen reader users know all too well is hearing the same information repeatedly, or worse, missing out on crucial content altogether because it’s not properly exposed.

To tackle this, developers need to manage content visibility, especially when it comes to how assistive technologies interpret and announce web elements. Thankfully, this is possible via the aria-hidden attribute, and in this post, we’ll help you master it. You’ll learn what the aria-hidden attribute is exactly and how to properly use it.

Fundamentally, when you’re building a webpage, it’s important to remember that there are two separate “views” of your page: the DOM and the accessibility tree.

The DOM (Document Object Model) is your website’s regular HTML structure, which is responsible for rendering the page visually. It contains all the elements of a webpage as they’re rendered for all users, including both sighted and non-sighted users.

Meanwhile, the accessibility tree is a specialised version of the DOM that provides assistive technologies with the content that matters, helping users with disabilities navigate and understand the web. It should exclude elements that don’t need to be announced, like empty containers or purely decorative items. If that tree is full of irrelevant, redundant, or distracting elements, it can overwhelm users who rely on it, making it harder for them to navigate the web.

This separation between the DOM and the accessibility tree allows developers to hide irrelevant or redundant content from assistive technologies while keeping it visible to everyone else. But how? Well, it’s all thanks to the aria-hidden attribute! 

aria-hidden is an attribute used to manage content visibility for assistive technologies like screen readers. It’s part of the WAI-ARIA specification, which aims to make web content more accessible to people with disabilities.

When you apply aria-hidden="true" to an element, it removes that element – and all of its children – from the accessibility tree. This means screen readers won’t announce it. The element is still there, visible as usual on the web page, just not announced by screen readers. This is different from the HTML hidden attribute, which removes both the visual element and its presence in the accessibility tree.

This distinction matters because there are times when content should remain visible to sighted users, but shouldn’t distract or overwhelm screen reader users. 

Here are three main scenarios where using aria-hidden can really improve the experience for screen reader users:

By using this ARIA attribute correctly, you’re helping people who use screen readers stay focused on the content that matters most, improving their experience and saving them from unnecessary noise. 

However, if used incorrectly (e.g., on interactive elements), you risk violating the WCAG 2.2 Success Criterion 4.1.2, “Name, Role, Value.” This guideline requires that interactive elements – such as links, buttons, and form controls – be properly exposed to assistive technologies, so they can be understood and interacted with by those who use screen readers. 

That’s why you should never apply aria-hidden="true" to focusable elements, like links, buttons, or form controls. If you do so, you’ll put your users in a situation where users can focus on elements they can’t perceive or interact with. This can lead to frustration and a broken experience for users navigating via the keyboard or screen reader.

You should also never apply aria-hidden to elements containing focusable elements. Focusable elements in a parent with aria-hidden will not be announced to users when reading the content of a page with a screen reader. But they can still be reached and interacted with via keyboard navigation.

Now that we’ve covered the theory behind aria-hidden, let’s dive into some practical examples to illustrate both correct and incorrect uses of this attribute. 

❌ Imagine you have a navigation button with an icon and a label inside a <div>. Here’s how someone might mistakenly use aria-hidden:

This is problematic because it:

✅ Now, let’s look at how to fix the previous poor implementation use case. This time, we’ll apply aria-hidden only to the decorative icon to ensure the button remains accessible to screen reader users:

This is better because aria-hidden="true" is applied only to the icon (<svg class="icon-home">). Since the icon is decorative, it doesn’t need to be announced by screen readers. The Home text remains visible to both sighted users and screen readers, making sure the purpose of the button is clear.

The button is a native HTML element, so it’s automatically focusable and has built-in keyboard accessibility. Screen readers will announce the button as “Home,” and users can activate it with a keyboard or mouse.

Also, by hiding the decorative icon from screen readers, you avoid unnecessary repetition. The screen reader will announce “Home” once, rather than announcing both the icon and the label.

Ensuring that your use of aria-hidden aligns with WCAG (Web Content Accessibility Guidelines) is crucial for creating accessible web content. While automated accessibility testing tools like axe or WAVE can be a great starting point, they’re not foolproof. They’ll help you catch obvious issues, like missing aria-hidden attributes or misused ones, but they won’t always catch the context. For example, these tools won’t be able to tell if the hidden content is actually decorative, duplicated, or offscreen. That’s why manual testing is necessary.

There are a few key things to check to ensure you’re complying with WCAG and creating a smooth, accessible experience:

If you’re unsure whether you’ve implemented aria-hidden correctly, consider reaching out to web accessibility experts. At The A11Y Collective, our accessibility audits can identify improper implementations and guide you toward WCAG-compliant, user-friendly solutions. We dive into the details, ensuring your site works smoothly for everyone, from sighted users to those relying on assistive technology. You’ll know for sure that your website is on track to be both legally compliant and genuinely accessible.

Getting aria-hidden right is just the tip of the iceberg when it comes to web accessibility. While using this attribute correctly ensures a smoother experience for screen reader users, there’s so much more to learn about building truly accessible web experiences. The goal is to make your websites usable and enjoyable for everyone, regardless of how they interact with the web.

If you’re ready to dive deeper into the world of accessibility and learn how to implement best practices across your web development projects, we’ve got just the thing for you! Our Accessible code course is designed to equip developers with the practical skills needed to create accessible websites. Whether you’re just starting out or looking to refine your existing knowledge, this course will guide you through all the essential techniques, including advanced ARIA attributes, proper HTML semantics, and much more.

Mastering these techniques will make you a better developer and help you avoid the growing legal challenges surrounding inaccessible websites.

Join our Accessible code course today and master building truly accessible websites that everyone can use with confidence!