In one paragraph
ARIA-hidden element must not be focusable or contain focusable elements describes a mismatch between the accessibility tree and keyboard interaction. aria-hidden does not itself disable focus or clicks. Either expose needed controls or make inactive content appropriately unavailable, managing focus before the change. Removing sequential tab stops alone is not always enough to prevent programmatic or pointer focus into a hidden subtree.
Why it matters
A keyboard user can land on a control that assistive technology has been told to ignore. That creates confusing or silent navigation, often in off-canvas panels, inactive slides, duplicated content, or incorrectly hidden icon links.
aria-hidden applies to a subtree; adding aria-hidden=false to a descendant does not generally cancel an ancestor's true value. Fix the boundary rather than layering contradictory declarations throughout the component.
Inertness is a different tool. inert makes its covered subtree unavailable for interaction and removes it from accessibility exposure, while not automatically styling it as inactive. Actual hiding through appropriate HTML or CSS has different layout consequences. Choose the behaviour that matches the interface.
How WebAuditOS evaluates this finding
The supplied aria-hidden-focus rule checks its applicable hidden regions for sequentially tabbable content. Its documented exclusions and review conditions include inert or disabled states, negative tabindex cases, certain focus handlers, and modal-related heuristics.
Serious impact maps to high severity. Some uncertain cases become review outcomes omitted by the failures-only report. A passing negative-tabindex path does not prove that scripts, pointer input, or transitions cannot place focus in the hidden region. An initial modal snapshot can also obscure other states.
How to fix it
- Inspect where focus can actually move before, during, and after opening or closing the component. Include controls inside hidden ancestors, not only elements with their own aria-hidden attribute.
- Decide whether the region should remain operable. If the control is needed and visible, remove inappropriate accessibility hiding. If the whole panel is inactive, use a mechanism that actually fits its intended interaction and visual state.
- For a subtree intentionally unavailable to users, consider inert with suitable visual and status treatment. For example:
<section id="inactive-panel" inert>
<a href="/account">Account settings</a>
</section>This illustrates inertness, not a complete modal or drawer. The application must provide an understandable active route and manage state transitions.
- Move focus to a meaningful active location before making its current region unavailable. When closing or switching a view, restore focus according to the task rather than leaving it on a removed or inert element.
- Keep the active dialog or drawer outside inappropriate hidden or inert boundaries. Native dialog and modal implementations have special behaviour; follow the actual supported pattern instead of applying attributes to the entire body indiscriminately.
- Do not depend only on tabindex=-1. It removes ordinary sequential navigation but can leave other focus mechanisms. Review click handling, scripted focus, and dynamically added descendants.
- Treat inert as a Boolean attribute: inert="false" still means the attribute is present. Remove it or set the DOM property appropriately when reactivating content, and restore necessary names and states.
- Test Tab, Shift+Tab, pointer use, Escape where applicable, assistive navigation, and repeated open-close cycles. Rescan multiple relevant states rather than relying on the initial overlay view.
What the fix can break
Applying inert too broadly can disable the very controls needed to dismiss an overlay. It can also remove searchability and text selection within the affected region. Communicate inactivity visually where relevant.
Focus restoration can target a trigger that no longer exists after a state change. Choose a logical fallback and test deletion or navigation outcomes.
A component that looks hidden can still be active, while one that looks active can be inert. Keep visual, programmatic, and interaction states coordinated rather than controlling them from separate stale variables.
Questions
Does aria-hidden disable clicking and focus?
No. It controls accessibility exposure, not a general interaction lock.
Does aria-hidden=false on a child undo a hidden parent?
Do not rely on that. Correct the ancestor boundary and intended subtree exposure.
Is tabindex=-1 a complete repair?
Not necessarily. Review pointer and scripted focus as well as the sequential tab order.
Which related checks help?
Review body hiding, keyboard regions, and the automation limits guide.
What severity does this get in the report?
High. An axe finding takes its severity from the impact axe reports for the element that failed, and the report maps critical and serious to high, moderate to medium, minor to low. This rule is declared serious in axe-core 4.13.0, so every failure arrives as high.