Skip to main content :::
:::

Keyboard Accessibility Testing: Can Users Complete the Task Without a Mouse?

Keyboard accessibility is a core part of web accessibility testing. Check tab order, focus indicators, traps, dialogs, and form flows.

Last updated:

Summary

  • Choose one main task and check whether it can be completed without a mouse.
  • Keyboard testing checks reachability, visible focus, state changes, and escape paths.

Test the main task, not only whether Tab moves

The core question in keyboard accessibility testing is not whether focus appears somewhere. It is whether users can complete the main task without a mouse. Start at the top of the page and use only the keyboard to complete a real flow, such as search, filtering, sign-in, form submission, or checkout.

Pressing Tab a few times can miss the issues that actually block a task: focus not returning to an error after form submission, focus disappearing after a dialog closes, or an expanded menu preventing the user from moving forward.

  • Use Tab to move forward and Shift + Tab to move backward.
  • Use Enter for ordinary links, Enter or Space for native buttons, and Space to toggle a checkbox.
  • Radio groups and tabs typically use arrow keys within the component rather than Tab for every item. Check selection and activation against the component’s interaction pattern.
  • Use Escape to close dismissible dialogs, popovers, or menus.
  • After form errors, loading completion, or route changes, confirm where focus lands.

Check reachability, visibility, operability, and escape

A practical keyboard review can be split into four questions: can users reach it, can they see focus, can they operate it, and can they leave or continue afterward. This is easier for teams to execute than memorizing individual checkpoints.

  • Reachability: links, buttons, fields, custom controls, and main actions can receive focus.
  • Visibility: focus styling has enough contrast and area, and is not accidentally removed.
  • Operability: keyboard behavior matches user expectations and does not require a mouse.
  • Escape: the component has a working keyboard exit. A modal dialog intentionally contains focus while open; check that it can be closed by keyboard and that focus returns to its trigger or a logical next step.

Try it: follow a form error through to correction

Choose a form in a test environment and use clearly identified test data. Before submitting, confirm it will not send email, charge a card, or change a real person’s data. Do not use a live checkout or contact form as a practice exercise.

  • Start before the form and Tab through the fields. Note whether each name and focus position is clear.
  • Leave one required field empty and submit. Check that you can find the error, understand the correction, and keep the data already entered.
  • Find and correct the field using only the keyboard, then submit again. Check that completion can be found, not just inferred from a button changing color.
  • Record the page, browser, steps, expected result, and actual result. Repeat those steps after a fix. Test screen-reader error and completion announcements separately.

Common keyboard issues

Keyboard issues are often not caused by one missing attribute. They usually come from semantics, styling, JavaScript behavior, and state management together. Custom components must not only look like buttons or menus; they also need the behavior users expect from those controls.

  • Interactive div or span elements without keyboard support.
  • CSS removes outlines without providing a clear replacement focus style.
  • Tab order does not match the visual order, causing users to get lost.
  • Dialogs do not receive focus when opened or return focus to the trigger when closed.
  • Single-page app route changes leave focus in the old position or an unpredictable place.

DevCheck can assist, but real flows still matter

DevCheck can help teams run preliminary checks on the current page, observe focus paths, and discuss issues with manual review aids. But no tool can decide whether every flow is reasonable or guarantee that assistive technology users can complete the task.

A better workflow is to use DevCheck as the entry point before release, then have QA, engineering, or product owners complete the main flow with a keyboard. Fix what automation can catch, and document the remaining human-judgment risks.

Related pages