# Keyboard Accessibility Testing: A Step-by-Step Guide

Source: https://accessibilityscore.in/keyboard-accessibility-testing
Last reviewed: 2026-10-16 by the HalfAccessible accessibility team

Many people never use a mouse: people who are blind and use screen readers, people with tremors or limited mobility, and power users. Keyboard testing is the fastest manual accessibility check you can do. This guide shows how to do it and which WCAG criteria it covers.

## Short answer
Keyboard accessibility testing checks that every link, control and task on a page works with a keyboard alone. Put the mouse aside, press Tab and Shift+Tab to move, Enter and Space to activate, arrow keys inside widgets and Escape to close. Focus must always be visible, follow a logical order and never get trapped.

## Key facts

- **Core WCAG criteria:** 2.1.1 Keyboard (A), 2.1.2 No Keyboard Trap (A), 2.4.3 Focus Order (A), 2.4.7 Focus Visible (AA)
- **Added in WCAG 2.2:** 2.4.11 Focus Not Obscured (Minimum), Level AA
- **Time for a first pass:** About 10 minutes per page template
- **Tools needed:** A keyboard and a browser; no software to install
- **What automation can check:** Some signals, such as missing focus styles and unreachable scrollable regions
- **What only people can check:** Whether every task can be completed, in a logical order, without traps

## Why does keyboard accessibility matter?

If a control cannot be reached or used with a keyboard, it cannot be used by screen reader users, by people using switch devices or voice control that emulate keys, or by anyone who cannot use a mouse precisely. Keyboard access is also a foundation: if it is broken, most other assistive technology fails too.

WCAG 2.1.1 Keyboard is a Level A criterion, the most basic level, and keyboard failures are among the most common blockers found in manual audits.

## How do you test a page with the keyboard?

Click the browser address bar, then put the mouse away and work through the page:

- Press Tab repeatedly from the top. Every link, button, field and control should receive focus, in an order that follows the visual layout.
- Watch the focus indicator at every step. You should always be able to see where focus is, and it should never be hidden under a sticky header, cookie banner or chat widget.
- Press Shift+Tab to go back. Focus should retrace the same path.
- Activate links with Enter, and buttons with Enter and Space.
- Inside menus, tabs, radio groups and sliders, use the arrow keys.
- Open dialogs and menus, then press Escape. They should close and return focus to the control that opened them.
- Complete a real task, such as a search, a sign-up form or a checkout, without touching the mouse.

## What are the most common keyboard accessibility failures?

These problems turn up again and again in audits:

- Custom controls built from div or span elements that cannot be focused or activated
- Focus outlines removed with CSS (outline: none) and no replacement
- Keyboard traps, often in embedded media players, date pickers and third-party widgets
- Modal dialogs that let focus escape behind them, or do not close with Escape
- Positive tabindex values that scramble the tab order
- Menus and tooltips that open only on mouse hover
- Focus hidden behind sticky headers or footers
- Single-key shortcuts that fire while typing, without a way to turn them off (2.1.4)

## Can automated tools test keyboard accessibility?

Only partly. Tools can spot some signals: AccessibilityScore.in checks whether interactive elements show a visible change when they receive focus (2.4.7), and axe-core flags issues such as scrollable regions that cannot be reached by keyboard and interactive controls nested inside each other.

No tool can confirm that every task can be completed in a sensible order without traps, because that depends on behaviour over a sequence of key presses. Use a scan to catch the obvious problems, then do the manual walk-through above.

## Keys to test and what they should do

| Key | What it should do | Common failure |
| --- | --- | --- |
| Tab | Move focus to the next interactive element | Custom controls skipped; focus order jumps around |
| Shift+Tab | Move focus to the previous element | Focus jumps to an unexpected place |
| Enter | Follow a link or activate a button | Clickable div or span does nothing |
| Space | Activate a button; toggle a checkbox | Page scrolls instead of activating a custom button |
| Arrow keys | Move within menus, tabs, radio groups, sliders and listboxes | Each option is a separate Tab stop, or arrows do nothing |
| Escape | Close a dialog, menu or popup and return focus | Dialog stays open, or focus is lost |

## Common questions

### What is a keyboard trap?
A component that focus can enter with the keyboard but cannot leave with standard keys such as Tab, Shift+Tab or Escape. WCAG 2.1.2 No Keyboard Trap forbids it at Level A.

### Which WCAG criteria cover keyboard accessibility?
Mainly 2.1.1 Keyboard, 2.1.2 No Keyboard Trap, 2.1.4 Character Key Shortcuts, 2.4.3 Focus Order, 2.4.7 Focus Visible and, in WCAG 2.2, 2.4.11 Focus Not Obscured (Minimum).

### Is it acceptable to remove the focus outline?
Only if you replace it with another clearly visible focus style. Removing it without a replacement fails WCAG 2.4.7 Focus Visible.

### Should every element be focusable?
No. Only interactive elements, such as links, buttons and form controls, should be in the tab order. Making headings or paragraphs focusable adds noise for keyboard users.

### How do I test keyboard access on a Mac?
Turn on Keyboard navigation in System Settings, and in Safari enable Press Tab to highlight each item on a webpage. Other browsers on macOS follow the system setting.

### Does keyboard testing replace screen reader testing?
No. Keyboard testing checks that everything can be reached and operated; screen reader testing checks that it is announced in a meaningful way. Do both.

## Sources

1. [W3C WAI: Understanding 2.1.1 Keyboard](https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html)
2. [W3C WAI: Understanding 2.1.2 No Keyboard Trap](https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap.html)
3. [W3C WAI: Understanding 2.4.7 Focus Visible](https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html)
4. [W3C WAI: Understanding 2.4.11 Focus Not Obscured (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html)
5. [W3C WAI-ARIA Authoring Practices: Developing a keyboard interface](https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/)
6. [WebAIM: Keyboard accessibility](https://webaim.org/techniques/keyboard/)

Run a free accessibility score: https://accessibilityscore.in