Goal
Ensure all functionality works with a keyboard.
Success Criterion · WCAG 2.1.1
Keyboard
All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
Level AWCAG 2.0Operable2.1 · Keyboard Accessible
Copy button ready
What to do
Make every interactive feature operable via keyboard alone (Tab, Shift+Tab, Enter, Space, Arrow keys) without requiring a mouse or touch.
Why it matters
Many people cannot use a mouse or touch accurately and rely on keyboard access (including assistive technologies that emulate keyboard input).
Success criterion
What WCAG 2.1.1 requires
Summarized directly from the official Understanding document so teams can quote the requirement accurately.
All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints.
Intent
Why WCAG created this requirement
- Keyboard access is foundational for screen readers, switch devices, voice input, and many AT tools.
- Avoid mouse-only interactions such as drag-and-drop without keyboard alternatives.
- Do not require timed key sequences (e.g., holding keys for exact durations) for basic operation.
Benefits
Who gains when you pass
- Keyboard-only users can complete all tasks.
- Screen reader users can operate interactive components reliably.
- Users with motor impairments can use switch devices or alternative keyboards.
- Power users benefit from predictable keyboard support.
Why it matters
User impact when this criterion fails
Summaries drawn from the Understanding document help you socialize impact statements with product stakeholders.
Mouse-only controls exclude keyboard users from completing tasks.
Custom widgets without keyboard support can be unreachable or unusable.
Users may abandon the experience when essential functions are inaccessible.
Exception guidelines
Use the WCAG 2.1.1 exceptions correctly
Document the rationale for each exception and note which alternative support you provide.
Path-based input
Some functions require input based on movement path (not just endpoints), like freehand drawing.
Requirement
If the function inherently requires path, it may be exempt—but provide alternatives where possible.
Overview
Everything users can do with a mouse or touch must also be doable using a keyboard—without requiring precise timed keystrokes. The only exception is when the task inherently depends on path-based movement (like freehand drawing).
- Use native HTML controls whenever possible; they include keyboard support by default.
- For custom components, implement expected keyboard patterns (Enter/Space to activate, Arrow keys to navigate).
- Ensure focus is visible and moves logically as users interact.
- Provide keyboard alternatives for pointer gestures (including dragging).
Reference: All summaries and highlights originate from Understanding WCAG 2.1.1 and the W3C quick reference.
Fast facts
- Conformance level
- Level A
- WCAG version introduced
- WCAG 2.0
- Principle
- Operable
- Guideline
- 2.1 · Keyboard Accessible
Examples
Make success tangible for teams
Share pass/fail snapshots to coach designers, engineers, QA, and content authors.
Custom dropdown
Pass
Opens with Enter/Space, navigates options with Arrow keys, selects with Enter, closes with Escape.
Fail
Opens only on mouse click and cannot be operated with keyboard.
Drag-and-drop
Pass
Provides keyboard reordering controls (“Move up/down”) in addition to drag.
Fail
Requires dragging with a mouse with no keyboard alternative.
Button
Pass
Uses `<button>` and activates with Enter/Space by default.
Fail
Clickable `<div>` without key handlers.
Evidence to keep
Document conformance decisions
Capture artifacts for VPATs, procurement reviews, and regression testing.
- Document keyboard interactions for custom components (keys and expected behavior).
- Maintain a checklist of required keyboard behaviors per widget type.
Official resources
Deep dives and supporting material
Keep these links handy when writing acceptance criteria or responding to audits.
Implementation checklist
Capture progress and blockers
- Inventory all interactive features and confirm each has keyboard operation.
- Prefer native controls (`button`, `a`, `input`, `select`) over div-based controls.
- Add keyboard handlers and ARIA roles/states for custom widgets.
- Support standard interaction keys: Tab, Shift+Tab, Enter, Space, Escape, Arrow keys.
- Ensure focus order is logical and matches the intended task flow.
- Provide keyboard alternatives for pointer-only actions (dragging, drawing, hover-only).
Testing ideas
Prove conformance with evidence
- Unplug the mouse/trackpad and complete core workflows using only keyboard.
- Tab through the page and verify all interactive elements are reachable.
- Operate custom widgets with expected keyboard commands and verify states change properly.
- Verify there are no timed keystroke requirements for operation.
- Test with a screen reader to confirm controls are operable and properly announced.
Related success criteria