- Success Criterion 2.1.1
- Conformance level A
Interactive Control Removed From the Keyboard Tab Order
2.1.1 — Keyboard
Scenario
Setting
A hotel booking site's room-selection page
What’s wrong
tabindex="-1" (code removing it from the Tab order) on interactive controls removing them from tab order with no alternative access.
Example
A QA pass on a hotel booking site's room-selection page turns this up: tabindex="-1" (code removing it from the Tab order) on interactive controls removing them from tab order with no alternative access.
Why it matters
Blind users, people with motor disabilities, and anyone operating the interface without a pointer. The practical effect on a hotel booking site's room-selection page: they can't complete the task using a keyboard alone.
How to test
Inspect the control in DevTools: if tabindex="-1" has been applied, removing it from the Tab order with no other way to reach it, it fails.
How to fix
Restore interactive controls to the tab order (tabindex="0" (code making it keyboard-focusable) or native focusability).
Outcome
That one change on a hotel booking site's room-selection page means they 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