WCAG 2.2 / RULE REFERENCE

WCAG 2.1.1 — Keyboard operability

Level A keyboard operability separates "accessible in theory" from "accessible in fact". When it fails, it fails totally — a keyboard user cannot work around a dead menu the way they might squint past weak contrast. It is also where automated checks and real browsers diverge: a static check can see a click handler; only a real traversal sees a trap.

The rule

All functionality must be operable through a keyboard interface, with no keyboard traps. Level A — failing it blocks users wholesale, not just inconveniently.

What it means for how you build

Every interactive element needs a reachable focus order and working focus styles. A widget that only works on hover, or that swallows Tab forever, fails this criterion.

Self-check

Can you complete every task using only Tab, Shift+Tab, Enter, Escape, and arrow keys?
Do modals trap focus inside — and return it to the trigger on close?
Do hover-only controls have focus and keyboard equivalents?
Can you reach and activate the page’s least-used widget — footer toggles, overflow menus, chart controls?

Common pitfalls

The modal that leaks focus: Tab escapes to page content hidden behind the overlay.
Custom widgets built on divs with onClick — no role, no key handler, invisible to keyboards and AT alike.
Traps inside embedded content — a third-party widget that swallows keys is your failure, not theirs.

How the engine checks it

Tier-2 runner keyboard-reach probe — real-browser traversal, with presentational-utility exemptions for genuinely inert embeds.

Sources

Related rules

Last reviewed 2026-11-01.