Keyboard Navigation
Everything must be operable with a keyboard alone, which is the single most load-bearing accessibility requirement.
Definition
WCAG 2.1.1 requires all functionality to be available from a keyboard, and 2.1.2 requires that focus can always move away again. This serves screen reader users, people with motor impairments, people using switch devices or voice control, and a large number of people who simply prefer keyboards.
Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.
On this plate
Reach for this when
- Every interactive component.
- Reviewing any custom widget.
- Testing a release.
Common mistakes
- Click handlers on non-interactive elements.
- Positive tabindex values, which break the natural order.
- Focus traps outside modals.
- Focus indicators hidden behind sticky elements.
The checks that find most problems
- 1.Put the mouse away and complete the primary task using Tab, Shift+Tab, Enter, Space, Escape and the arrow keys.
- 2.Confirm every interactive element can be reached and activated.
- 3.Confirm focus is always visible, including over sticky headers and inside scroll containers.
- 4.Confirm the tab order follows the visual order.
- 5.Confirm focus never becomes trapped anywhere except a modal dialog, which must be escapable.
- 6.Confirm a skip link exists to bypass repeated navigation.
Expected key behaviour
| Component | Keys |
|---|---|
| Button | Enter and Space activate. |
| Link | Enter activates. |
| Checkbox | Space toggles. |
| Radio group | Arrows move and select within the group. Tab enters and leaves. |
| Tabs | Arrows move between tabs. Tab moves into the panel. |
| Menu | Arrows move, Enter activates, Escape closes, typing jumps to a match. |
| Modal | Focus trapped inside. Escape closes. Focus returns to the trigger. |
| Combobox | Arrows move through options. Enter selects. Escape closes the list. |
Two things every page needs
<body>
<a class="skip-link" href="#main">Skip to main content</a>
<header>...</header>
<main id="main" tabindex="-1">...</main>
</body>
<style>
.skip-link {
position: absolute;
left: -9999px;
}
.skip-link:focus {
position: static; /* visible, in the normal flow, as the first thing on the page */
}
/* Focus must not be hidden behind sticky chrome (WCAG 2.4.11) */
:root { scroll-padding-block-start: var(--header-height); }
</style>A skip link that is hidden until focused, and scroll-padding so a sticky header never covers the element that just received focus.
Keeping the keyboard path intact
Do
- Use a button for anything that acts and a link for anything that navigates, which is where the expected keys come from.
- Keep the DOM order matching the visual order, since that is the tab order readers will get.
- Give a container tabindex -1 when you need to move focus to it programmatically, rather than making it tabbable.
- Make every custom widget escapable, and return focus to whatever opened it.
Do not
- Do not add tabindex with a positive number. It reorders the whole page and breaks the order everywhere else.
- Do not attach click handlers to a div and call it done. It is unreachable and unactivatable by keyboard.
- Do not trap focus outside a modal context, including in embedded players and third-party widgets.
- Do not rely on hover to reveal a control that has no keyboard equivalent.
Local chart
A11Y·002 · Region V · Grid A4
This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.
Sources
Where a source establishes something narrower than the popular reading of it, the note says so.
- [1]
- [2]
Understanding Success Criterion 2.1.1: Keyboard
W3C, WCAG 2.1
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Applies when you are designing
Relied on by
Entries that assume this is already in place.
- Focus IndicatorsA11Y·003 · Accessibility
Keyboard access without a visible focus ring is technically operable and practically unusable.
- AccordionCMP·017 · Component
- Date PickerCMP·009 · Component
- MenuCMP·018 · Component
- Modal DialogCMP·010 · Component
- SliderCMP·008 · Component
- TabsCMP·016 · Component
- TooltipCMP·013 · Component
- Bulk ActionsPAT·017 · Pattern
- Command PalettePAT·018 · Pattern
- Infinite Scroll and PaginationPAT·021 · Pattern
- NavigationPAT·001 · Pattern
- UndoPAT·022 · Pattern
Often used with
These usually appear in the same screen or the same decision.
- Accessibility InsightsTOOL·033 · Tool
- LinearTOOL·046 · Tool
Check your work
Review passes that test whether this was done properly.
- Accessibility ChecklistCHK·002 · Checklist
Short definition
The one-paragraph version, for when that is all you need.
- Accessibility (a11y)TERM·072 · Term
- Assistive TechnologyTERM·075 · Term
- Focus OrderTERM·077 · Term
- Focus TrapTERM·078 · Term
- Infinite ScrollTERM·052 · Term
- Progressive EnhancementTERM·122 · Term
Related concept
Connected closely enough to change how you apply this.
- Accessible NamesA11Y·008 · Accessibility
- Character Key ShortcutsA11Y·019 · Accessibility
- Content on Hover or FocusA11Y·018 · Accessibility
- Focus ManagementA11Y·004 · Accessibility
- Screen ReadersA11Y·005 · Accessibility
- WCAG in PracticeA11Y·001 · Accessibility
- UI to Accessibility AuditAI·005 · AI workflow
- Flexibility and Efficiency of UseHEUR·007 · Heuristic
- Fitts's LawLAW·002 · Law
- Power Law of PracticeLAW·015 · Law
- Steering LawLAW·016 · Law
- Visual StatesFND·053 · UI foundation
- Accessibility AuditFLOW·012 · Workflow
- Design QAFLOW·003 · Workflow