2.1.1 Keyboard
- Level A
- Operable
- Since WCAG 2.0
Summary
This criterion protects everyone who cannot use, or chooses not to use, a pointer: people with tremors or limited motor control, people who are blind (screen readers drive the interface through the keyboard), switch access users whose devices emulate keystrokes, and people with repetitive strain injuries. If any function on the page or screen can only be reached or triggered with a mouse, trackpad, or touch gesture, those users are locked out of it entirely, not merely inconvenienced.
The auditor's mental model is a full sweep with the pointer set aside: every function, not just navigation, must be operable through a keyboard interface, and no keystroke may demand precise timing. The only exception is genuinely path-dependent input, where the journey of the movement matters and not just its endpoints: freehand drawing or handwriting is the classic case. The exception is narrow. Dragging a file to a folder, reordering a list, or panning a map all have defined endpoints, so they get no exemption; the function needs a keyboard route. Note also that "keyboard interface" includes external keyboards connected to phones and tablets, so this criterion applies with full force to native mobile apps.
Official wording
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.
EN 301 549 mapping
- Web pages
- Clause 9.2.1.1
- Software and native apps
- Clause 11.2.1.1
- Closed functionality (kiosks, terminals)
Systems closed to keyboards must be operable without a keyboard interface (clause 5.1.6.1).
Clause 9.2.1.1 applies this criterion to web pages unchanged and clause 11.2.1.1 applies it to software with keyboard access. Systems closed to keyboards must instead be operable without a keyboard interface under clause 5.1.6.1.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
Put the mouse out of reach and traverse the whole page. Tab and Shift+Tab move between controls, arrow keys move within composite widgets (menus, radio groups, tabs, sliders), Enter activates links and buttons, Space toggles buttons and checkboxes, and Escape dismisses dialogs and menus. Every function you found earlier with the pointer must be achievable in this sweep. On macOS, first enable full keyboard navigation (Safari's "Press Tab to highlight each item" preference, or the system keyboard navigation setting), otherwise Safari skips links and you will record false failures.
The usual web failure spots are custom widgets and hover-only interactions. A dropdown, date picker, accordion, or slider built from div and span elements receives no keyboard behaviour for free: check in browser developer tools for tabindex and keyboard event listeners alongside the click handlers. Menus and tooltips that appear only on mouseover with no matching focus behaviour hide their content from keyboard users. Drag-and-drop interfaces (file upload zones, sortable lists, kanban boards) fail when dragging is the only route and there is no keyboard-operable alternative such as move buttons or a cut-and-paste pattern. Also confirm that nothing requires held or rapidly repeated keys: timing-dependent keystrokes fail even when the key itself works.
iOS
Test with a hardware keyboard connected, most conveniently on an iPad, with Full Keyboard Access enabled (Settings, Accessibility, Keyboards, Full Keyboard Access). FKA lets you move focus with Tab and arrow keys and activate with Space, and it exposes gesture substitutes through its own menus. Sweep every screen: standard UIKit and SwiftUI controls are focusable by default, but custom controls drawn with gesture recognisers or bare views frequently are not, and anything FKA cannot reach or activate is a failure. Watch for swipe-only interactions (custom carousels, swipe-to-reveal row actions with no alternative) and controls that respond only to touch events rather than the accessibility activation path.
On iPad, also check any app-defined keyboard shortcuts work as advertised (hold the Command key to display the shortcut overlay). The European standard applies this requirement to software wherever keyboard access is supported; a system genuinely closed to keyboards must instead be operable without one, but a consumer iOS app, which supports external keyboards through the platform, does not qualify as closed.
Android
Connect a Bluetooth or USB keyboard, or use a d-pad or the directional controls in an emulator, and sweep each screen: Tab and the arrow keys move focus, Enter or the d-pad centre key activates. Standard views and Material components handle this natively. Custom views are the risk: a view that only overrides onTouchEvent is invisible to keyboard users unless it is also focusable and handles key or click events (isFocusable, onKeyDown, or routing activation through performClick). In Jetpack Compose, the clickable modifier provides focus and key handling, but custom pointer-input modifiers do not: check for focusable and key event handling on anything hand-rolled. Layout Inspector helps confirm whether a suspect view is focusable at all.
Common Android failure spots: swipe-to-dismiss or swipe-to-action list items with no keyboard-reachable equivalent, custom sliders and rating bars that ignore arrow keys, image carousels driven purely by touch gestures, and custom bottom sheets that can be opened by keyboard but only closed by dragging. As on iOS, the European standard expects keyboard operability wherever the platform supports keyboard access, which mainstream Android does.
Pass and fail examples
Passes:
- A custom dropdown that opens with Enter, moves through options with arrow keys, selects with Enter, and closes with Escape.
- A sortable list where each item offers keyboard-operable "move up" and "move down" actions alongside drag-and-drop.
- A navigation menu that opens both on hover and on keyboard focus, and can be traversed with arrow keys.
- A signature field in a contract app that captures freehand pen strokes: the underlying function is path-dependent, so the exception applies to the stroke input itself.
- An Android list row with swipe-to-archive that also exposes an archive action reachable with a connected keyboard.
Fails:
- A "mega menu" that opens only on mouseover: keyboard focus lands on the top-level link and the submenu never appears.
- A star rating widget built from clickable
divelements with notabindexand no key handling: the pointer can rate, the keyboard cannot. - A kanban board where cards move between columns only by dragging, with no keyboard route: the endpoints define the function, so the path exception does not apply.
- An iOS custom toggle drawn with a tap gesture recogniser that Full Keyboard Access can focus but not activate.
- A game-style interaction requiring a key to be pressed twice within half a second: specific timing for individual keystrokes fails even though a keyboard is used.
Not a fail under this criterion:
- Focus reaches every control but you cannot see where it is: a missing or invisible indicator belongs to SC 2.4.7 Focus Visible.
- Keyboard focus enters a widget and cannot leave it: that is SC 2.1.2 No Keyboard Trap.
- Everything is operable but the Tab sequence jumps around illogically: sequence problems belong to SC 2.4.3 Focus Order.
- A dragging interaction that works by keyboard but has no single-pointer alternative: grade that under SC 2.5.7, not here.
Commonly confused with
- SC 2.4.7 Focus Visible. 2.1.1 asks whether functions can be operated by keyboard; 2.4.7 asks whether the user can see where focus is while doing it. A page can pass one and fail the other, so record the evidence separately.
- SC 2.1.2 No Keyboard Trap. Getting stuck is not the same as being unable to operate. If focus enters an embedded widget and standard keys cannot move it out, file the trap under 2.1.2; reserve 2.1.1 for functions the keyboard cannot reach or trigger at all.
- SC 2.5.7 Dragging Movements. The two look at the same drag interactions from opposite sides. 2.1.1 demands a keyboard route; 2.5.7 demands a single-pointer alternative, and keyboard support does not satisfy it. A drag-only list reorder can fail both, and fixing one does not fix the other.
- SC 2.4.3 Focus Order. A confusing traversal sequence is a focus order finding. Under 2.1.1 the question is only whether every function is reachable and operable, however oddly ordered the journey is.
- SC 2.1.4 Character Key Shortcuts. Keyboard shortcuts that exist and collide with typing (single-character shortcuts with no remap or disable option) are a 2.1.4 finding; the absence of keyboard operability altogether is 2.1.1.
How AUDITSU tests this
The AUDITSU audit walkthrough puts a keyboard sweep into the review of every screen. For each screen you first inventory the functions available by pointer or touch, then repeat them through the keyboard interface: on web with the mouse set aside, on iOS with Full Keyboard Access, on Android with a connected keyboard. The walkthrough prompts you to check the common traps explicitly (hover-only reveals, custom widgets, drag-only interactions, timing-dependent input) and to note where a claimed path-dependence exception is really an endpoint-based function in disguise. Each check records a pass, fail, or not applicable result per screen with the evidence attached, so a control that works on one screen but not another is captured exactly where it fails.
For the full guided workflow, see the audit platform.