WCAG 2.2 · Guideline 2.1 · Operable
Keyboard Accessible
Every task has to be finishable from the keyboard alone.
Get the keyboard right and almost everything else follows. Speech input creates keystrokes. An on-screen keyboard driven by a mouse creates keystrokes. Switch devices and sip-and-puff hardware create them too. No other input method carries that many people at once, and it holds on one condition, which is that operating your site never depends on how long a key is held down. What does not count is pushing the mouse pointer around from the number pad. That is the answer to anyone arguing a mouse-only control is still reachable somehow.
Three A/AA success criteria live here, all of them Level A, and this guideline has no Level AA rule at all. They cover full keyboard operation, getting back out of anything you can tab into, and single-character shortcuts that do not fire while somebody is typing. The obligation is looser than most teams assume. What has to work from the keyboard is the whole task rather than every single control, so a mouse-only shortcut passes as long as a keyboard route to the same outcome exists beside it. The guideline itself is a goal. Those three rules are the test.
- Rules
- 3
- Level A
- 3
- Level AA
- 0
- Human testing only
- 1
All 3 Keyboard Accessible rules
- 2.1.1Level AKeyboardEvery function on the page has to be operable through a keyboard interface.Partly scannable13 fixes
- 2.1.2Level ANo Keyboard TrapFocus that can get into something has to be able to get back out of it, and the rule gives two ways to satisfy that.Partly scannable2 fixes
- 2.1.4Level ACharacter Key ShortcutsIf your site fires an action from a single printable character, one of three things has to be true.Human testing2 fixes
Level AAA in this guideline
One enhanced criterion sits under 2.1. They are outside the level almost every law names, so our audits treat them as reference rather than scope. Some are still worth adopting, and the Level AAA hub says which.
What goes wrong here
These are the failures we find repeatedly under 2.1, across sites of every size.
- Custom controls are built from div and span elements. They never take focus on their own. The keyboard walks straight past them.
- A modal dialog lets focus wander behind it. The user tabs into a page they cannot see and cannot get back from.
- Focus enters a widget and no key combination gets it out. That is the trap the standard names, and it is worse than any other keyboard failure because there is no mouse to reach for.
- A drag-and-drop interface has no keyboard route to the same result. Reordering a list with the mouse works, and reordering it any other way does not exist.
- Single-key shortcuts fire while somebody is typing or dictating. Their input becomes commands, which is a specific kind of unusable.
Who it affects
- People who cannot use a pointing device, including many with motor disabilities and repetitive strain injuries.
- People using a screen reader on a desktop, whose whole interaction model runs through the keyboard interface. On a touchscreen the same person is using gestures instead, which is why this is about the interface rather than about the technology.
- People using switch access or sip-and-puff devices, which commonly present themselves to the page as a keyboard. Some adapted input emulates a pointer instead, so ask what a given device sends rather than assuming.
- People who simply prefer the keyboard and notice the moment it stops working.
How to work through it
- 1Put the mouse away. Complete the page's main task with the keyboard alone, start to finish. Ten minutes of this finds more than most days of reading code.
- 2Watch the focus indicator the whole way. Note anywhere it vanishes, jumps somewhere unrelated, or lands on something invisible.
- 3Learn the widget before you judge it. A tab list, a menu and a grid are all operated with arrow keys once you are inside them, so "Tab did not reach it" is not by itself a finding.
- 4Open every dialog, menu and date picker, then confirm you can leave each one. Returning focus to the trigger is the usual right answer and not the only one, because the workflow may have moved on.
- 5Try every gesture-driven feature and check a keyboard route exists to the same result. The exception is narrow: it covers functions that genuinely depend on the path a pointer travels, like freehand drawing, not anything merely built with a pointer in mind.
- 6Check character-key shortcuts. A shortcut made only of printable characters has to be switchable off, remappable to include a non-printable key, or active only while the relevant component has focus.
How the levels build
Level A does the heavy lifting. All functionality operable through a keyboard interface, no traps, no dependence on how long a key is held or how fast a sequence is entered, and character-key shortcuts kept out of somebody's typing. Level AA adds nothing here. Level AAA removes the path-dependent exception, and that does not mean freehand drawing has to be rebuilt for the keyboard. It means content that depends on the path a pointer travels cannot reach this level at all, which is a real decision rather than a work item.
Other Operable guidelines
- 2.2Enough TimeTime limits and moving content have to be under the reader's control.
- 2.3Seizures and Physical ReactionsNothing on the page may flash or move in a way that can hurt somebody.
- 2.4NavigableReaders have to be able to find their way around and know where they are.
- 2.5Input ModalitiesTouch, pointer, voice, and motion all have to work, not only the keyboard.
Part of the Operable principle · browse by level: Level A · Level AA · or the full 55-rule library.
See how your site does against these rules.
An expert review plus a real blind screen-reader user, on up to 10 pages, every finding with its screenshot, criterion, and fix. $499, report in 5 business days.