# Keyboard Navigation: WCAG 2.1.1 Explained

Source: https://allyway.ai/glossary/keyboard-navigation

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](https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html) is a Level A criterion of [WCAG 2.2](https://allyway.ai/regulations/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](https://allyway.ai/regulations/en-301-549) (clause 9.2.1.1), it also applies under the [European Accessibility Act](https://allyway.ai/regulations/eaa).

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.

> **Note:** > **Mouse support stays welcome**
> WCAG does not ask you to remove mouse or touch input. It only asks that the keyboard can do the same job – for example a cut-and-paste or "Move to" button next to drag and drop.

## 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.

```html title="Example"
<!-- 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>
```

**Do:** Do

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.

**Don't:** Don't

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](https://allyway.ai/glossary/keyboard-trap) – and focus that moves but cannot be seen, which fails [focus visible](https://allyway.ai/glossary/focus-visible). A [skip link](https://allyway.ai/glossary/skip-link) saves keyboard users from tabbing through the whole menu on every page.

## How to test keyboard navigation



## Questions

Q: What is keyboard navigation in web accessibility?
A: 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.

Q: Which keys should work for keyboard accessibility?
A: 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.

Q: Does WCAG 2.1.1 apply to drag and drop?
A: 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.

Q: Is tabindex needed for keyboard navigation?
A: 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.

Q: How can I find keyboard problems on my website?
A: 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](https://allyway.ai/free-wcag-accessibility-scanner-for-websites) and fix the reported issues first.