Rules · aria-hidden-focus
Failure reference
Hidden content that can still be focused.
aria-hidden removes content from assistive tech — but if it stays keyboard-focusable, users land on elements that do not exist for them.
What fails — and who it fails
The failure, in plain language.
Closed menus and carousels hidden with aria-hidden while their links remain in the tab order: focus enters a void, announcements go silent.
Detection — what the machine can and cannot judge
How the scanner finds it.
- Elements with aria-hidden="true" are checked for focusable descendants in the rendered page.
The legal reading — factual, not fearful
Where this sits in enforcement.
One of the failures behind "the keyboard just gets lost" complaints — hard for a user to name, easy for a scan to prove with a selector.
The fix — by pattern
The pattern that clears it.
- <div class="menu" aria-hidden="true"><a href="…">…</a></div>
+ <div class="menu" aria-hidden="true" inert>…</div>Fix the template, not the page — one change typically clears every instance at once. The triage engine groups findings by template pattern for exactly that reason.
Verification — resolution is evidence, not a checkbox
Fixed means a scan said so.
On monitored domains, mark the finding fixed and the next scan verifies it: zero remaining instances converts the finding to Resolved, and both the claim and the confirmation land in the append-only ledger. Criteria that need human judgement close through sign-off in the coverage matrix — covered by the right method, never by assumption.
Related failures:
See where your templates stand.
A complimentary assessment renders up to 25 public pages in an EU-hosted browser and shows every instance of this failure — grouped, ranked, and honest about what still needs a human.