Why Focusable Elements Must Not Be Hidden from Assistive Technologies

Hiding content from assistive technologies means removing it from how users perceive and navigate the interface.

In modern browsers, applying aria-hidden="true" removes the element and its entire subtree from the accessibility tree. While the attribute is present, assistive technologies cannot access or announce that content.

If any part of that hidden content can still receive focus, users encounter elements they can reach but cannot perceive or understand. This creates a broken experience for screen reader and keyboard users.

WCAG Success Criterion

This issue most commonly impacts the following WCAG success criteria:

• 4.1.2 Name, Role, Value — focusable content is not programmatically exposed to assistive technologies
• 2.4.3 Focus Order — focus moves to elements that users cannot perceive
• 2.1.1 Keyboard — keyboard interaction leads to inaccessible states
• 1.3.1 Info and Relationships (in some patterns) — relationships are hidden from assistive technologies

The failure occurs when focus lands on an element whose role, name, or state cannot be programmatically determined because it has been hidden from the accessibility tree.

What aria-hidden="true" Actually Does

While applied, aria-hidden="true":

• Removes the element and all descendants from the accessibility tree
• Prevents screen readers from announcing or navigating to that content
• Is inherited by all child elements and cannot be overridden by descendants

It is important to note:

• aria-hidden can be changed dynamically
• Its effect is not permanent
• But while active, descendants cannot re-expose themselves

Screen readers do not interpret HTML directly. They rely on the accessibility tree exposed by the browser. ARIA attributes populate or remove nodes from that tree.

The Core Rule

If an element is hidden from assistive technologies, it must not be focusable
and must not contain focusable descendants.

A focusable element inside an aria-hidden="true" region creates a mismatch:

• Keyboard focus moves to the element
• Assistive technologies receive no information about it
• Users cannot determine where they are or what happened

What Counts as Focusable?

An element is focusable if it can receive focus via keyboard or script, including:

• Links (<a href>)
• Buttons
• Form inputs
• <summary> inside <details>
• Elements with tabindex="0" or positive values
• Elements with contenteditable
• Elements focused programmatically via .focus()

Important nuance:

• tabindex="-1" removes an element from the tab order
• It does not prevent programmatic focus
• Programmatic focus inside an aria-hidden subtree still creates an inaccessible state

Correct Markup Examples

These examples pass because hidden content cannot receive focus.

Non-focusable content

<p aria-hidden="true">Decorative text</p>

Focusable element removed via CSS

<div aria-hidden="true">
  <a href="/" style="display:none">Hidden link</a>
</div>

Focus removed explicitly

<div aria-hidden="true">
  <button tabindex="-1">Button</button>
</div>

Disabled native control (focus already removed)

<input disabled aria-hidden="true">

Disabled native controls are not focusable.
In most cases, adding aria-hidden here is unnecessary and may indicate an underlying design issue.

Descendants cannot override aria-hidden

<div aria-hidden="true">
  <div aria-hidden="false">
    <button tabindex="-1">Button</button>
  </div>
</div>

Once an ancestor is hidden, all descendants remain hidden from assistive technologies.

Incorrect Markup Examples

These examples fail because focusable content exists inside hidden regions.

Focusable link moved off-screen

<div aria-hidden="true">
  <a href="/" style="position:absolute; left:-9999px">Link</a>
</div>

Off-screen positioning does not remove focus or accessibility exposure.

aria-disabled used incorrectly

<div aria-hidden="true">
  <input aria-disabled="true">
</div>

aria-disabled does not remove focus.
The input remains keyboard-focusable but invisible to assistive technologies.

Descendant attempts to override aria-hidden

<div aria-hidden="true">
  <div aria-hidden="false">
    <button>Button</button>
  </div>
</div>

The button is focusable but completely hidden from screen readers.

Explicitly focusable hidden content

<p tabindex="0" aria-hidden="true">Focusable text</p>

This creates a keyboard-only stop with no accessible context.

Focusable <summary> inside hidden <details>

<details aria-hidden="true">
  <summary>More info</summary>
  <p>Details</p>
</details>

<summary> is focusable by default and must not exist inside hidden content.

Modern Alternative: inert

For temporarily disabling sections of the interface, inert is often the correct solution.

The inert attribute:

• Prevents keyboard focus
• Prevents pointer interaction
• Removes the subtree from the accessibility tree automatically

This makes it safer than combining aria-hidden with manual focus management.

Common use cases include:

• Background content behind modals
• Inactive regions during step-based flows
• Temporarily disabled UI sections

When available, prefer inert over aria-hidden for interactive content.

Visual Hiding vs Accessibility Hiding

Not all hiding techniques behave the same:

Technique	Removed from accessibility tree	Focusable
display: none	Yes	No
hidden attribute	Yes	No
visibility: hidden	Yes	No
opacity: 0	No	Yes
Off-screen positioning	No	Yes
aria-hidden="true"	Yes	Yes (unless prevented)

Only some methods remove both perception and focus.

Why This Matters

When focus enters an aria-hidden region:

• Screen readers announce nothing
• Users lose orientation
• Navigation becomes unpredictable
• Tasks may become impossible to complete

A focusable element that is hidden from assistive technologies creates a critical usability failure caused by a mismatch between keyboard focus and accessibility exposure.

Common Causes of Failure

• Using aria-hidden="true" to visually hide content
• Hiding background content behind modals without managing focus
• Assuming aria-disabled removes focus
• Forgetting to remove focusable children
• Trying to re-expose descendants with aria-hidden="false"
• Hiding active UI instead of decorative elements

Rule of thumb:
If users can focus on it, assistive technologies must be able to perceive it.

Native Hiding vs ARIA Hiding

Whenever possible, prefer native solutions:

• display: none
• hidden
• Removing elements from the DOM
• inert for temporary deactivation

Native approaches remove both focus and accessibility exposure, keeping behaviour aligned.

How This Is Tested

Accessibility testing verifies that:

• No focusable elements exist inside aria-hidden="true"
• Focus order matches the accessibility tree
• Hidden content is not reachable via keyboard
• Screen readers do not encounter silent focus targets

This issue is frequently identified through keyboard testing and screen reader testing, not automation alone.

Wrapping Up

While active, aria-hidden="true" removes its entire subtree from the accessibility tree. Descendants cannot override this behaviour. If a focusable element exists inside a hidden region, users can reach something they cannot perceive, understand, or operate. Never hide focusable content from assistive technologies. If something is hidden, it must also be unfocusable.