WCAG 2.1 · Level A · Operable
WCAG 2.1.1 — Keyboard, explained with examples
Every interactive function on the page must be operable using only the keyboard. Mouse-only interaction excludes anyone using a screen reader, switch device, voice control, or who has tremor or limited mobility. Keyboard support is the prerequisite for almost every other assistive technology.
- Number
- 2.1.1
- Level
- A
- Principle
- Operable
- Guideline
- 2.1 Keyboard Accessible
Why this criterion exists
Mouse-only interaction excludes anyone using a screen reader, switch device, voice control, or who has tremor or limited mobility. Keyboard support is the prerequisite for almost every other assistive technology.
If you only remember one thing: every interactive function on the page must be operable using only the keyboard. Everything else on this page is detail.
Who feels it when this fails
Accessibility criteria sometimes feel abstract until you see who pays the cost when a site ignores them. Keyboard affects:
Screen reader users
Users with motor impairments
Users who prefer keyboard for speed (developers, power users)
Voice control users (relies on keyboard pathways)
How sites typically fail it
These are the patterns we see week after week. None are intentional — they are accidents of how teams build interfaces under deadline. Knowing the failure modes is the fastest path to writing them out of your component library.
Custom dropdowns implemented with click handlers and no keyboard
<div onclick="..."> instead of <button>
Hover-only menus that never receive focus
Drag-and-drop interactions without keyboard alternative
How to test for it
Tab through the entire page; every control must be reachable.
Activate each control with Enter or Space.
Trigger menus with Arrow keys; close with Esc.
Automated scanners catch this criterion most of the time, but never all of the time. Manual testing with the keyboard and a screen reader closes the gap.
A code fix you can copy
<button> gives you free Enter/Space activation, focus visibility, and the right ARIA role. Reach for native elements before custom roles.
The problem
<div onclick="open()">Open menu</div>The fix
<button type="button" onclick="open()">Open menu</button><button> gives you free Enter/Space activation, focus visibility, and the right ARIA role. Reach for native elements before custom roles.
Frequently asked questions
Are mouse-only games subject to 2.1.1?
Yes, with a narrow exception. WCAG 2.1.1 allows mouse-required interaction only when the activity itself is fundamentally impossible with a keyboard — such as free-form drawing or handwriting recognition. Even then, an alternative path must be available for the same information or function. Chess, form filling, navigation, and menus never qualify for that exception.
Has keyboard inaccessibility caused real lawsuits?
Keyboard accessibility is central to nearly every high-profile web ADA case. In Gil v. Winn-Dixie (2017), keyboard navigation was among the cited failures. In National Federation of the Blind v. Target Corp. (2006), keyboard inaccessibility was a core finding. The pattern is consistent: if a screen reader user cannot tab through your site, you have a strong exposure to ADA litigation under Title III.
Do I need to support every keyboard shortcut, or just Tab and Enter?
At minimum: Tab to reach every interactive element, Enter to activate links and buttons, Space to toggle checkboxes and activate buttons, Escape to close dialogs, and Arrow keys for composite widgets (menus, tabs, radio groups, sliders). ARIA Authoring Practices Guide documents the full keyboard pattern for each widget type.
What about drag-and-drop interfaces?
Drag-and-drop must have a keyboard alternative. This can be as simple as a cut/paste keyboard operation, an "up/down" button to reorder items, or a modal picker. The drag-and-drop gesture itself does not need to work from the keyboard — the function it performs must be achievable some other way without using a mouse.
How does 2.1.1 relate to the European Accessibility Act?
The EAA mandates WCAG 2.1 Level AA via EN 301 549. Keyboard accessibility (2.1.1) is a Level A criterion, meaning it is part of both AA and A conformance. Any consumer-facing EU site that fails keyboard access fails the EAA. Enforcement bodies in Germany and France began active audits in 2025 using WCAG as the technical baseline.
Other Operable criteria
2.1.2 No Keyboard Trap
Operable · Level A
2.4.3 Focus Order
Operable · Level A
2.4.4 Link Purpose (In Context)
Operable · Level A
2.4.6 Headings and Labels
Operable · Level AA
All WCAG 2.1 criteria
Browse the full index by principle
Complete WCAG 2.1 guide
POUR principles, conformance levels, legal requirements
Find every accessibility issue on your site in 60 seconds.
Free public scan. No card. AI-generated fixes for every issue we find.