WCAG 2.1.1 Keyboard

What it asks

The keyboard is the one input almost every assistive technology can produce. Screen readers send keystrokes. Switch devices, on-screen keyboards and voice control software all end up sending the same thing. So if a page works from a keyboard, it works for a long list of people at once.

This rule says all functionality must be operable through a keyboard interface. Opening a menu, choosing a date, closing a dialog, playing a video, sorting a table: each must be possible with keys alone. The keys must not need specific timings either, such as holding one down for three seconds.

There is one exception. A function that depends on the path of the person’s movement, not just where it starts and ends, can stay pointer-only. Freehand drawing is the usual example. Dragging an item to a new position is not, because only the end point matters. The Level AAA version, 2.1.3 Keyboard (No Exception), removes even that exception.

It does not require that focus be visible, or that it move in a sensible order. Those are separate criteria. 2.1.1 asks only that every function is reachable and can be completed.

Its official name is success criterion 2.1.1 Keyboard, at Level A. It was added in WCAG 2.2, under guideline 2.1 Keyboard Accessible and the principle Operable. The W3C’s normative text says, in part:

“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.”

From WCAG 2.2, W3C. Full explanation: Understanding 2.1.1 Keyboard.

Who it helps

People who are blind, who cannot see where to point a mouse and use the keyboard through a screen reader. People with tremors or limited hand movement, for whom a mouse is slow or impossible but keys are workable.

People using a switch, a head pointer or voice control, whose devices present themselves to the browser as a keyboard. And anyone whose mouse has just stopped working.

What passes and what fails

These pass

• A navigation menu that opens on Enter, moves between items with the arrow keys and closes with Escape.
• A custom date picker where every day can be reached with the arrow keys and chosen with Enter, or the date can be typed into the field.
• A sortable list with "Move up" and "Move down" buttons, so items can be reordered without dragging.
• A video player whose play, pause, volume and captions controls are real buttons that respond to Enter or Space.
• A signature pad that is pointer-only, because drawing a signature depends on the path.

These fail

• A div with a click handler and no tabindex or role, so the keyboard cannot reach it at all.
• A list that can only be reordered by dragging, with no keyboard route.
• A chart or map drawn on a canvas whose controls respond only to pointer events.
• A custom select box that ignores the arrow keys, so a keyboard user can open it but never choose an option.
• A panel that can scroll but has no focusable element inside it and is not focusable itself, so keyboard users cannot reach the content below the fold.
• A "hold to confirm" button that must be pressed for two seconds, which is a specific timing.

How to test it by hand

1. Put the mouse out of reach. Load the page and press Tab until focus has visited every control. Note anything that looks interactive and is skipped.
2. At each control, try to operate it: Enter or Space for buttons and links, arrow keys inside menus, lists, tabs and sliders, Escape to close anything that opened.
3. Open every menu, dialog, accordion and tooltip and work through its contents the same way.
4. Try every task the page offers end to end: sign up, search, filter, play media, reorder, add to basket.
5. Check that nothing depends on timing, such as a long press or a double press.
6. For each function that cannot be reached or completed, note the control, what happens, and whether it genuinely depends on a drawn path.

What automated testing can decide

What a machine can decide

Some of the clearest failures are in the code. A click handler on an element with no role and no tabindex is a classic sign. A scrollable region with nothing focusable inside it, a frame whose contents have been taken out of the tab order, and a server-side image map can all be found from the page and its styles, and each of those is a defect in its own right.

Beyond that, automated testing can show which controls respond to the keyboard and which do nothing. That is the list a reviewer needs to start from.

What it cannot

A control that does nothing when Enter is pressed may have a different documented key, and a function that cannot be done at one control may be available at another. Whether every function can be completed is a question about the whole page, not one element, and whether the path exception applies is a judgement. The criterion is about functionality, and a tool that reads code only knows about elements.

How Dreven handles it

Dreven finds the controls and regions on your pages that the keyboard may not be able to use and shows you each one, with the element, the page and a picture of what was seen.

A reviewer decides each result, because deciding that a function has no keyboard route at all takes judgement, and the report says how each result was decided.

No automated check makes a site conform. In Dreven, a person reviews the results and signs the report.

Related criteria

• 2.1.2 No Keyboard Trap (Level A). Once the keyboard can get in, it must be able to get out again.
• 2.4.7 Focus Visible (Level AA). A keyboard user has to be able to see where focus is.
• 2.4.3 Focus Order (Level A). Focus must move in an order that makes sense.
• 2.5.7 Dragging Movements (Level AA). Dragging needs a single-pointer alternative too, for people using a mouse or finger who cannot drag.
• 4.1.2 Name, Role, Value (Level A). Custom controls need a role, a name and a state, so assistive technology knows what keys to send.

Questions people ask

All WCAG 2.2 criteria, in plain words