Skip to main content
Accessibility.com, LLC
Category: Testing and Evaluation

Keyboard-Only Testing

Also known as: Keyboard Testing, Keyboard Navigation Testing, Keyboard Accessibility Testing
Simply put

Keyboard-only testing is a way of checking whether a website or application can be fully used with just a keyboard, without a mouse. It confirms that a person can move to and operate every interactive part of the page, such as links, buttons, and forms, using keys like Tab, Enter, and the arrow keys. This type of testing is a standard part of evaluating digital accessibility and is done manually.

Formal definition

Keyboard-only testing is a manual accessibility evaluation method in which an evaluator navigates and operates content using only the keyboard interface, verifying that all interactive functionality is reachable and operable without a pointing device. It commonly assesses visible focus indication, logical focus order, the ability to perform the same or comparable actions available to mouse users, and the absence of keyboard traps, where focus cannot be moved away from a component using the keyboard alone. This testing is closely associated with WCAG Success Criterion 2.1.1 (Keyboard, Level A), whose normative requirement is that there be a keyboard-operable way to perform the same or comparable actions and to operate the content. As a manual technique, keyboard-only testing addresses issues that automated tools cannot fully detect and is generally treated as one component of a broader evaluation that also includes assistive technology testing; it is not on its own a determination of full WCAG conformance or legal compliance.

Why it matters

Keyboard operability is foundational to digital accessibility because many people cannot or do not use a pointing device such as a mouse. People with motor disabilities, those who rely on assistive technologies, and users of alternative input methods commonly navigate entirely through the keyboard interface. If interactive elements like links, buttons, and forms cannot be reached or operated with keys such as Tab, Enter, and the arrow keys, those users may be effectively locked out of core functionality. Keyboard-only testing verifies that this basic pathway works.

This testing is closely associated with WCAG Success Criterion 2.1.1 (Keyboard), a Level A criterion whose normative requirement is that there be a keyboard-operable way to perform the same or comparable actions available to mouse users and to operate the content. Because it is a manual technique, keyboard-only testing surfaces problems that automated tools cannot fully detect, such as missing or illogical focus order, absent visible focus indication, and keyboard traps where focus cannot be moved away from a component using the keyboard alone.

It is important to treat keyboard-only testing as one component of a broader evaluation rather than a complete measure of accessibility. Passing keyboard tests does not on its own establish full WCAG conformance, nor does it guarantee legal compliance, and it does not substitute for assistive technology testing. Organizations should combine it with manual and assistive technology evaluation and, where legal exposure is a concern, consult qualified counsel and current agency guidance, as requirements evolve through regulation and case law.

Who it's relevant to

Accessibility Engineers and QA Testers
Those responsible for evaluating digital products use keyboard-only testing as a standard manual technique to identify issues such as unreachable controls, illogical focus order, missing focus indicators, and keyboard traps. Because these problems are not fully detectable by automated tools, keyboard testing is generally treated as an essential part of any accessibility evaluation.
UX Designers and Front-End Developers
Designers and developers who build interactive components can use keyboard-only testing to confirm that links, buttons, forms, and custom widgets can be reached and operated without a mouse and that focus behavior is predictable. Addressing keyboard operability early helps align implementations with WCAG Success Criterion 2.1.1 (Keyboard, Level A).
Compliance Officers and Legal Counsel
Those overseeing accessibility programs should understand that keyboard-only testing supports evaluation against a specific WCAG criterion but does not on its own establish full conformance or legal compliance. It is one input into a broader assessment, and questions about legal obligations should be directed to qualified counsel in light of applicable regulation and case law.
People Who Rely on the Keyboard Interface
Many users, including people with motor disabilities and those using assistive technologies or alternative input methods, depend on keyboard operability to access content. Keyboard-only testing helps ensure these users can perform the same or comparable actions available to those using a pointing device.

Inside Keyboard-Only Testing

Keyboard Navigation
The practice of operating a website or application using only the keyboard, without a mouse or other pointing device, typically relying on keys such as Tab, Shift+Tab, Enter, Space, and the arrow keys to move through and activate interactive elements.
Focus Order
The sequence in which interactive elements receive focus as the user navigates. A logical, predictable focus order that generally follows the visual and reading order helps users understand where they are and where they can go next.
Visible Focus Indicator
A perceptible visual cue showing which element currently has keyboard focus. WCAG addresses focus visibility, and keyboard-only testing commonly verifies that a clear indicator is present on every focusable element.
Keyboard Traps
Situations where focus enters a component but cannot be moved away using the keyboard alone. Identifying and eliminating keyboard traps is a core objective of keyboard-only testing and relates to relevant WCAG success criteria.
Operable Interactive Controls
Buttons, links, form fields, menus, dialogs, and custom widgets that must be reachable and fully functional via keyboard, including the ability to open, close, select, and dismiss components.
Skip Links and Bypass Mechanisms
Features such as 'skip to main content' links that allow keyboard users to bypass repeated blocks of content, reducing the number of keystrokes needed to reach primary content.
Manual Testing Method
Keyboard-only testing is a manual technique that complements, rather than replaces, automated testing and assistive technology testing, since automated tools detect only a portion of accessibility issues.

