Keyboard & focus
Hidden Content Can Still Receive Keyboard Focus
Something is hidden from screen readers but can still be reached with Tab, so focus lands on a control that says nothing at all.
aria-hidden-focusWCAG 2.0Introduced in WCAG 2.0.Level AA — the minimum. Missing it blocks people outright.
- Status
- SeriousSerious — Significant friction, or information that is lost.CurrentScanners run this rule today.
- Owner
- DesignDevTest
- Audit
- Automated+ManualA scanner finds it; a person confirms the fix.
Why it matters
aria-hidden="true" tells screen readers to skip an element and everything inside it. But it does not stop the keyboard from reaching links, buttons or fields inside.
So a screen reader user presses Tab and lands somewhere silent. They don't know where they are or what will happen if they press Enter.
Who it affects
| Who | What they experience | Impact |
|---|---|---|
| Screen reader users | Focus moves to a control they hear nothing about, or only hear "blank". | High impact |
| Keyboard-only users | If the hidden part is also invisible, focus seems to vanish while they press Tab through it. | High impact |
| Low-vision users (magnification) | Those using a screen reader or magnifier lose track of where focus has gone. | Partial impact |
| Cognitive and neurodivergent users | Focus jumping to unexplained or invisible places is confusing and easy to get lost in. | Partial impact |
| Voice control users | Mostly not affected, though a hidden control may not respond to its spoken name. | Partial impact |
Business & product impact
| Area | Why | Impact |
|---|---|---|
| Legal | It fails WCAG 4.1.2 at Level A, the minimum. Australia's Disability Discrimination Act complaints and EN 301 549 both point to WCAG. | High impact |
| Conversion | Silent focus stops in menus and pop-ups make people give up on checkout or sign-up. | Moderate impact |
| SEO | No real search benefit — don't sell it as one. | Low impact |
| Brand trust | A page that traps or confuses keyboard users feels broken, and people say so. | Moderate impact |
| Cost to fix | Usually small. Fix it once in the shared menu, drawer or dialog component. | High impact |
Fixing it in code
A closed slide-out menu
Don't
<nav aria-hidden="true" class="drawer closed">
<a href="/shop">Shop</a>
</nav>A screen reader says: “(Tab lands on the link and the screen reader says nothing)”
Do
<nav hidden class="drawer closed">
<a href="/shop">Shop</a>
</nav>A screen reader says: “(Tab skips the closed menu entirely)”
hidden removes it from both screen readers and the Tab order.
The page behind an open dialog
Don't
<main aria-hidden="true">
<button>Add to cart</button>
</main>A screen reader says: “(Tab leaves the dialog and lands on a silent button)”
Do
<main inert>
<button>Add to cart</button>
</main>A screen reader says: “(Tab stays inside the dialog)”
inert hides the content and also stops focus reaching it.
Designer's handoff note
For every menu, drawer and dialog, mark which parts are reachable when it is open and when it is closed.
Hidden means hidden for everyone — not just for screen readers.
Quick test
Tool
The keyboard alone, then NVDA (opens in a new tab) or VoiceOver (opens in a new tab)
Checklist
- Pass
- Every Tab stop is visible and announced with a name.
- Fail
- Focus disappears, or lands on something that is silent.
What a green scan still misses
A scanner finds focusable items inside aria-hidden. It can't tell whether the content should really be hidden or should be shown and announced.
Reference
- Rule ID
aria-hidden-focus- Raised by
- axe-core: “ARIA hidden element must not be focusable or contain focusable elements”
- WCAG
- 4.1.2 Name, Role, Value (opens in a new tab) · Level A · since WCAG 2.0
- Other standards
- EN 301 549 9.4.1.2 · RGAA 10.8.1
- Last reviewed
- 14 October 2026