Success Criteria

WCAG 2.1.1 Keyboard

Success Criterion 2.1.1 requires that all functionality of the content is operable through a keyboard interface, without requiring specific timing for individual keystrokes. It's a Level A criterion — one of the foundational requirements under the Operable principle, Guideline 2.1 (Keyboard Accessible).

Why "keyboard" and not just "not mouse-dependent"

This criterion is phrased around a keyboard interface specifically because it stands in for an entire category of assistive technology: switch devices, voice control software, and screen readers all typically operate through the same keyboard-equivalent event interface a real keyboard uses. A control that's keyboard-operable is very often operable by all of these at once; a mouse-only control excludes all of them simultaneously.

What "all functionality" actually means

Every interactive capability on the page needs a keyboard path — not just primary navigation, but drag-and-drop reordering, hover-triggered menus, custom sliders, canvas-based drawing tools, right-click context actions. If a mouse user can do it, a keyboard user needs an equivalent way to do it too, even if the exact interaction pattern differs (arrow keys instead of dragging, for instance).

The one narrow exception

WCAG allows an exception only where the underlying function fundamentally requires input that can't be keyboard-emulated with reasonable accuracy — freehand drawing being the standard example. This is a narrow carve-out, not a general excuse: a custom dropdown, modal, or drag-to-reorder list are all expected to have keyboard equivalents; they don't fundamentally require a pointer, they were just built assuming one.

Where this breaks in practice

See Keyboard Inaccessible Controls for the concrete failure patterns: <div>s styled as buttons with only a mouse click handler, custom widgets with no keyboard event wiring, and positive tabindex values that scramble the natural tab order. The fix in almost every case is the same: prefer real, native interactive HTML elements, which come with keyboard behavior built in for free, over rebuilding that behavior from scratch on a generic element.

The related trap: keyboard traps

A separate but closely related criterion, 2.1.2 (No Keyboard Trap), requires that if keyboard focus can move into a component, it can also move back out using only the keyboard (or the user is told how). A modal dialog that can be opened via Tab but has no keyboard-accessible close button is a keyboard trap — technically distinct from a 2.1.1 failure, but usually found alongside one.

Common questions

What is WCAG 2.1.1 Keyboard?

A Level A criterion requiring every interactive function to be usable with a keyboard alone, not just with a mouse.

What commonly fails 2.1.1?

Custom controls built from div/span with click handlers but no keyboard support, and interactions that only respond to hover or mouse events.

Are there exceptions?

Yes — functions that inherently require continuous path-based input (like freehand drawing) are exempt, but the vast majority of controls must be keyboard-operable.