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.
Keyboard Accessibility Requirements At A Glance
- Level A: WCAG 2.1.1 Keyboard: every function must work with the keyboard alone, with no path that needs a mouse or a timed keystroke (Source: W3C, WCAG 2.2 SC 2.1.1 (opens in a new tab))
- 2.4.11: Focus Not Obscured (Minimum), new at Level AA in WCAG 2.2: the focused control must not be entirely hidden by sticky headers, banners or other author content (Source: W3C, WCAG 2.2 SC 2.4.11 (opens in a new tab))
- 18.2%: Of U.S. adults report any difficulty walking or climbing steps; many keyboard, switch and voice users depend on the same keyboard interface (Source: CDC NCHS FastStats, NHIS 2024 (opens in a new tab))
- Easy Checks: W3C lists keyboard access in its preliminary Easy Checks, so teams can start this review before a full audit (Source: W3C WAI Easy Checks (opens in a new tab))
Choose Your Next Step
Want a quick first look at a page before a full keyboard pass? Run a free scan on AccessibilityScore.in (opens in a new tab); it is a starting point that complements manual keyboard testing, not a replacement. For a full manual WCAG 2.2 AA audit of up to 25 templates or key user flows, see the $2,000 Complete Audit on our pricing page or our accessibility audit services.
Free 30-Minute Call
Best for: first conversations, scoping and quotes
Tell us which templates and journeys matter most and whether you need a keyboard-only pass, a full WCAG audit or help fixing traps and focus bugs. We send a quote. No technical prep needed.
Book a free 30-minute call (opens in a new tab)
$500 Quick Audit
Best for: small sites that want a first keyboard and screen reader check
Up to 5 page templates with automated scans plus manual keyboard and screen reader spot checks, a top-10 issues report mapped to WCAG 2.2 and a 30-minute review call.
$100 Technical Consultation
Best for: developers stuck on a focus trap, tab order bug or audit finding
A one-hour working session to walk through findings, talk with your developer, or review focus, dialogs and custom widgets live on the 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. These are the failures we see most often, with the WCAG criterion each one maps to.
| Issue | What users run into | How to fix it |
|---|---|---|
| Keyboard traps WCAG 2.1.2 |
Focus gets stuck inside a video player, date picker, chat widget or iframe and cannot move away with Tab or Escape. | Keep a standard exit path with Tab, Shift + Tab or Escape, or tell the user how to leave before they enter. |
| Missing focus indicators WCAG 2.4.7 |
Interactive elements have no visible focus ring, often after a CSS reset removes the outline, so keyboard users lose their place. | Keep a high-contrast :focus-visible style on every focusable control; never remove outlines without a replacement. |
| Incorrect tab order WCAG 2.4.3 |
Focus jumps around the page in a confusing order, usually from positive tabindex values or CSS that rearranges content visually. | Keep DOM order matching the visual reading order; avoid positive tabindex. |
| Mouse-only controls WCAG 2.1.1 |
Clickable div or span elements, hover-only menus and drag-only interactions cannot be reached or used with the keyboard. | Use real buttons and links, or add keyboard handlers and an accessible name that match the WAI-ARIA APG patterns. |
| Focus lost after interaction WCAG 2.4.3 |
After a dialog closes or content updates, focus jumps to the top of the page or disappears. Screen reader users hit the same bug; confirm with screen reader testing. | Return focus to the control that opened the dialog, or to the next sensible item after a delete or update. |
| Focus hidden behind sticky elements WCAG 2.4.11 |
Fixed headers, chat buttons and cookie banners completely cover the focused element as you Tab. | Use scroll-padding, shrink sticky layers, or make banners modal so the focused control stays at least partly visible. |
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
Want your site tested with a real keyboard, not only a scanner? Founder Mohammad Shadab Saifi (CPACC, WAS, CPWA, DHS Trusted Tester, 10+ years) leads our WCAG 2.2 accessibility audits, which include a full manual keyboard pass on every template and key journey. See what you receive in our sample audit report.
New to this? Book a free 30-minute call to talk through where you stand and get a quote, or get a free accessibility needs assessment with no commitment. If your developer needs hands-on technical answers now, book the $100 one-hour technical consultation.