Common questions

Answers to the questions practitioners most commonly ask about Keyboard-Only Testing.

Does passing keyboard-only testing mean my site is fully accessible?
No. Keyboard-only testing evaluates whether functionality is operable without a mouse, but it does not cover all accessibility considerations. A site can be fully keyboard-operable while still presenting barriers for screen reader users, users who need sufficient color contrast, or users who rely on other assistive technologies. Keyboard testing is one component of a broader evaluation that should also include screen reader testing, manual review against WCAG success criteria, and testing with other assistive technologies. Meeting keyboard-related criteria does not by itself guarantee an accessible experience or immunity from legal claims.
Can automated tools replace manual keyboard-only testing?
Generally no. Automated tools detect only a portion of accessibility issues and are limited in evaluating the interactive, sequential experience of navigating with a keyboard. Determining whether focus order is logical, whether focus is visible, whether keyboard traps exist, and whether all interactive elements can be reached and operated typically requires manual testing by a person navigating with the keyboard. Automated checks may flag some related problems, but they commonly cannot confirm a usable keyboard experience on their own.
Which keys are typically used during keyboard-only testing?
Testing commonly uses the Tab key to move forward between interactive elements, Shift+Tab to move backward, and Enter or the Space bar to activate controls such as links and buttons. Arrow keys are often used within composite components such as radio button groups, menus, sliders, and some custom widgets. The Escape key is frequently used to close dialogs or menus. The exact keys expected depend on the component and its role.
What issues should a keyboard-only test look for?
A keyboard-only test commonly checks that all interactive elements can be reached and operated using the keyboard, that the focus order follows a logical and meaningful sequence, that a visible focus indicator is present, that no keyboard traps prevent the user from moving away from a component, and that functionality available with a mouse is also available via keyboard. These areas align with WCAG success criteria addressing keyboard operability, focus visibility, and focus order.
How do you begin a keyboard-only test?
A common approach is to set the mouse aside and navigate the page using only the keyboard, starting from the top of the page and using Tab to move through interactive elements in sequence. Testers often observe where focus lands, whether the focus indicator remains visible, whether the order is logical, and whether each control can be activated and exited. Interactive components such as forms, menus, modal dialogs, and custom widgets typically warrant closer examination.
Does keyboard-only testing benefit users beyond those with disabilities?
Keyboard operability supports people who cannot use or have difficulty using a mouse, including many users of assistive technologies and people with certain motor disabilities. Some users without disabilities also prefer or rely on keyboard navigation. Because keyboard access underpins how several assistive technologies interact with content, addressing keyboard operability can support a wider range of users, though it does not substitute for testing with those technologies directly.

Common misconceptions

Passing keyboard-only testing means the site is fully accessible and legally compliant.
Keyboard-only testing addresses one important dimension of accessibility. Meeting keyboard-related criteria does not guarantee an accessible experience for all users, nor does it guarantee immunity from legal claims. Comprehensive evaluation also requires manual review, assistive technology testing, and consideration of applicable WCAG success criteria; it is not legal advice, and requirements evolve through regulation and case law.
Automated accessibility scanners can fully verify keyboard operability, so manual keyboard testing is unnecessary.
Automated tools detect only a portion of issues and often cannot reliably confirm logical focus order, the absence of keyboard traps, or the usability of custom widgets. Manual keyboard-only testing remains necessary to evaluate these aspects.
Keyboard testing and screen reader testing are the same thing.
They are related but distinct. Keyboard-only testing evaluates operability using only the keyboard, while screen reader testing evaluates how assistive technology conveys content and interactions. Both are commonly recommended as part of a thorough evaluation.

Best practices

Navigate the entire interface using only the keyboard, confirming that every interactive element can be reached and operated without a pointing device.
Verify that a visible focus indicator is present on each focusable element and that the focus order follows a logical sequence generally consistent with the visual and reading order.
Test for keyboard traps by ensuring focus can move into and back out of every component, including menus, dialogs, and custom widgets, using standard keys.
Check that skip links and other bypass mechanisms function correctly, allowing users to move past repeated blocks of content.
Combine keyboard-only testing with automated testing and assistive technology testing, since each method surfaces different issues and automated checks alone are insufficient.
Document findings against the relevant WCAG success criteria and consult qualified legal counsel or current agency guidance when interpreting compliance obligations, as this guidance is not legal advice.