Keyboard navigation testing goes beyond pressing Tab. A systematic approach covers interaction patterns that automated tools like axe and Lighthouse will never catch, because those tools test structure and not behaviour.
1. Start before the main content
The first Tab press should reach a skip link. Without one, keyboard users have to tab through every nav item on every page load. That's a WCAG 2.4.1 failure, and one of the most common.
2. Tab through every interactive element
Buttons, links, inputs, selects and custom components, every one of them. If you can't reach it with Tab, keyboard users can't use it.
3. Check focus visibility at each stop
Having an outline isn't enough; it has to be visible enough. WCAG 2.4.13 (Focus Appearance, Level AAA, introduced in WCAG 2.2) sets minimum requirements for focus indicator size and contrast. A 1px dotted outline on a white background doesn't pass.
4. Activate everything you reach
Press Enter on links and buttons, Space on checkboxes, and the arrow keys on radio groups and select menus. Reaching an element with Tab is pointless if you can't activate it.
5. Test modals and overlays separately
Open the modal with the keyboard and check that focus moves inside it. Try to Tab out; focus should stay trapped. Close it, and focus should return to the trigger that opened it. Modern interfaces break this pattern more consistently than almost any other.
6. Test in reverse
Shift+Tab back through everything. The order should make sense in both directions.
7. Don't use the mouse to reset
If you need to click something to continue testing, you've found a bug. Document it and keep going without the mouse.
How long this takes depends on page complexity, data coming from APIs and the flow being tested.
Something that rarely gets mentioned: when you develop and test at the same time, your eyes start seeing what they expect to see instead of what's there. Familiarity with your own code creates real blind spots, and the checklist protects against them. Each checked item confirms that something was verified, not just seen.
The checklist surfaces issues that axe, Lighthouse and every other automated tool miss. Semantic HTML is the foundation that makes all of this possible, but even perfect semantics can fail at the interaction layer, and the keyboard test is where you find out.
What step do most teams skip? In my experience, the focus trap inside modals. Every time.