aria-hidden-focus
Web validation
aria-hidden="true" must not contain descendants that remain in the tab sequence.aria-hidden="true" removes an element and everything inside it from the accessibility tree, but it does not stop descendants from receiving keyboard focus. When a control sits inside such a hidden container, assistive technology cannot present the control’s name, role, or context, leaving users confused and unable to act.
Pass Patterns
Hidden container with only decorative content
A hidden container that holds only decorative, non-focusable content.
<span aria-hidden="true">
<svg focusable="false" viewBox="0 0 24 24"><!-- Decorative icon --></svg>
</span>Hidden control removed from the tab sequence
A control temporarily hidden from assistive technology and removed from the tab sequence.
<div aria-hidden="true">
<button tabindex="-1">Play animation</button>
</div>Fail Patterns
Focusable control inside an aria-hidden container
A button remains in the tab sequence inside an aria-hidden container.
<div aria-hidden="true">
<button type="button">Play animation</button>
</div>aria-hidden="false" on a descendant
Setting aria-hidden="false" on a descendant does not override an ancestor’s aria-hidden="true".
<div aria-hidden="true">
<div aria-hidden="false">
<a href="/help">Help</a>
</div>
</div>ACT Rules
Try It Yourself
Using a screen reader
New to screen reader testing, or need a refresher?
Review this article first: Practical guides for using screen readers
- Turn on a screen reader (for example, NVDA, JAWS, or VoiceOver).
- Move screen reader focus to the element before the container with
aria-hidden="true". - Press Tab to move through the page.
- Listen for announcements and watch the visual focus indicator.
Expected result: Focus skips every descendant inside the aria-hidden="true" container.
Actual result: Focus lands on a control inside the hidden container, which is announced incompletely or not at all, so focus seems to vanish.
FAQ
How does this issue relate to 4.1.2 Name, role, value?
SC 4.1.2 requires that each user-interface component exposes its name, role, state, and value programmatically. A control that is still in the tab sequence but hidden from the accessibility tree fails to meet this requirement because assistive technology cannot obtain the necessary properties.
Why is this issue marked as Serious?
When focus moves to a control that assistive technology cannot expose, users lose context and may think the page is broken. They can miss important actions, become disoriented, or abandon the task. This creates a significant barrier for people who rely on screen readers or other assistive technology.
Standards and Regulations
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 4.1.2 Name, Role, Value (A) | For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to assistive technologies. |
| EN 301 549 | 9.4.1.2 Name, Role, Value | Same as the WCAG text. |