Accessibility guide
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.
Last reviewed by the HalfAccessible accessibility team
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.
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.
Click the browser address bar, then put the mouse away and work through the page:
These problems turn up again and again in audits:
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.
| 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 |
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.
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).
Only if you replace it with another clearly visible focus style. Removing it without a replacement fails WCAG 2.4.7 Focus Visible.
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.
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.
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.