Turn Keyboard Accessibility into a Website Acceptance Test

A website review should ask whether someone can complete an important task using a keyboard. Attractive screens and a successful mouse click do not answer that question. A customer may reach a form but lose their place, become stuck inside a dialog, or find that an action only appears on hover.

Turn one business journey into an acceptance exercise: find a service, open its inquiry form, correct an error, and submit a clearly labeled test request. The result should be a record of observable behavior, with defects another person can reproduce.

Choose a task and prepare the environment

Select a journey that matters to customers or employees. Use a test environment when submission creates work or sends messages. Record the browser, operating system, page, and version under review. Confirm that the browser is configured to navigate all relevant controls with the keyboard.

The W3C accessibility principles explain that functionality should be keyboard operable and that users must not become trapped. Apply those principles to the complete task, including menus, error messages, verification steps, and confirmation.

Set the mouse aside for the exercise. If you need it to escape a component, record the failure before continuing. Otherwise, an unconscious mouse rescue can hide the very obstacle the test was meant to reveal.

Follow focus through the journey

Use Tab and Shift+Tab to move forward and backward through ordinary controls. Observe which item receives focus and whether the sequence remains understandable. You should be able to answer, “Where am I, and what will activation do?”

WCAG's Focus Visible explanation describes the need for a visible keyboard-focus indicator. During this test, record where that indicator disappears or is hidden behind another interface element. A screenshot should identify the control and the step that reached it.

Do not assume every custom widget uses Tab for every internal movement. A calendar or menu may use arrow keys according to its interaction pattern. Check its instructions and intended keyboard behavior. An undisclosed or inconsistent shortcut deserves investigation rather than guesswork.

Exercise dialogs and error recovery

If the inquiry form opens in a modal, check the opening focus, the controls inside it, and the way out. The W3C modal-dialog pattern describes focus cycling within the open dialog, Escape dismissal, and appropriate focus return after closing.

In the hypothetical inquiry journey, run this sequence:

1. Reach the service link and activate it using the keyboard.
2. Open the inquiry dialog and identify the currently focused control.
3. Move through every field and action, then move backward through them.
4. Submit with a required field empty. Locate the error, correct it, and confirm that entered values remain as intended.
5. Close the dialog and verify where focus returns. Reopen it and complete the permitted test submission.
6. Find the confirmation and the next useful action without moving the mouse.

Also inspect a long page with a sticky header or banner. A control can technically receive focus while remaining difficult to see. Test the layouts and zoom levels your review plan actually covers, and record those conditions.

Write an acceptance result that can be checked

A useful failure report says, “After opening Request information and pressing Tab three times, focus moves to an invisible control; Enter closes the dialog.” Include the environment and expected behavior. “Accessibility is broken” provides too little information to retest.

For each task, mark completed, blocked, or completed with a recorded obstacle. Keep the exact failing step, affected control, screenshot when useful, and responsible owner. Ask the reviewer to repeat the same sequence after the correction.

Do not equate keyboard completion with a complete accessibility assessment. Screen-reader behavior, text alternatives, contrast, zoom, and other requirements need appropriate checks. This exercise supplies focused evidence for one important part of the experience.

Make the check part of future changes

Retest the journey when navigation, forms, dialogs, banners, or third-party widgets change. Store the task and expected behavior alongside the feature's acceptance criteria so the next reviewer can repeat it without reconstructing the instructions.

The scenario above is a proposed test, not a certification or a reported client result. Its value is a practical conversation between the business owner, designer, and developer about whether a person can finish the task.

Contact Dynelink to define keyboard acceptance cases for the website actions your customers and employees need to complete.