Keyboard-first navigation
Who relies on the keyboard
Screen reader users, people with motor impairments, switch device users and power users all depend on keyboard access. Many assistive technologies behave like a keyboard, so if it works by keyboard it often works for them too.
WCAG 2.1.1 Keyboard (level A) says all functionality must be available from a keyboard. Designers shape this early, because a hover-only menu or a drag-only control cannot be fixed by code alone.
Core rules
No keyboard traps
WCAG 2.1.2: if focus can move into a component, it must be able to move out using the keyboard.
Logical order
WCAG 2.4.3: focus order should follow the meaning and visual order of the page.
Skip links
WCAG 2.4.1: let users bypass repeated blocks such as the header and menu.
If the visual layout and the DOM order differ, keyboard users will jump around the page unpredictably.
Dialogs and menus
Overlays are where keyboard design most often fails. Specify the full behaviour in the design, not only how it looks.
- When a dialog opens, move focus into it, usually to the first control or the heading.
- Keep Tab inside a modal dialog while it is open.
- Let Esc close the dialog.
- On close, return focus to the button that opened it.
Native first, custom with care
Native elements such as <code>button</code>, <code>a</code>, <code>input</code> and <code>select</code> bring keyboard behaviour and roles for free. A <code>div</code> styled as a button does not.
- Use native elements whenever one fits the job.
- For custom widgets such as tabs or menus, follow the keys and roles in the WAI-ARIA Authoring Practices Guide.
- Test the final design by unplugging the mouse and completing the main task.
A simple test finds most problems. Open the page, put the mouse aside and use only the keyboard. Tab moves forward, Shift+Tab moves back, Enter activates links and buttons, and Space activates buttons and checkboxes.
- Press Tab once from the top. Does a skip link appear?
- Continue through the page. Does focus follow the reading order?
- Open every menu, tab set and dialog, then close each with the keyboard.
- Complete the main task, such as signing up or buying, without the mouse.
Anything that appears only on hover needs a keyboard equivalent, such as showing it on focus as well.
Sources
- W3C. Web Content Accessibility Guidelines (WCAG) 2.2. https://www.w3.org/TR/WCAG22/
- W3C WAI. ARIA Authoring Practices Guide. https://www.w3.org/WAI/ARIA/apg/
This guide was drafted with AI assistance from public standards and references. For the exact wording of a standard, use the sources listed above.