Keyboard
Every function on the page must be operable from a keyboard alone — no required mouse moves, drags, or specific timings. Screen-reader, switch, and voice-control users all depend on this baseline.
What it asks
All functionality of the content must be operable through a keyboard interface, without requiring specific timings for individual keystrokes. The user must be able to reach every interactive element with Tab, activate it with Enter or Space, and operate complex widgets with the arrow keys and other standard combinations.
There are two narrow exceptions: input that depends on the path of the user’s movement (freehand drawing, signing a document) and not just the endpoints, and input that mirrors an analogue real-world action where path matters.
How to meet it
- Use native interactive elements (
<button>,<a href>,<input>,<select>) — they are keyboard-operable by default. - For custom widgets built from
<div>or<span>, addrole,tabindex="0", and key handlers for Enter, Space, Escape, and arrows as appropriate for the pattern. - Follow the ARIA Authoring Practices Guide for menus, tabs, comboboxes, dialogs, and tree views — each has a defined keyboard interaction model.
- Provide a keyboard equivalent for every mouse-only gesture: drag-and-drop needs a reorder-via-buttons fallback, hover-only menus need click-to-open, swipe carousels need previous/next buttons.
- Test by unplugging the mouse and walking the entire flow.
Common failures
<div onclick>with norole="button",tabindex="0", or key handler — invisible to keyboard users entirely.- Custom dropdowns where the trigger is reachable but the options are not navigable with arrow keys.
- Drag-and-drop kanban boards, file uploaders, or canvas tools with no keyboard alternative.
- Modal close buttons that exist but no Escape-key handler.
- Hover-only tooltips and menus that never appear under keyboard focus.
- Carousels and image galleries operable only by swipe or click on indicators that have no tabindex.
axe and Lighthouse will flag missing tabindex and missing accessible names, but they cannot tell you whether your custom dropdown actually responds to arrow keys — that part is manual.
Why it matters
This is the single most important success criterion for operability. Screen-reader users navigate by keyboard. Switch users emulate a keyboard. Voice-control users issue commands that map to keyboard events. Power users with RSI rely on it. A site that fails 2.1.1 effectively excludes everyone who cannot use a mouse — and that group is much larger than the obvious one.