Keyboard Accessibility Testing Checklist

If you build web apps, keyboard testing should be part of your normal QA workflow.

Many accessibility blockers are easy to find with a keyboard, but they are often missed because teams only test with a mouse or trackpad.

1. Navigate the full workflow

Do not only tab across one page.

Test the full journey:

• Login.
• Search.
• Filtering.
• Form entry.
• Validation.
• Upload.
• Payment.
• Dashboard actions.
• Account settings.
• Downloads.

If a user cannot complete the path without a mouse, the workflow is not keyboard accessible.

2. Check focus visibility

Every interactive element needs a visible focus state.

Watch for:

• Removed outlines.
• Low-contrast focus rings.
• Focus hidden under sticky UI.
• Focus shown on a wrapper instead of the actual control.
• Focus lost after route changes or dynamic updates.

Use screenshots or screen recordings when reporting visual focus bugs.

3. Check focus order

Focus order should preserve meaning and operability.

Problems often appear when CSS changes layout, cards include nested links, modals open, sidebars collapse, or hidden content remains focusable.

Common fixes include:

• Using native HTML controls.
• Removing hidden elements from the tab order.
• Returning focus after dialogs close.
• Avoiding positive tabindex values.
• Managing focus after dynamic updates.

4. Look for keyboard traps

Keyboard traps are serious.

Test:

• Modals.
• Carousels.
• Maps.
• Video players.
• Embedded widgets.
• Chat components.
• Custom menus.

If focus enters but cannot leave, the journey is blocked.

5. Test custom widgets with expected keys

Custom widgets need intentional keyboard support.

Check menus, tabs, accordions, comboboxes, date pickers, sliders, grids, and drag-and-drop tools.

Ask:

• Can I reach it?
• Can I operate it?
• Can I understand state changes?
• Can I leave it?
• Does it work with assistive technology semantics?

6. Write findings developers can close

A good keyboard accessibility bug includes:

• Page or component.
• Steps to reproduce.
• Expected behavior.
• Actual behavior.
• User impact.
• WCAG mapping.
• Recommended fix.
• Retest result.

That level of detail prevents vague tickets and speeds remediation.

Conclusion

Keyboard accessibility is practical. You can test it today with no special tooling.

Run through real journeys, check focus, find traps, fix custom widgets, and retest before calling the issue closed.

Read the original guide on IAAP Audit: https://iaapaudit.com/blog/keyboard-accessibility-checklist-websites-web-apps