Keyboard testing during an accessibility audit evaluates whether all interactive elements on a page can be operated without a mouse. This covers navigation, form inputs, menus, modals, and any component that requires user interaction. If a keyboard user cannot reach or activate an element, the audit identifies it as an issue.
| Key Point | What It Means |
|---|---|
| What It Evaluates | Whether every interactive element is reachable and operable using only a keyboard |
| Focus Visibility | Whether a visible indicator shows which element currently has keyboard focus |
| Focus Order | Whether the tab sequence follows a logical reading order through the page |
| Keyboard Traps | Whether focus gets stuck inside a component with no way to exit using the keyboard |
| Why Scans Miss This | Automated scans detect approximately 25% of issues and cannot evaluate real keyboard interaction patterns |
How Keyboard Testing Fits into the Audit Process
An accessibility audit is a human-led evaluation conducted against Web Content Accessibility Guidelines (WCAG) conformance criteria. Keyboard testing is one component of that evaluation, alongside screen reader testing, visual inspection, and code review.
Auditors use the Tab key to move through every interactive element on a page. They use Enter and Space to activate buttons and links, arrow keys to move through menus and radio groups, and Escape to close modals and dropdowns. Each interaction is evaluated against WCAG success criteria at the target conformance level, typically 2.1 AA or 2.2 AA.
What Auditors Look for During Keyboard Testing
Focus visibility is one of the first things an auditor checks. Every focused element needs a visible outline or indicator so the user knows where they are on the page. Custom styles that remove the default focus ring without replacing it are a common source of issues.
Focus order refers to the sequence in which elements receive focus as a user tabs through the page. The order should match the visual layout and reading flow. When developers rearrange elements with CSS but leave the DOM order unchanged, the tab sequence can become confusing.
Keyboard traps occur when focus enters a component and cannot leave using standard keyboard controls. Modal dialogs are a frequent location for traps, especially when the dialog does not return focus to the element that opened it after closing.
Operability means every action available to a mouse user is also available to a keyboard user. Dropdown menus, date pickers, sliders, accordions, and custom widgets all require keyboard interaction paths. If a widget only responds to mouse events, the audit identifies it as an issue.
What Automated Scans Cannot Evaluate
Automated scans can flag missing focus indicators in some cases, but they cannot simulate the experience of tabbing through a page. A scan cannot determine whether focus order is logical, whether a modal traps the user, or whether a custom component responds to the expected key commands. These require human evaluation.
Because scans only flag approximately 25% of accessibility issues, keyboard interaction problems frequently fall into the remaining 75% that require an auditor to identify.
Why Keyboard Access Affects a Large User Population
Keyboard operability is not limited to users who cannot use a mouse. People who use screen readers rely on keyboard commands to interact with pages. Users with motor disabilities may use switch devices or voice input that maps to keyboard events. Repetitive strain injuries lead some users to alternate between mouse and keyboard throughout the day.
Keyboard accessibility is a foundational layer that supports multiple assistive technologies and interaction methods, which is why it receives focused attention in every audit.