Keyboard Navigation Audits: How to Test a Page Without a Mouse

Many people navigate the web without a mouse: keyboard-only users, people using switch devices, and screen reader users who move through a page with keyboard commands. If a page can only be used with a pointer, those visitors are locked out of parts of it, sometimes the whole of it. A keyboard audit checks that every interactive part of a page can be reached, operated and left again using only the keyboard. The Keyboard Navigation Auditor checks pasted markup for common keyboard issues, giving you a structured starting point before you test in a real browser.

The basic test is the Tab key. Pressing Tab should move focus through the page in an order that matches the visual layout: top to bottom, left to right in most left-to-right designs, through the header, then the main content, then the footer. Each stop should be an interactive element: a link, a button, a form field, or a custom control that behaves like one. Non-interactive text, headings and plain containers should not receive focus, because every extra stop is a keystroke a keyboard user must spend to get anywhere. Shift plus Tab should walk the same order backwards. If the focus order jumps from the header to the footer and then back to the middle of the page, the visual order and the focus order disagree, and keyboard users will feel lost even though mouse users see nothing wrong.

Seeing focus matters as much as moving it. Every focused element needs a visible focus indicator, usually an outline, so the user always knows where they are. Browsers provide a default outline, and the most damaging keyboard mistake is removing it with CSS, for example with outline: none, without providing a replacement. A custom indicator is fine, even better, as long as it is clearly visible against every background it can appear on. Check the indicator on buttons, links, form fields and menu items, and check it in every state the element can be in, including when it sits on a dark banner or over an image.

Some components need more than Tab. Menus, dialogs, tab panels and carousels have their own keyboard patterns. A dialog should trap focus inside itself while it is open, so Tab cycles within the dialog rather than wandering off to the page behind it, and the Escape key should close it and return focus to the element that opened it. A menu button should open with Enter or Space, and arrow keys should move between menu items. A custom dropdown that only opens on hover is unreachable by keyboard, and a carousel whose previous and next controls are not focusable cannot be operated at all. The auditor flags missing patterns in markup, but the real test is always to operate the component yourself with the keyboard and confirm each pattern works.

A worked example you can follow

Imagine a small landing page whose markup contains 14 interactive elements: a logo link, 4 navigation links, a search field, a search button, 2 call-to-action buttons, a newsletter email field, a subscribe button, a video play button, and a footer link. That is 1 + 4 + 1 + 1 + 2 + 1 + 1 + 1 + 1 = 13, plus one more element, a settings gear button, bringing the total to 14. Running the audit finds 3 problems: the settings button is a div with a click handler and no keyboard support, so it is not in the tab order at all; the video play button has its outline removed and no replacement, so focus becomes invisible on it; and a promotional dialog traps focus but has no working Escape handler.

Count the impact. Of the 14 interactive elements, 1 is unreachable, so 13 of 14, or about 93 percent, are reachable, but the reachable percentage hides the real damage: the one unreachable element is the settings control, and the invisible focus indicator affects every keyboard user who tabs past the video button. Fixing the three issues changes the arithmetic: replacing the div with a real button element brings the reachable count to 14 of 14, restoring a visible outline makes focus visible on all 14 stops, and adding an Escape handler that returns focus to the button that opened the dialog closes the trap correctly. Re-run the audit after each fix and confirm the failure count drops from 3 to 0, rather than assuming a fix worked.

Test the tab order by hand after the audit passes. Put the mouse aside, start at the address bar, and Tab through the whole page, noting each stop and whether the order matches what you see. Then test Shift plus Tab backwards, open and close every dialog and menu, and confirm focus returns to a sensible place after each one closes. The auditor catches markup problems; only a human pass catches a focus order that is technically complete but confusing, such as a sidebar that tabs after the footer even though it appears before it visually.

Common mistakes to avoid

The most common mistake is building interactive elements out of div or span elements with click handlers and no keyboard support. Use native button, a and input elements wherever possible, because they bring keyboard support for free. A second mistake is removing focus outlines for visual cleanliness; style them instead of deleting them. A third mistake is adding tabindex values greater than zero, which hijack the natural order and create a tab sequence nobody can predict; use tabindex="0" only to add an element that should be focusable, and tabindex="-1" to remove one from the tab order while keeping it focusable by script. A fourth mistake is leaving keyboard traps: a component focus enters but cannot leave, which strands the user. A fifth mistake is testing only with a mouse and a screen reader, and never pressing Tab at all; the keyboard pass is its own test and takes only minutes.

Keyboard access is also where accessibility and general usability meet. A clear focus indicator helps anyone using a keyboard on a television, a kiosk or a laptop with a broken trackpad. A logical tab order helps power users who navigate by keyboard for speed. And the fixes are usually small: a native element here, an outline there, an Escape handler in one place. The audit tells you where to look, and a short manual pass tells you whether the experience actually works.

Frequently asked questions

Is a passing audit enough to claim a page is keyboard accessible? No. The audit finds markup problems, but focus order quality, dialog behaviour and the feel of the sequence need a manual keyboard pass.

What is a skip link, and do I need one? A skip link is a link at the very start of the page that jumps focus to the main content, letting keyboard users bypass repeated navigation. It is a simple, high-value addition on pages with long headers.

Why should I avoid positive tabindex values? Because they pull elements out of the document order and force a custom sequence that is fragile: every future edit risks breaking it, and the resulting order rarely matches the visual layout.

For contrast checks on your focus indicators, see Accessibility Contrast Matrix Guide, and pair the audit with the Accessibility Contrast Matrix and the Color Converter when styling visible focus states. Audit the markup, walk the page with Tab alone, and fix what the walk reveals.