WCAG 2.1.1 requires that everything a mouse user can do on a page can also be done with a keyboard alone, with no need for precise timing on any key, and only path-dependent tasks like freehand drawing are exempt. It is Level A and one of the first things every auditor checks, because a single unreachable button can block a whole journey.
This guide covers who needs it, the keys people expect, a mouse-free test, the failures we see in web applications and the rules that sit beside it. For the wider set of tests, see accessibility testing.
Quick facts
Level
AAdded in
WCAG 2.0Principle
Operable, guideline 2.1 Keyboard accessibleException
Only functions that depend on the path of movement, like freehand drawingFast test
Put the mouse away and finish a full task with Tab, Enter, Space and arrowsHelps most
Blind users, people with motor disabilities, switch and voice users
What WCAG 2.1.1 covers
Every function on the page must be usable through a keyboard interface. That includes the obvious things, like links and buttons, and the less obvious ones: custom dropdowns, sliders, tabs, tooltips, video controls, chat widgets and drag and drop. The rule also says users must not need precise timing for each key press. You cannot require someone to hold a key for exactly two seconds.
There is one narrow exception: functions where the path of movement matters, such as freehand drawing or a signature pad. Moving a box around a diagram editor is not exempt, because arrow keys can move it. W3C sums it up as functionality that is "operable through a keyboard interface" (WCAG 2.2, 2.1.1).
"Keyboard interface" includes more than physical keyboards. Switch devices, sip and puff controls, some voice software and on-screen keyboards all send key presses, so keyboard support serves them too.
Who works the web without a mouse
Blind people use the keyboard because a mouse needs sight to aim. People with tremors, limited hand movement or paralysis often find a pointer too precise and use a keyboard, a switch or a mouth stick instead. Many power users simply prefer keys. People with repetitive strain injury switch to the keyboard to rest their wrist. A screen reader adds its own key commands on top, but it still depends on the page responding to standard keys.
The keys people expect to work
| Key | Expected action |
|---|---|
| Tab | Move to the next link, button or field |
| Shift+Tab | Move back one item |
| Enter | Follow a link, press a button, submit a form |
| Space | Press a button, tick a checkbox, scroll the page |
| Arrow keys | Move within radio groups, menus, tabs, sliders and selects |
| Escape | Close a dialog, menu or popup |
| Home and End | Jump to first or last item in some widgets |
Custom widgets should follow the keyboard patterns W3C documents in its ARIA Authoring Practices Guide, so users meet the keys they already know.
WCAG keyboard accessibility testing, step by step
No scanner can prove that every function works from the keyboard. This is a hands-on test, and it is one of the best value checks in any audit.
- Put the mouse away. Click once in the address bar, then do not touch the mouse or trackpad again until the test is over.
- Tab through the whole page. Press Tab repeatedly and confirm that every link, button, field and custom control receives focus at some point.
- Operate each control. Use Enter, Space, the arrow keys and Escape to open menus, tick boxes, change tabs, play media and close dialogs.
- Complete a real task. Finish a full journey, such as signing up, searching or checking out, without the mouse.
- Try the tricky parts. Test hover menus, sliders, carousels, date pickers, drag and drop, maps and embedded players separately.
- Note anything stuck or skipped. Record each control you could not reach or use, and anywhere focus got stuck, noting the page and how to reproduce it.
On a Mac, Safari skips links when you press Tab unless you turn on Safari, Settings, Advanced, Press Tab to highlight each item on a webpage. Otherwise use Option+Tab, or test in Chrome or Firefox.
Keyboard accessibility in web applications: where it breaks
| Pattern | What happens | Fix |
|---|---|---|
| Clickable div posing as a button | Cannot be reached or pressed | Use a button element |
Link with no href | Skipped by Tab | Add a real href, or use a button for actions |
| Menu that opens only on mouse hover | Submenu never appears for keyboard users | Open on focus or with Enter, Space and arrow keys |
| Custom select or date picker | Arrow keys do nothing | Use the native control, or follow the APG pattern |
| Drag and drop only | Items cannot be moved | Add buttons such as Move up and Move down |
tabindex="-1" on interactive items | Removed from the Tab order | Remove it, or use 0 for custom controls |
| Embedded player or map with no key support | Controls cannot be used | Pick a component with keyboard support or provide another way |
A clickable div versus a real button
Fails: the div looks like a button and responds to clicks from a script, but it cannot receive focus or respond to Enter and Space.
<div class="btn">Add to basket</div>Passes: the native button gets focus, Enter and Space, and the right role, with no extra code.
<button type="button" class="btn">Add to basket</button>If you truly must build a custom control, you need tabindex="0", a role, key handlers for Enter and Space, and visible focus. That is four jobs the native element already does. The name, role and value guide explains the role part.
Keyboard wcag rules that travel together
- 2.1.2 (A) deals with traps: you can reach a control, but can you leave it? Focus must never get stuck in a widget, an embedded frame or a modal.
- 2.1.4 (A, from WCAG 2.1) covers single-letter shortcuts, which must be possible to switch off or remap, so voice users do not trigger them by accident.
- 2.1.3, the AAA version, removes the path exception altogether.
- 2.4.3 and 2.4.7 make sure the order makes sense and the focus is visible; see focus order and focus visible.
- 2.5.7 (AA, from WCAG 2.2) asks for a single-pointer option whenever a task uses dragging; a keyboard option alone does not meet it.
For worked examples and techniques, read Understanding Keyboard on the W3C site.
Questions people ask
What does wcag 2.1.1 keyboard require?
All functionality must work with a keyboard alone, without needing specific timing for each key press. Only functions that depend on the path of movement, such as freehand drawing, are exempt. It is Level A.
Is 2.1.1 wcag just another name for WCAG 2.1?
No. 2.1.1 is the number of a success criterion: principle 2, guideline 2.1, criterion 1. WCAG 2.1 is a version of the standard. The keyboard criterion has existed since WCAG 2.0.
Do mobile apps and touch sites need keyboard support?
Yes. People connect keyboards and switch devices to phones and tablets, and screen readers on touch devices also rely on keyboard-like actions. The rule applies to web content on any device.
Does a hover menu fail keyboard accessibility wcag rules?
It fails if the submenu cannot be opened or used from the keyboard. Make it open on focus, or with Enter or Space on a button that toggles it, and let arrow keys or Tab move through the items.
Is a drag and drop interface allowed?
Yes, if every drag action also has a keyboard method, such as Move up and Move down buttons or a menu to choose a position. Under WCAG 2.2 you also need a single-pointer method for 2.5.7.
Can I test wcag keyboard access with an automated tool?
Only partly. Tools can find a few signs, like clickable divs or negative tabindex. Whether each function really works needs a person pressing keys.