- Success Criterion 2.1.1
- Conformance level A
Keyboard Focus Landing on Hidden or Inert Page Regions
2.1.1 — Keyboard
Scenario
Setting
A fitness app's workout tracker
What’s wrong
Focus sent into aria-hidden (code hiding content from screen readers)/inert regions making controls announced-invisible or skipped while equivalents don't exist.
Example
Here's a real case from a fitness app's workout tracker: focus sent into aria-hidden (code hiding content from screen readers)/inert regions making controls announced-invisible or skipped while equivalents don't exist.
Why it matters
Blind users, people with motor disabilities, and anyone operating the interface without a pointer. Here, on a fitness app's workout tracker, the result is they lose track of where they are on the page.
How to test
Tab through the page: if focus lands inside an aria-hidden or inert region (invisible but still focusable), or skips past a control an equivalent doesn't exist for, it fails.
How to fix
Keep focusable controls out of aria-hidden (code hiding content from screen readers)/inert regions, or unhide them when active.
Outcome
After the fix, the same visitor to a fitness app's workout tracker can now reach and operate the control without a mouse.
Who is affected
Blind users, people with motor disabilities, and anyone operating the interface without a pointer.
Learn more
- Understanding Understanding document (opens in a new tab)
Related scenarios
- Feature That Only Responds to Mouse Events, Not the Keyboard
- Element That Loses Focus the Instant It’s Reached by Keyboard
- Clickable Element Acting Like a Link With No Real Keyboard Role
- Clickable Div With No Keyboard Focus or Key Handling at All
- Focusable Element That Enter and Space Don’t Actually Activate
- Custom Dropdown That Can’t Be Operated by Keyboard Arrows