Keyboard accessibility testing asks whether someone can complete a task through the keyboard interface, understand where they are, and leave every component they enter. Tabbing through the initial page is a starting point. A useful review also opens menus and dialogs, submits forms, follows errors, and checks what happens when content changes.
This checklist is for developers, QA teams, and accessibility evaluators planning a repeatable manual review. It covers a focused set of keyboard and focus checks. Agree the wider accessibility audit scope separately, including the standard, conformance level, and other testing methods.
Prepare a repeatable test environment
Record the operating system, browser and version, viewport, account role, product version, and relevant keyboard settings. Ensure the environment allows navigation to links and controls; platform preferences can affect which elements Tab reaches.
Choose a complete task with a clear endpoint, such as finding an appointment and receiving a booking confirmation. Write down the starting URL and any setup needed to expose the correct state. Use safe test data and an agreed test account when the process submits information.
For the keyboard pass, put the pointer aside and document when an action cannot be completed. A separate screen reader pass can then examine the names, roles, states, and announcements exposed to assistive technology. Preserve the distinction between these two reviews so the result of one does not imply completion of the other.
Check that the task can be operated
WCAG 2.2 Success Criterion 2.1.1, Keyboard, requires functionality to be operable through a keyboard interface, with an exception for underlying functions that depend on the path of movement. Dragging a card between known destinations is not automatically exempt merely because its current interface uses a pointer.
For each step of the task, try to:
- Reach the relevant control or its keyboard-accessible equivalent.
- Activate the control and observe the resulting state.
- Change selections, enter information, and submit it.
- Cancel or reverse an action where the interface offers that operation.
- Continue to the task's endpoint without switching to a pointer.
Use the expected keys for the type of control. Follow the component's documented keyboard behavior where it is available. If a custom control uses an unusual interaction, record how a user can discover it before deciding which requirement the observation affects.
Distinguish Tab navigation from navigation inside a widget
Do not assume every item in a composite widget must be a separate Tab stop. A tab set, listbox, or tree can use one entry point in the Tab sequence and other keys to move inside it.
The WAI-ARIA Authoring Practices keyboard interface guide explains these conventions. APG patterns are implementation guidance; evaluate a WCAG conclusion against the success criterion itself rather than treating every pattern recommendation as a normative requirement.
| Component | What to investigate | What to record |
|---|---|---|
| Ordinary links and buttons | Sequential navigation and activation | Reachable action and resulting state |
| Tab set or listbox | Entry point, internal navigation, selection, and exit | Keys used and the selected item |
| Expanded navigation | Opening, reading available options, choosing, and closing | Expanded state and where focus moves |
| Custom date picker | Changing dates and confirming a choice | Chosen date, exposed state, and keyboard route |
A static paragraph usually does not need to receive Tab focus to be readable. Conversely, an action that never enters the Tab sequence may still have a usable keyboard equivalent. Evaluate the actual operation rather than counting focusable elements.
Check focus order and visibility as separate questions
Success Criterion 2.4.3, Focus Order, concerns a sequence that preserves meaning and operation. It does not require a particular left-to-right or top-to-bottom arrangement in every layout. Follow the sequence and explain where it creates confusion or prevents the task from progressing.
Next, check whether you can identify the focused control throughout the interaction. Success Criterion 2.4.7, Focus Visible, addresses the visible keyboard focus indicator. Inspect controls in their actual presentation, including disabled-looking styles, open panels, and error states. Keep an observation about an absent indicator distinct from an observation about the order of focus.
Finally, check overlapping content. Under Success Criterion 2.4.11, Focus Not Obscured (Minimum), a component receiving keyboard focus must not be entirely hidden by author-created content. This AA requirement permits partial obscuring; keeping the whole component visible is a better design target. The criterion also contains notes about user-movable and user-opened content, so include the relevant state in the finding.
Pay particular attention to sticky headers, cookie notices, fixed action bars, and chat panels. Capture the focused state and the overlapping layer together. A screenshot of the page before focus arrived does not show what the keyboard user encountered.
Open, operate, and close modal dialogs
The APG modal dialog pattern describes focus moving inside an opened dialog, Tab remaining within it, Escape closing it, and focus generally returning to its trigger. The appropriate initial focus can depend on the content, and a logical workflow destination can replace the trigger in some cases.
Test the full lifecycle rather than checking only the presence of a dialog role:
- Open the dialog from its trigger using the keyboard.
- Note the initial focus and whether the beginning of the content can be understood.
- Visit the available controls in both directions.
- Perform the offered action or cancel it.
- Close the dialog and record where focus lands.
Success Criterion 2.1.2, No Keyboard Trap, requires a keyboard route out of a component. Keeping focus inside an active modal is not itself a failure when the dialog can be dismissed through an appropriate keyboard method. A component that leaves the user with no usable exit needs a reproducible finding.
Repeat the task through errors and layout changes
Submit incomplete or invalid test data, inspect the response, correct the information, and continue. Record whether new content changes the focus sequence or hides the currently focused field. Use the form accessibility testing guide for the complementary checks on labels, error descriptions, and announcements.
Repeat relevant steps at the narrower layouts and zoom settings agreed in the scope. A navigation bar can become a different component when it collapses. Document the viewport and state rather than treating the desktop result as evidence for the collapsed menu.
Write a finding another person can repeat
For an illustrative booking dialog issue, a useful record might say: open the date selector from the booking page, move to the confirmation action, close the dialog, then press Tab. Describe the observed destination and why it disrupts continuation of the booking task. Include the product version, environment, exact key sequence, and the evaluator's requirement mapping.
After a fix, repeat that sequence and complete the surrounding task. Preserve the new observation alongside the earlier evidence. The release retesting guide helps connect changed components to the journeys that need another manual pass.
Sources and interpretation
The linked WCAG Understanding pages and APG guidance were checked on 6 October 2026. Understanding pages explain the requirements; the WCAG 2.2 Recommendation contains the normative success criteria. The procedure here is a focused test plan and does not cover every accessibility requirement that may apply to the product.