What Is Manual Keyboard Accessibility Testing?
Manual keyboard accessibility testing evaluates whether users can fully interact with a website or application using only a keyboard. This testing is essential for people who cannot use a mouse because of mobility impairments, tremors or temporary injuries, and for people who rely on assistive technologies such as screen readers, switch devices and voice control, which all depend on keyboard access under the hood.
Accessibility specialists navigate through all functionality using keyboard commands such as Tab, Shift + Tab, Enter, Spacebar, Escape and the Arrow keys to verify that every interactive element can be reached, seen and operated.
Keyboard accessibility is a fundamental requirement of WCAG compliance and plays a critical role in creating inclusive digital experiences. It is also one of the quickest checks anyone can do; the W3C includes it in its Easy Checks for a first review of a page.
Why Keyboard Accessibility Testing Is Important
Many accessibility barriers only become apparent when navigating without a mouse.
Ensures Equal Access for Keyboard Users
Users who rely on keyboards must be able to use menus, forms, buttons, modal dialogs and other interactive elements without limitations. If one step of a checkout cannot be reached with the keyboard, the whole journey fails.
Supports Accessibility Compliance
WCAG requires that all functionality be operable through a keyboard interface, making keyboard testing a critical part of compliance efforts. Several success criteria depend on it, as the map below shows.
Improves Overall Usability
Well-designed keyboard navigation benefits power users, developers and anyone who wants to move through content efficiently.
WCAG Success Criteria Covered by Keyboard Testing
| Criterion | Level | What to check |
|---|---|---|
| 2.1.1 Keyboard | A | Every function works with the keyboard alone, without specific timing. |
| 2.1.2 No Keyboard Trap | A | Focus can always move away from a component using standard keys (or users are told how). |
| 2.1.4 Character Key Shortcuts | A | Single-key shortcuts can be turned off or remapped, or only work when the component has focus. |
| 2.4.1 Bypass Blocks | A | A skip link or landmarks let users bypass repeated navigation. |
| 2.4.3 Focus Order | A | Focus moves in an order that preserves meaning and operability. |
| 2.4.7 Focus Visible | AA | There is a visible focus indicator on every focusable element. |
| 2.4.11 Focus Not Obscured (Minimum) | AA | New in WCAG 2.2: the focused element is not entirely hidden by sticky headers, cookie banners or other author-created content. |
How to Do Manual Keyboard Accessibility Testing: Step by Step
- Put the mouse away. Unplug it or move it out of reach, and turn off the trackpad if you can. On a Mac, turn on keyboard navigation in System Settings and, in Safari, enable “Press Tab to highlight each item” so links are included in the tab order.
- Load the page and press Tab once. The first focusable item should usually be a “Skip to main content” link. Activate it with Enter and confirm focus lands at the start of the main content.
- Tab forward through the whole page, then Shift + Tab back. Check that every link, button and form field receives focus, that focus is always visible, that the order follows the visual layout, and that nothing invisible (such as off-screen menu items) takes focus.
- Operate each control with its expected keys (see the table below): Enter for links, Enter or Space for buttons, Space for checkboxes, arrows for radio groups, tabs, sliders and menus, and Escape to close.
- Test menus, dialogs and forms in every state. Open each dropdown and modal, fill in and submit each form with errors, and expand accordions.
- Check focus return. When a dialog or menu closes, focus should go back to the control that opened it. When an item is deleted, focus should move somewhere sensible, not to the top of the page.
- Check for traps and obscured focus. Make sure you can Tab out of embedded media, maps, chat widgets and iframes, and that sticky headers, footers or banners never completely cover the focused element as you scroll with Tab.
- Record each failure with the element, what happened, what should happen and the WCAG criterion.
Expected Keys by Control Type
| Control | Expected keyboard behaviour |
|---|---|
| Link | Enter activates. |
| Button | Enter or Space activates. |
| Checkbox | Space toggles. |
| Radio group | Tab into the group, arrow keys move between options. |
| Select / listbox | Arrow keys change the option; Enter or Space opens a native select on some platforms. |
| Tabs | Tab moves into the tab list; Left and Right arrows move between tabs. |
| Menu button / dropdown | Enter or Space opens; Escape closes and returns focus to the button. |
| Modal dialog | Focus moves inside; Tab stays within the dialog; Escape closes. |
| Slider | Arrow keys change the value; Home and End jump to min and max. |
Custom widgets should follow the matching WAI-ARIA Authoring Practices patterns. WebAIM’s keyboard accessibility article and web.dev’s guide to manual accessibility testing are good references for what users expect.
Common Issues Found During Keyboard Testing
Manual keyboard testing often uncovers accessibility problems that automated tools cannot detect.
Keyboard Traps
Users become stuck inside a component, such as an embedded video player, date picker or third-party widget, and cannot move away using standard keys.
Missing Focus Indicators
Interactive elements have no visible focus state, often because of a CSS reset that removes the outline, making navigation guesswork.
Incorrect Tab Order
Focus moves through content in a confusing or illogical order, usually because of positive tabindex values or CSS that rearranges content visually.
Mouse-Only Controls
Clickable div or span elements, hover-only menus and drag-only interactions cannot be reached or used with the keyboard.
Focus Lost After Interaction
After a dialog closes or content updates, focus jumps to the top of the page or disappears. These issues also confuse screen reader users, so it is worth confirming them with screen reader testing.
Focus Hidden Behind Sticky Elements
Fixed headers, chat buttons and cookie banners cover the focused element, failing WCAG 2.2’s Focus Not Obscured criterion.
Manual Keyboard Testing vs Automated Testing
Automated accessibility testing can flag some keyboard-related code problems, such as positive tabindex values or interactive elements with no role. It cannot tell whether focus order makes sense, whether a focus indicator is visible against the background, whether a widget responds to the right keys, or whether a trap exists. Those need a person with a keyboard. Run automated scans first, then use manual keyboard testing on every template and key journey.
Manual Keyboard Accessibility Testing Checklist
- Skip link is first, visible on focus and works.
- Every interactive element is reachable with Tab and Shift + Tab.
- Focus is always visible and never fully hidden by sticky content.
- Focus order follows the visual and logical order.
- Every control works with its expected keys.
- Menus and dialogs open, close with Escape and return focus.
- No keyboard traps in widgets, media or iframes.
- Hidden and off-screen content does not take focus.
- Single-key shortcuts can be turned off or remapped.
- Forms can be completed and submitted, and errors can be reached.
On phones and tablets, external keyboards and switch devices also rely on the same focus behaviour; our mobile accessibility testing guide covers those checks, and our document accessibility testing guide covers PDFs and forms. Comprehensive keyboard testing helps organizations create more accessible and user-friendly digital products.
Work With Us
If you’re not sure your site is fully keyboard-operable, our accessibility audit tests exactly that, with severity-ranked findings you can hand straight to your developers.
Get a free accessibility needs assessment — no commitment required.
