Keyboard Navigation: WCAG 2.1.1 Explained
Also called: Keyboard accessibility, Keyboard operability, Keyboard-only navigation
Definition
Keyboard navigation means that every function of a website can be reached and operated with a keyboard alone – usually with Tab, Shift+Tab, Enter, Space and the arrow keys. WCAG 2.1.1 requires it at Level A.
Keyboard navigation means that people can use every part of your website with a keyboard alone: move from link to link with Tab, open menus, fill in forms and complete a purchase without touching a mouse. If a single function only works with a pointer, keyboard users are locked out of it.
What it means
WCAG 2.1.1 Keyboard is a Level A criterion of WCAG 2.2, the lowest and most basic level. It requires that all functionality is operable through a keyboard interface "without requiring specific timings for individual keystrokes". Because it is part of EN 301 549 (clause 9.2.1.1), it also applies under the European Accessibility Act.
Keyboard accessibility matters far beyond people who press physical keys. The W3C names blind users, who cannot follow a mouse pointer, people with low vision, who may lose track of it, and people with hand tremors. Speech input, switch devices, on-screen keyboards and scanning software also send keyboard commands – so if keyboard operability fails, they fail too.
| Key | Expected behavior |
|---|---|
| Tab / Shift+Tab | Move to the next / previous link, button or form field |
| Enter | Follow a link, press a button, submit a form |
| Space | Press a button, tick a checkbox |
| Arrow keys | Move within radio groups, menus, tabs and sliders |
| Esc | Close a dialog, menu or popup |
There is one exception: functions where the result depends on the path of the movement, such as freehand drawing. Drawing straight lines, resizing a window or dragging an item to a target do not fall under it – these need a keyboard alternative.
Examples
The most common failure is a clickable element that is not a real control. A div with a click handler looks like a button, but it never receives keyboard focus.
<!-- Fails: not focusable, Enter and Space do nothing -->
<div class="btn" onclick="addToCart()">Add to cart</div>
<!-- Passes: native button, focusable and operable by default -->
<button type="button" onclick="addToCart()">Add to cart</button>
<!-- Dropdown that opens on hover only fails; open it on focus/click too -->
<button aria-expanded="false" aria-controls="shop-menu">Shop</button>
<ul id="shop-menu" hidden>…</ul>Use native <a href>, <button>, <input> and <select> elements, open menus on click or Enter as well as on hover, and offer a keyboard alternative for drag and drop and sliders.
Put click handlers on div or span, remove elements from the tab order with tabindex="-1", or hide important actions in content that only appears on mouse hover.
Two related problems often show up during keyboard testing: focus that cannot leave a widget – a keyboard trap – and focus that moves but cannot be seen, which fails focus visible. A skip link saves keyboard users from tabbing through the whole menu on every page.
How to test keyboard navigation
Questions
What is keyboard navigation in web accessibility?
It means every function of a website can be used with the keyboard alone, usually with Tab, Shift+Tab, Enter, Space, the arrow keys and Esc. WCAG 2.1.1 requires it at Level A.
Which keys should work for keyboard accessibility?
Tab and Shift+Tab move between interactive elements, Enter activates links and buttons, Space activates buttons and checkboxes, arrow keys move inside composite widgets such as tabs, and Esc closes dialogs and menus.
Does WCAG 2.1.1 apply to drag and drop?
Yes. Moving an item to a target is not path-dependent, so it needs a keyboard way to do the same thing – for example buttons to move the item up or down. Only functions like freehand drawing are exempt.
Is tabindex needed for keyboard navigation?
Usually not. Native links, buttons and form fields are focusable on their own. Use tabindex="0" only for custom widgets, and avoid positive values such as tabindex="5", because they break the natural focus order.
How can I find keyboard problems on my website?
Start with a quick manual Tab test of your key pages. To find elements that are missing roles or names across the site, run the free WCAG scanner and fix the reported issues first.
Related terms
Keyboard Trap: WCAG 2.1.2 Explained and Fixed
A keyboard trap is a part of a page that keyboard focus can enter but not leave using the keyboard alone. WCAG 2.1.2 No Keyboard Trap forbids it at Level A.
Read definition: Keyboard Trap: WCAG 2.1.2 Explained and FixedFocus Visible: WCAG 2.4.7 and Visible Focus Styles
Focus visible means that a website shows a visible indicator – usually an outline – on the link, button or field that currently has keyboard focus. WCAG 2.4.7 requires it at Level AA.
Read definition: Focus Visible: WCAG 2.4.7 and Visible Focus StylesSkip Link: Jump Straight to the Main Content
A skip link is a link at the very top of a page that jumps to the main content, so keyboard and screen reader users do not have to pass the whole menu on every page. It is a sufficient technique for WCAG 2.4.1.
Read definition: Skip Link: Jump Straight to the Main ContentIcon Button: How to Give It an Accessible Name
An icon button is a button that shows only a symbol – a magnifier, a cross, three lines – and no visible text. To be accessible it needs an accessible name in code that tells assistive technology what the button does.
Read definition: Icon Button: How to Give It an Accessible Name