Keyboard Accessibility: Test a Complete Task Without a Mouse

Choose a task such as finding an article, submitting a form or changing a delivery option, then complete it using the keyboard. Track where focus goes, whether you can see it and whether each control behaves as expected. This reveals problems that a quick inspection of the homepage can miss.

Begin with the browser and operating-system settings that allow normal keyboard navigation through controls. Record those settings with the test environment. Keep screen-reader testing as a separate part of the review as well, because a working keyboard path and a useful spoken interface require different observations.

Start with a repeatable route

Write the starting URL, the task and the expected result. Include any account role or saved state that changes the page. For a form, test both a successful submission and an error. For a menu or dialog, test opening it, moving within it and closing it.

Use Tab to move forward and Shift+Tab to move backward through the normal focus sequence. Check that meaningful controls are reachable in a sensible order. Keep the browser’s location bar and page content distinct when recording a problem; a test should say which element had focus before the failure.

Make a short record for each step: key pressed, focused element, visible response and task result. If focus disappears, stop and inspect the active element. That observation helps distinguish an invisible focus style from a control that was removed or never received focus.

Use native controls for familiar actions

Use an anchor with a valid destination for navigation and a button for an action on the current page. Native buttons already provide keyboard behavior and focusability. Native inputs, selects and textareas also bring established interactions that a custom element would need to recreate.

An ordinary action button inside a form should have an explicit type when it is not meant to submit:

<button type="button">Show delivery details</button>
<button type="submit">Save delivery choice</button>

The first button still needs the action’s implementation, but its basic semantics are already present. Adding role="button" to a generic container only describes a role; the author must also supply focusability and the expected keyboard interaction. Check that a click handler is not the sole way to operate the component.

Check the focus order against the task

Read the DOM order alongside the visual layout. A page that looks like a straightforward sequence can become confusing if CSS rearranges it while focus follows a different path. WCAG 2.4.3 requires a sequence that preserves meaning and operability when order matters.

Use tabindex="0" to include an otherwise non-focusable element in the normal sequence only when that is appropriate for the component. Use tabindex="-1" for an element that needs programmatic focus without adding another normal tab stop. Avoid positive tabindex values as a way to patch an awkward layout; they create a separate ordering system that becomes harder to maintain.

Check repeated page furniture. A working skip link can let users reach the main content without traversing every navigation item. Activate it, then continue with Tab and confirm that the next focus position follows the intended destination. Check that the target exists on every template that uses the link.

Match the keys to the component pattern

Component	Keyboard behavior to check
Link	Reachable in sequence and activated with Enter
Button	Activated with Enter and Space
Text field	Normal typing, editing and selection remain available
Disclosure	Button changes the content visibility and expanded state
Tab set or other composite widget	Tab enters or leaves the component; internal navigation follows its documented pattern
Modal dialog	Focus moves inside, remains within the active dialog and can leave through the close behavior

Use the relevant WAI-ARIA Authoring Practices pattern for a custom widget. A tab set, listbox and ordinary navigation list have different interactions. Choose the pattern that matches the user’s task before writing the key handlers.

Preserve browser and operating-system shortcuts. A global key listener can accidentally prevent typing in an input or stop ordinary scrolling. Test keyboard behavior inside text fields as well as on the custom component, especially when the page registers shortcuts at the document level.

Make focus easy to locate

Keep a visible indicator on every interactive element. Test it against each background and in selected, error and expanded states. A focus treatment that appears on a white form can disappear inside a colored toolbar.

Tab through the page while sticky headers, cookie notices and chat panels are present. Under WCAG 2.4.11, author-created content must not entirely hide the focused component. Test at a narrow viewport and with zoom, where fixed elements can occupy much more of the available screen.

If a control scrolls into view, confirm that its indicator and label are usable at the final position. Check both forward and reverse navigation. A layout may reveal a control when moving down the page but obscure it again when moving upward beneath a fixed header.

Open and close dialogs deliberately

When a modal opens, move focus to an appropriate element inside it. For a short decision, that may be a button; for a long explanation, focusing an introductory heading can make the content easier to understand. Keep the background inert while the modal is active.

Test Tab and Shift+Tab at the first and last focusable elements. The APG modal pattern keeps that sequence within the dialog and uses Escape to close it. Include a visible close or cancel control where appropriate. On closing, normally return focus to the opener, or to a logical next location if the opener no longer exists.

Record the exit behavior in the test. A modal can legitimately contain focus while open, provided the user can close it with the keyboard. A component that traps focus without a usable exit blocks the rest of the page.

Test dynamic changes and failures

Remove an item from a list and inspect where focus goes afterward. Open additional form fields and confirm they appear in the expected order. Submit an invalid form and verify that the user can find and correct the problem without restarting the task.

For asynchronous work, keep the current task understandable while loading. Decide whether focus should stay on the triggering control, move to a new step or follow an error summary. Test the slow and unsuccessful responses as well as the successful one. Those states often expose a focus-management gap that never appears in a fast demonstration.

Write a finding that can be fixed

Record the URL, environment, starting state, exact keys and the first point where the task fails. Include the expected focus destination and the observed one. A concise reproduction is more useful than a statement that “keyboard support is broken.”

After the repair, repeat the original task in both directions and check other uses of the shared component. Keep the result with the component’s acceptance criteria. That makes keyboard behavior part of the next change rather than a separate cleanup at the end of the project.