Keyboard
Tier 1 · The normative floor
Baseline compliance
What the normative text of WCAG 2.2 requires, and nothing more. Only a failure of this tier is a WCAG failure.
The bare minimum
All functionality can be operated through a keyboard interface, without needing specific timing for individual keystrokes. The exception is functionality whose underlying function depends on the path of the user's movement, not just its endpoints (such as freehand drawing).
Normative text
Verbatim from WCAG 2.2, W3C Recommendation 12 December 2024. Underlined terms are defined below.
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.
Not required by the normative text
Common claims that this criterion does not support. Don't log these as WCAG failures.
- The Tab key specifically. Arrow keys and other keys count as a keyboard interface.
- A visible focus indicator. That's 2.4.7.
- Any limit on the number of keystrokes needed.
Definitions used (2)
Glossary definitions are normative. Their notes are informative.
- functionality
-
processes and outcomes achievable through user action
- keyboard interface
-
interface used by software to obtain keystroke input
Informative notes (2)
A keyboard interface allows users to provide keystroke input to programs even if the native technology does not contain a keyboard.
Operation of the application (or parts of the application) through a keyboard-operated mouse emulator, such as MouseKeys, does not qualify as operation through a keyboard interface because operation of the program is through its pointing device interface, not through its keyboard interface.
Notes in the criterion Informative
WCAG 2.2 lists notes among its informative material, which "does not create requirements that impact a conformance claim." They help interpret the criterion but are not part of the floor.
This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.
This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.
Tier 2 · The gap
Usability & user impact
Where content can meet this criterion and still make things harder for people with disabilities. These are not failures of SC 2.1.1, so raise them as usability defects. Known failures, including failures of related criteria, are listed in Tier 1.
Something can be keyboard-operable yet take dozens of Tab presses, or rely on key combinations nobody would guess.
Tier 3 · The golden path
Recommended best practice
The pattern that meets the floor, closes the gap, and avoids audit disputes. A recommendation, not a requirement.
Use native interactive elements, keep tab stops to the controls people need, and use arrow-key navigation inside composite widgets like menus, tabs and grids, following established keyboard patterns.
W3C's Understanding document and techniques for SC 2.1.1 ↗ are informative: sufficient techniques show ways to pass, and documented failures show common ways to fail, but neither changes what the criterion requires.
How SC 2.1.1 maps to the WCAG 3 draft
From this site's reviewed map to the WCAG 3 editor's draft. It's an interpretation: W3C has not published a mapping.
Successor provisions
From WCAG 2.2, section 5.1: “The main content of WCAG 2.2 is normative and defines requirements that impact conformance claims. Introductory material, appendices, sections marked as "non-normative", diagrams, examples, and notes are informative (non-normative). Non-normative material provides advisory information to help interpret the guidelines but does not create requirements that impact a conformance claim.”