Who this affects
An element hidden from assistive technology still receives keyboard focus. Keyboard users land on something that is silent — a focus trap.
How to fix it
Remove aria-hidden, or take the element out of the tab order with tabindex="-1".
Effort Medium · ~20 min
Before and after
Fails
<div aria-hidden="true">
<a href="/offers">Offers</a>
</div>Passes
<div aria-hidden="true" inert>
<a href="/offers" tabindex="-1">Offers</a>
</div>Where this sits in the standard
| WCAG success criterion | Level | EN 301 549 clause |
|---|---|---|
| 4.1.2 Name, Role, Value | A | 301-549, 9.4.1.2 |
EN 301 549 clause 9 applies these criteria to web content. The published version referenced by the European Accessibility Act is V3.2.1, which incorporates WCAG 2.1 level A and AA. More on the standard.
How to check it by hand
Tab to the control and listen to what a screen reader announces. It should say what the control is and what it does. "Button" on its own is a failure.
Automated testing settles roughly a third of the WCAG success criteria. This rule is one an automated tool detects reliably — but a clean automated result is not proof of conformance.
Reference
Deque's technical write-up for this rule: aria-hidden-focus
See whether your site trips this rule
Paste a URL. We open it in a real browser, dismiss the cookie wall and run the full EN 301 549 rule set. No account, no card.