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 it affects, and how much
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

Business & product impact, with how much each claim weighs
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)”

<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)”

<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

Step 1: Open a page with a closed menu, or open a dialog.
Step 2: Press Tab slowly through the whole page.
Step 3: Watch where focus goes, and listen with a screen reader on.

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
Read more: Deque University: aria-hidden-focus (opens in a new tab)
Last reviewed: 14 October 2026