Focusable element hidden from screen readers
keyboard/hidden-focusable
- WCAG success criterion
- 4.1.2 (level A)
- Outcome class
- Automatic. An automated check that can report a confirmed violation.
- Area
- Accessibility, Technical Robustness
- Default severity
- high
- axe-core rule
aria-hidden-focus
Why we flag this
Keyboard users reach elements that screen readers do not announce — invisible traps.
aria-hidden="true" on a focusable element or its ancestor.
What the rule checks
Scope. Rendered elements in the sequential tab order (native focusable or tabindex >= 0) that are inside, or carry, aria-hidden="true".
Expectation. Fails (violation, one per element) when an element that the Tab key reaches is hidden from the accessibility tree by aria-hidden="true" on itself or an ancestor, also across an open shadow root (aria-hidden applies to the flat tree): keyboard users land on something that is not announced. Passes when the element is taken out of the tab order (tabindex="-1"), when the hidden subtree is inert, when it is not rendered, or when aria-hidden is "false". Native links and ARIA widgets with tabindex 0 count alike, as does aria-hidden set by a script after load.
Source. WCAG 2.2 SC 4.1.2 Name, Role, Value and SC 1.3.1; WAI-ARIA 1.2 §6.7 aria-hidden (authors must not hide focusable content); HTML §6.6.3 tabindex, §6.3 inert
Detection: shared; needs dom, computed_style.
This page is generated from the rule catalogue and the rule contracts; see therule overview for how the outcome classes are derived.