Skip to main content
Accessibility

ARIA Hidden and Inert Content

  • ARIA
  • inert
  • aria-hidden
  • assistive technology
  • hidden content

When building interactive web experiences, developers frequently need to hide content from assistive technologies or make entire sections of a page temporarily non-interactive. The aria-hidden attribute and the HTML inert attribute are the two primary mechanisms for accomplishing this. While they share the goal of removing content from user interaction, they operate differently and serve distinct use cases. Understanding when and how to use each is critical for creating accessible, WCAG-compliant interfaces.

The aria-hidden="true" attribute removes an element and all its descendants from the accessibility tree, making them invisible to screen readers. The inert attribute goes further: it removes content from the accessibility tree and disables all user interaction—clicks, focus, and text selection—effectively making a subtree of the DOM completely dormant. Together, these tools give developers fine-grained control over what users can perceive and interact with at any given moment.

Why ARIA hidden and inert content matters

Assistive technology users rely on the accessibility tree to navigate and understand a page. When decorative or irrelevant content is not properly hidden, screen reader users encounter noise—redundant icons, duplicate text, or background content behind modals—that makes the experience confusing and frustrating.

Consider a modal dialog. When it opens, sighted users see a dimmed background and naturally focus on the dialog. Screen reader and keyboard users, however, can still tab into and read background content unless the developer explicitly marks it as hidden or inert. Without these techniques:

  • Screen readers announce content behind the modal, breaking the user's mental model.
  • Keyboard users can tab to focusable elements behind an overlay, creating a broken focus trap.
  • WCAG compliance is jeopardized, particularly Success Criterion 4.1.2 (Name, Role, Value) and 2.4.3 (Focus Order).

These issues affect people who use screen readers, switch devices, voice control, and keyboard-only navigation.

How ARIA hidden and inert content works

The aria-hidden attribute

Setting aria-hidden="true" on an element removes it and its entire subtree from the accessibility tree. The element remains visible on screen and interactive via mouse or keyboard—only its exposure to assistive technologies changes.

Common valid use cases include:

  • Decorative icons next to text labels (the icon adds no information).
  • Redundant text that is already conveyed by an accessible name.
  • Visually duplicated content intended only for visual layout.

A critical rule: never place aria-hidden="true" on a focusable element or an ancestor of a focusable element. Doing so creates a situation where a keyboard user can focus an element that the screen reader cannot announce, which is a WCAG failure.

The inert attribute

The inert attribute is a native HTML boolean attribute that makes an element and all its descendants non-interactive. This means:

  • They are removed from the accessibility tree.
  • They cannot receive focus.
  • Click events are not fired on them.
  • Text within them cannot be selected.

This makes inert the ideal tool for marking background content behind modal dialogs, slide-out panels, or any overlay that should monopolize user attention.

Choosing between aria-hidden and inert

Feature aria-hidden="true" inert
Removes from accessibility tree Yes Yes
Prevents keyboard focus No Yes
Prevents pointer interaction No Yes
Prevents text selection No Yes

Use aria-hidden when content is visible but purely decorative. Use inert when content should be completely non-interactive, such as page content behind a modal.

Code examples

Bad example: modal without hiding background content

In this example, the background content remains fully accessible and focusable while the modal is open, allowing users to tab behind the dialog.

<div class="page-content">
  <h1>Welcome to our site</h1>
  <a href="/products">Browse products</a>
</div>

<div class="modal" role="dialog" aria-labelledby="modal-title" aria-modal="true">
  <h2 id="modal-title">Subscribe to our newsletter</h2>
  <label for="email">Email address</label>
  <input type="email" id="email">
  <button type="submit">Subscribe</button>
  <button type="button" class="close-btn">Close</button>
</div>

Even with aria-modal="true", browser support for trapping assistive technology navigation is inconsistent. The "Browse products" link remains focusable and announced.

Good example: using inert on background content

<div class="page-content" inert>
  <h1>Welcome to our site</h1>
  <a href="/products">Browse products</a>
</div>

<div class="modal" role="dialog" aria-labelledby="modal-title" aria-modal="true">
  <h2 id="modal-title">Subscribe to our newsletter</h2>
  <label for="email">Email address</label>
  <input type="email" id="email">
  <button type="submit">Subscribe</button>
  <button type="button" class="close-btn">Close</button>
</div>

Adding inert to .page-content removes it from the accessibility tree and prevents keyboard focus from reaching any element inside it. When the modal closes, JavaScript should remove the inert attribute to restore interactivity.

Bad example: aria-hidden on a focusable element

<button aria-hidden="true" onclick="doSomething()">
  Perform action
</button>

This button can still receive keyboard focus, but a screen reader will not announce it, leaving the user stranded on a mystery element.

Good example: aria-hidden on a decorative icon

<button type="button">
  <svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">
    <path d="M3 18h18v-2H3v2zm0-5h18v-2H3v2zm0-7v2h18V6H3z"/>
  </svg>
  Menu
</button>

The SVG icon is hidden from assistive technologies because the button's text label "Menu" already conveys the purpose. Adding focusable="false" on the SVG prevents an extra tab stop in older browsers.

Managing inert with JavaScript

const modal = document.querySelector('.modal');
const pageContent = document.querySelector('.page-content');
const closeBtn = modal.querySelector('.close-btn');

function openModal() {
  pageContent.setAttribute('inert', '');
  modal.hidden = false;
  modal.querySelector('input, button').focus();
}

function closeModal() {
  pageContent.removeAttribute('inert');
  modal.hidden = true;
}

closeBtn.addEventListener('click', closeModal);

This pattern ensures background content is fully inert while the modal is open and fully restored when it closes, creating a robust, accessible modal experience without relying solely on focus-trap scripts.

Help us improve this glossary term

Was this guide helpful?

Scan your site

Rocket Validator scans thousands of pages in seconds, detecting accessibility and HTML issues across your entire site.

🌍 Trusted by teams worldwide

Validate at scale.
Ship accessible websites, faster.

Automated HTML & accessibility validation for large sites. Check thousands of pages against WCAG guidelines and W3C standards in minutes, not days.

Scheduled Reports
API Access
Open Source Standards
$7 / 7 days

Pro Trial

Full Pro access. Cancel anytime.

Start Pro Trial →

Join teams across 40+ countries