Skip to main content
Accessibility Field Guide

QA Keyboard Check

A practical no-mouse QA checklist for checking keyboard access, visible focus, focus order, traps, dialogs, forms, errors, and common interactive controls.

Close-up of the Enter key on a black keyboard.
Photo: Close-up of Enter Key on Keyboard via Pexels — https://www.pexels.com/photo/close-up-of-enter-key-on-keyboard-8855545/
View full screen Download image

Use this checklist for a practical no-mouse pass before a screen goes to broader accessibility review.

If you are reviewing a full web app for the first time, use How to Review a Web App for Accessibility for the First Time for the broader walkthrough. Use this checklist when you are ready to put the mouse aside and test the keyboard path.

The goal is not to turn every tester into a keyboard accessibility expert. The goal is to catch the obvious broken paths early:

  • controls that cannot be reached
  • actions that only work with a mouse
  • focus indicators that are missing or too subtle
  • focus order that jumps around
  • modals, menus, and widgets that trap the user
  • forms that cannot be fixed after errors

If a person cannot complete the main task without a mouse, the screen is not ready.

How to run the check

Pick one real screen and one real task.

Examples:

  • submit an application
  • search for a record
  • update contact information
  • upload a document
  • review a table
  • open a menu and choose an item
  • complete a multi-step form
  • fix validation errors and submit again

Then put the mouse aside.

Use the keyboard for the full pass:

  • Tab to move forward
  • Shift + Tab to move backward
  • Enter or Space to activate buttons and controls
  • Escape to close dialogs, menus, or popovers when expected
  • arrow keys for controls that commonly use them, such as radio groups, menus, tabs, sliders, or custom selects

Write down where the path breaks, where focus disappears, and where the task becomes unclear.

Main task pass

Start with the main thing the page is for.

  • Can you reach the first meaningful control without using the mouse?
  • Can you complete the main task with only the keyboard?
  • Can you activate every required button, link, field, option, and control?
  • Can you move backward if you need to check or change something?
  • Can you submit, save, continue, cancel, or go back with the keyboard?
  • Can you tell when the task is complete?
  • Does anything require a mouse click, hover, drag, or pointer gesture with no keyboard alternative?

Quick finding pattern:

The main task breaks at [specific control/step] because [what cannot be reached, operated, seen, or recovered from].

Tab order and path

The order should match the task and the visible layout closely enough that the user can follow it.

  • Does Tab move through the page in a logical order?
  • Does Shift + Tab move backward in a logical order?
  • Does focus jump unexpectedly to the footer, sidebar, hidden content, or unrelated controls?
  • Does focus skip important controls?
  • Does focus enter controls that are hidden, disabled, collapsed, or not currently relevant?
  • Does the order still make sense after expanding sections or revealing conditional fields?
  • Does the order still make sense after validation errors appear?

Watch for the moment where you ask, “Where did it go?” That is usually the issue.

Visible focus

A keyboard user needs to see where they are.

  • Is focus visible on every interactive element?
  • Is the focus indicator strong enough to notice?
  • Does the focus indicator have enough contrast against the surrounding background?
  • Is the focus style clipped, hidden, or covered by other layout elements?
  • Are hover styles clearer than focus styles?
  • Are custom controls using a visible focus treatment?
  • Has the default browser outline been removed without a clear replacement?

Quick check:

If you pause at any point in the tab order, can you immediately tell which control has focus?

Anything that acts interactive should work from the keyboard.

  • Can every link receive focus and open with Enter?
  • Can every button receive focus and activate with Enter or Space?
  • Are clickable cards, rows, icons, or images keyboard reachable?
  • Are repeated controls distinguishable by name, such as multiple Edit, Remove, or View actions?
  • Do controls that look disabled stay out of the focus order when they are not usable?
  • Are links and buttons used for the right kind of action?

Common issue:

A card or icon works with a mouse click but is built as a non-focusable element, so keyboard users cannot reach it.

Forms and errors

The keyboard path should work when the user makes a mistake, not only when everything is perfect.

  • Can you reach every field, option, checkbox, radio button, upload control, and submit button?
  • Can you identify the purpose of each field while using the keyboard?
  • Can you select radio buttons and checkboxes with expected keys?
  • Can you operate custom selects, date pickers, autocomplete fields, and upload controls?
  • When you submit with errors, can you tell errors were found?
  • Does focus move to a useful place after failed submission?
  • Can you move from an error summary to the fields that need attention?
  • Can you fix the fields and submit again without using the mouse?
  • Does the form preserve completed answers when validation fails?

Do at least one intentional error pass. A form that only works on the happy path is not done.

Custom components need predictable keyboard behavior.

  • Can you reach the widget with the keyboard?
  • Can you open it with the expected key?
  • Can you move through its options or panels?
  • Can you close it or move away from it?
  • Does focus stay visible while using it?
  • Does the component avoid trapping focus?
  • Are hidden panels or closed sections removed from the tab path?
  • Does the selected or expanded state make sense visually and programmatically?

Common places to check carefully:

  • navigation menus
  • accordions
  • tabs
  • custom dropdowns
  • autocomplete inputs
  • date pickers
  • carousels
  • table row actions
  • help popovers

Dialogs, modals, and overlays

Dialogs are one of the fastest places to find focus problems.

  • When the dialog opens, does focus move into it?
  • Is the first focused element useful?
  • Can you move through the dialog content and actions in a logical order?
  • While the dialog is open, does focus stay inside it?
  • Can you close the dialog with the keyboard?
  • When the dialog closes, does focus return to a logical place?
  • Does focus avoid moving into the page behind the dialog?
  • Is there a visible focus indicator on dialog controls?

The modal should feel like a controlled path, not a trap.

Dynamic updates and page changes

When the page changes, the user should not lose their place.

  • After filtering, sorting, adding, deleting, or saving, does focus remain somewhere useful?
  • After moving to the next step, does focus land in a sensible place?
  • After expanding or collapsing content, can you keep following the path?
  • After a status message appears, can the user understand what changed?
  • After an item is removed, does focus avoid landing on something that no longer exists?
  • If new content appears, is it reachable in a logical order?

Ask:

After the page changed, did I still know where I was and what to do next?

Keyboard traps

A keyboard trap means the user can get into an area but cannot get out with the keyboard.

Check especially:

  • modals
  • embedded maps
  • chat widgets
  • date pickers
  • carousels
  • custom dropdowns
  • third-party widgets
  • file upload controls

For each one, ask:

  • Can I enter it?
  • Can I use it?
  • Can I leave it?

If leaving requires a mouse, it is a trap.

What to write down

Good QA notes are specific enough for someone else to reproduce.

Write findings like:

  • Keyboard focus skips the Upload document button after the file type field.
  • The Help icon opens on mouse hover, but it cannot be reached with Tab.
  • After the modal opens, focus remains on the page behind it.
  • The custom dropdown can be opened with Enter, but the arrow keys do not move through options.
  • The focus outline on the Continue button is too faint against the blue background.
  • After submitting with errors, focus stays on Submit and the error summary appears above the form.

Avoid vague notes like:

  • Keyboard issue
  • Focus problem
  • Not accessible

The fix starts with a clear description of the broken path.

Quick pass version

If you only have a few minutes, check these six things:

  1. Can I complete the main task without a mouse?
  2. Can I see where focus is the whole time?
  3. Does focus move in an order that makes sense?
  4. Can I open and close menus, dialogs, and custom controls?
  5. Can I recover from form errors without a mouse?
  6. Can I get out of every widget or modal I enter?

If any answer is no, capture the issue before review.

Use these as trail markers, not as the whole checklist:

What to do next