How to test a website with a keyboard

1. Define one task and a safe starting point

Write the task as a short outcome, such as finding opening hours, filtering a list, or completing a contact form. Include the starting URL and the point at which the task is complete. Test a form submission in a staging environment or with an approved test destination so the check does not create an unwanted message or purchase.

Record the browser, operating system, viewport, and whether a screen reader is running. For a first keyboard check, use the browser without a screen reader; screen reader keyboard interaction is an additional test. Make sure your browser and operating system are configured to move keyboard focus to links and controls, not only text fields.

Reload the page, put the pointer aside, and start from a known position. If you clicked a control while investigating, reset before repeating the keyboard path. W3C's Easy Checks is a starting point for review, not a complete evaluation.

2. Follow focus through the page

1. Press Tab to enter the page. If there is a skip link, activate it and confirm it moves you past repeated navigation to the main content.
2. Continue with Tab. At each stop, identify which element has focus. Use Shift+Tab to check the reverse route.
3. Check that focus follows a sequence that makes sense for the task. Watch for unexpected jumps between columns or a control reached before its instructions.
4. Repeat after scrolling and opening menus. Notice whether a header, cookie notice, or other overlay covers the focused control.

Ordinary paragraphs do not need to be Tab stops. Links, buttons, form controls, and other interactive components are the main stops in this review. Do not add tabindex="0" to every piece of content to make the sequence longer.

Use Focus Order to assess whether the sequence preserves meaning and operation. Use Focus Visible for the visible indicator. Record the exact control where focus becomes unclear, rather than a general note that navigation feels confusing.

3. Activate controls and complete the task

Test native links with Enter and native buttons with both Enter and Space. Test a checkbox with Space. For a radio group or a composite widget such as tabs, check the appropriate arrow-key behavior as well. Tab does not have to stop on every item inside a composite widget.

Confirm the result of each action: a selected filter changes the results, a disclosure reveals its content, or a form produces useful validation feedback. Check that a keyboard user can get to the new content and recover from an error. A pointer-only tooltip or drag action needs further investigation if essential information or functionality has no keyboard route.

<details>
  <summary>What to bring to your appointment</summary>
  <p>Bring your booking reference and the documents listed in your confirmation.</p>
</details>

This native disclosure supplies built-in interaction. Keep its summary focusable and its focus indicator visible when styling it, then check it in your supported browsers. Adding a click handler to a generic element does not supply the same behavior. WCAG Keyboard addresses keyboard operation of functionality, with an exception for input that depends on the path of movement itself.

4. Check dialogs and a way back

Open any dialog that belongs to the task using its keyboard-accessible trigger. For a modal dialog, check that focus moves inside, its purpose is clear, and Tab and Shift+Tab stay within it while it is open. Background controls should not remain operable as if the modal were absent.

Test Escape and the visible close or cancel control. After closing, check that focus returns to the trigger or another logical location if the trigger no longer exists. W3C's modal dialog pattern describes these interactions and cases where the initial focus should go somewhere other than the first control.

Keeping focus inside a modal is intentional only while there is a working keyboard exit. If you can enter a component but cannot leave it using the keyboard, investigate a potential trap. No Keyboard Trap explains the requirement, including instructions when leaving a component uses a nonstandard method.

5. Write steps another person can repeat

For each observed problem, capture the starting URL, relevant state, sequence of keys, expected behavior, actual behavior, and impact on the task. Include a screenshot or short recording if it helps locate the control, while keeping personal information out of the evidence.

Task:
Starting URL and state:
Browser / operating system / viewport:
Keys pressed, in order:
Expected behavior:
Observed behavior:
Effect on completing the task:
Result: passed / failed / not tested
Retest date and reviewer:

A hypothetical report might say: “Open the filter dialog, change a value, then press Escape. Expected: the dialog closes and focus returns to Filters.” Add an actual result only after observing it. An empty result is not a pass.

After a fix, repeat the complete task from the same starting point, in both directions where relevant. Then check a second use of the shared component. Record any steps you did not retest so the review remains useful to the next person.

6. Keep automated and manual results separate

Automated checks can flag some markup that creates keyboard risks. For example, Deque's tabindex rule flags positive tabindex values that can disrupt the focus sequence. That finding is a useful lead; removing a positive value does not prove the whole task works.

Use WebAccez to gather automated findings on scanned pages and keep the task record above alongside them. A scanner does not establish that every dialog opens, every error can be corrected, or focus returns to a useful place after an action. Passing this keyboard task also does not replace a screen reader review or other accessibility checks. Document the task you tested and keep the untested scope visible.