Make every control work with a keyboard
Every piece of functionality has to be operable from the keyboard interface. W3C lists G202 as sufficient for 2.1.1 Keyboard on its own and without qualification, which makes it one of the broadest techniques in the library. Keyboard interface is the phrase to hold onto, because it is not the same thing as a keyboard. W3C defines it as a way of feeding keystrokes to a program even when the device has no physical keys. That is how this rule reaches a phone, and why the technique's own worked example is a menu on a mobile device driven by a switch. Screen readers, switch devices, handwriting interpreters and speech-to-text software all arrive through that same door, so losing it loses all of them at once. W3C's method also starts wider than tabbing. Work out everything the page can do first, including the things done with the mouse and the keyboard together, and W3C names four that catch teams out. Drag and drop, selecting text, resizing a region, and opening a context menu. Its answer for drag and drop is the useful one. A reorderable list also ships buttons that move an item up, down, to the top and to the bottom.
How we find it in an audit
We put the mouse away and complete your real revenue journey on keys alone. Search, product, options, cart, checkout. Every point where the journey stops gets a screenshot. The trail of a purchase dying at a mouse-only size picker is the most persuasive thing an audit produces, because it costs a number rather than a rule. Before that we list what the page can do at all, W3C's way, since a keyboard walk only finds the functions somebody thought to look for. Drag-to-reorder and right-click menus are the two that hide from a tab pass.
How affected users experience it
A blind user drives the whole page through keyboard commands, so a control the keyboard cannot reach does not exist for them. There is no workaround here. No squinting, no zooming in, no asking somebody nearby. The journey ends at that control. The same wall stops somebody using a switch device, which is often one button pressed with a head or a hand, and somebody driving the page by voice, because voice commands are keystrokes underneath.
Passes vs. fails
Passes
<button type="button" class="size" onclick="pick('M')">M</button>
<!-- reachable with Tab, fires on Enter and Space, announced as a button -->Fails
<div class="size" onclick="pick('M')">M</div>
<!-- Tab never reaches it, Enter never fires it -->How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- Iframe with interactive elements is not excluded from tab-orderA tool can check this
- Scrollable content can be reached with sequential focus navigationA tool can check this
Other ways to satisfy this rule
13 guides on this site are filed under 2.1.1 Keyboard. W3C lists this one as sufficient for that rule on its own. Implement it correctly, in a way your readers' software actually supports, and the rule is met.
- G90sufficientPair every event handler with keyboard support
- H91sufficientUse native HTML controls instead of rebuilt ones
- PDF3sufficientFix the reading and tab order in PDFs
- PDF11sufficientTag PDF links so they are announced
- PDF23sufficientUse fillable form fields instead of flat text
- SCR2sufficientPair every mouse handler with a keyboard one
This guide is our interpretation of W3C technique G202: Ensuring keyboard control for all functionality. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.