Keyboard Navigation Test: Verify Tab Order, Focus, and Skip Links
A keyboard navigation test checks whether people can operate your entire site using only a keyboard, without a mouse or trackpad. This guide walks through the core checks, common failures, and how to test manually and with the AccessGuard scanner.
Why Keyboard Access Matters
Keyboard access is the foundation of web accessibility. People who cannot use a mouse rely entirely on the Tab, Shift+Tab, Enter, Space, and arrow keys to move through a page. This includes people with motor disabilities, people using switch devices or sip-and-puff controls, screen reader users who navigate by keyboard, and many power users who simply prefer it. If something works only on click or hover, a large group of people is locked out.
The Web Content Accessibility Guidelines (WCAG) treat keyboard operability as non-negotiable. Success Criterion 2.1.1 (Keyboard) requires that all functionality be available from a keyboard, and 2.4.7 (Focus Visible) requires that the focused element be clearly indicated. WCAG 2.2 added 2.4.11 (Focus Not Obscured), which means the focused element must not be hidden behind sticky headers or overlays. These are among the most commonly failed criteria on real sites.
Keyboard testing is also fast to start and high signal. You do not need special software to find serious problems. If you can Tab through a page and reach everything in a sensible order with a visible highlight, you have already cleared a major bar. Note that passing a keyboard test supports accessibility improvements and EAA readiness, but it is not legal advice and does not by itself guarantee compliance.
How to Run a Manual Keyboard Navigation Test
Start by putting the mouse aside. Load the page, click once in the browser address bar, then press Tab to move focus onto the page. From there, use only the keyboard. Tab moves forward, Shift+Tab moves backward, Enter and Space activate buttons and links, and arrow keys move within components like menus, radio groups, and sliders.
Work through the page top to bottom and watch for four things at once: whether focus is always visible, whether the order makes sense, whether you can reach every interactive element, and whether you can also get back out of every element. Pay special attention to menus, modals, carousels, date pickers, custom dropdowns, and cookie banners, since these are where keyboard support most often breaks. Test in at least one Chromium browser and one Firefox, because focus behavior can differ.
Browser tools speed this up. In DevTools you can inspect the currently focused element to confirm the correct control has focus, and you can watch the accessibility tree to see roles and names. Testing with a screen reader such as VoiceOver on macOS or NVDA on Windows adds another layer, since it reveals whether the focused control announces a meaningful name and role, not just whether it can be reached.
- Set focus in the page, then navigate using only Tab and Shift+Tab
- Confirm a visible focus indicator on every interactive element
- Check that tab order follows the visual and logical reading order
- Activate every control with Enter or Space and operate widgets with arrow keys
- Verify you can move focus out of every menu, modal, and embedded widget
- Test in more than one browser to catch focus differences
Tab Order and Logical Focus Flow
Tab order is the sequence in which focus lands on interactive elements as you press Tab. By default the browser follows the order of elements in the HTML source, so the cleanest way to get correct tab order is to write your markup in the same order it appears visually. When source order and visual order disagree, keyboard users experience a confusing jump around the page.
The most common cause of broken tab order is misuse of the tabindex attribute. Use tabindex="0" to add a custom interactive element into the natural order, and tabindex="-1" to make an element focusable only by script (useful for moving focus to a heading or dialog). Avoid positive tabindex values like tabindex="1" or higher, because they override the natural order for the whole page and are almost always a source of bugs. CSS layout tricks such as flex order and grid placement can also visually reorder content without changing the underlying tab order, so verify the two still match.
When you test, narrate the path out loud: header, primary navigation, main content, sidebar, footer. If focus suddenly leaps from the header into a footer widget and back, or skips the main call to action, the order needs fixing. AccessGuard flags likely tab order risks, such as positive tabindex usage and interactive elements that are not reachable, so you know where to look.
Visible Focus, Skip Links, and Focus Traps
A visible focus indicator is the outline or highlight that shows which element is currently selected. A frequent mistake is removing it globally with CSS such as outline: none, which leaves keyboard users with no idea where they are. If the default outline clashes with your design, replace it with a clear custom style using :focus-visible rather than deleting it. The indicator should have strong contrast against its background and stay visible even under sticky headers.
Skip links let keyboard users jump past repetitive navigation straight to the main content. A skip link is typically the first focusable element on the page, visually hidden until it receives focus, and points to an id on the main region. Without one, a keyboard user may have to Tab through dozens of nav items on every single page. Test yours by pressing Tab immediately after loading the page and confirming the link appears and works.
Focus traps are the other major failure. A good trap is intentional: inside an open modal, focus should cycle within the dialog and Escape should close it and return focus to the trigger. A bad trap is accidental, where focus enters a widget such as an embedded video, carousel, or third party embed and cannot get out with the keyboard alone. Both patterns need testing. Confirm that modals contain focus while open and release it when closed, and that no component silently swallows focus with no exit.
Testing with AccessGuard
Manual testing finds the problems only a human can judge, like whether the order feels logical. An automated scanner finds the mechanical issues quickly and consistently across every page. Used together they cover far more ground than either alone. The free AccessGuard scanner checks your pages for WCAG issues and surfaces keyboard related signals such as missing or suppressed focus styles, positive tabindex usage, interactive elements built without proper roles, and missing skip navigation.
Each finding comes with developer fix guidance that explains the underlying issue and shows the markup or CSS pattern to correct it, so your team can move from detection to repair without guesswork. You can export a PDF report to share with stakeholders, track progress in the dashboard over time, and run the WordPress plugin to keep checking as content changes. This gives you a repeatable keyboard accessibility baseline rather than a one time snapshot.
Accessibility scanning and EAA readiness signals help you prioritize accessibility improvements, but they are not legal advice and do not guarantee compliance with any law. For issues that need hands on work, VASTROX also offers accessibility repair, web development, and WordPress maintenance so you can get keyboard problems fixed, not just flagged.
- Run the free scan to detect focus, tabindex, and skip link issues
- Follow the developer fix guidance for each finding
- Export PDF reports and track progress in the dashboard
- Combine automated scanning with the manual test steps above
Frequently asked questions
What is a keyboard navigation test?
It is a check of whether every interactive part of your site can be reached and operated using only a keyboard, with a visible focus indicator, a logical tab order, working skip links, and no accidental focus traps. It maps directly to WCAG criteria like 2.1.1 Keyboard and 2.4.7 Focus Visible.
How do I test keyboard navigation manually?
Put your mouse aside, click in the address bar, then press Tab to move onto the page. Use Tab and Shift+Tab to move, Enter and Space to activate controls, and arrow keys inside widgets. Watch that focus is always visible, the order is logical, you can reach everything, and you can exit every menu and modal.
Why should I never use outline: none?
Removing the outline globally deletes the visual cue that tells keyboard users where they are on the page, which fails WCAG 2.4.7. If the default outline does not fit your design, replace it with a high contrast custom style using :focus-visible instead of removing it entirely.
What is a focus trap and is it always bad?
A focus trap keeps keyboard focus inside a region. It is intentional and correct inside an open modal, where focus should cycle within the dialog and Escape should close it. It is a bug when focus enters a component such as an embed or carousel and cannot get out with the keyboard, which strands the user.
Does passing a keyboard test mean my site is legally compliant?
No. A keyboard navigation test and AccessGuard scans provide accessibility improvements and EAA readiness signals, but they are not legal advice and do not guarantee compliance with the European Accessibility Act or any other law. Use them to find and fix real barriers as part of a broader accessibility effort.
Can AccessGuard test keyboard accessibility automatically?
AccessGuard flags the mechanical keyboard issues a scanner can detect, such as suppressed focus styles, positive tabindex, missing skip links, and controls without proper roles, and gives developer fix guidance for each. Pair it with the manual Tab test to also catch judgment based issues like whether the order feels logical.