Keyboard navigation: the two-minute test every website should pass
Put the mouse down and press Tab. Whether you can see where you are and reach everything says more than any accessibility badge. Here is the test.
The short answer
Put your mouse down, open your website, and press the Tab key. Keep pressing it. If you can always see where you are, if the order makes sense, and if you can open every menu, fill every form and press every button without picking the mouse up again, your site passes a test that a surprising number of business websites fail. It takes two minutes and needs no tools.
The people it matters for are real: keyboard users, screen reader users, people with motor impairments, and anyone whose mouse battery just died. It is also a core requirement of the accessibility standard that legislation refers to.
The test
- Load the home page and press Tab. The first thing to receive focus should be visible, ideally a “skip to content” link.
- Keep pressing Tab. A clear focus indicator should move through links and controls in the same order a sighted person reads the page.
- Open the main menu with the keyboard. Enter or Space on the menu button; arrow keys or Tab within; Escape closes it and returns focus to the button.
- Fill in the contact form. Tab into each field, type, Tab to the submit button, press Enter. Error messages should appear where focus is, not somewhere off screen.
- Open anything that pops up: a cookie notice, a modal, a lightbox. Focus should move into it, stay inside while it is open, and return to where you were when it closes.
- Reach the footer and back again with Shift+Tab. Nothing should be skipped and nothing should trap you.
The common failures and their fixes
| Failure | What you see in the test | Fix |
|---|---|---|
| Invisible focus | Pressing Tab does nothing visible; you are lost | Restore a clear focus style that meets contrast requirements |
| Menu cannot be opened | Tab skips the menu button or Enter does nothing | Use a real button and standard keyboard handling |
| Modal traps or loses focus | You Tab behind the modal, or Escape does nothing | Move focus in, trap it while open, restore on close |
| Custom controls that are not controls | A clickable div is skipped by Tab | Use native buttons and links, or add correct roles and keyboard handling |
| No skip link | Dozens of Tabs through the header on every page | Add a skip-to-content link as the first focusable element |
| Illogical order | Focus jumps around the page | Make the document order match the visual order |
| Hidden content still focusable | Focus disappears into an invisible slide or menu | Remove hidden content from the tab order |
Why it is a good proxy for the whole
Keyboard operability sits underneath everything else in accessibility. Screen readers are driven by keyboard. Voice control activates the same focusable elements. If the keyboard test passes, a large share of the accessibility standard is likely to be met; if it fails, the rest usually fails with it. That is why it is the first thing an auditor does, and why it is worth doing yourself.
What this means for you
Two minutes today tells you whether your site is usable by a real group of customers and whether it meets a core requirement of the accessibility standard. If it passes, good; add it to the checklist for every change. If it fails, the fixes are standard and a competent developer can make them. If it fails badly and the site was built on a page builder, that is one more reason a rebuild on a proper foundation is the cheaper long-term fix.
Frequently asked questions
Who actually uses a website with a keyboard only?
People who cannot use a mouse because of a motor impairment or a temporary injury, screen reader users whose software drives the page by keyboard, people using switch devices, and many power users who simply find it faster. It is a larger group than owners assume, and it includes customers.
Our site has an accessibility overlay widget. Does that cover this?
No. Overlays add a toolbar; they do not fix a menu that cannot be opened from the keyboard or a form field with no label. Run the test yourself. If it fails with the overlay installed, the overlay has not solved the problem, and it may have introduced new ones.
Is this required by law?
Keyboard operability is a core requirement of WCAG 2.2 at level AA, which is the standard referenced by accessibility legislation in the EU and elsewhere. Whether a specific law applies to your business depends on your sector and size; the requirement to be usable by keyboard is in the standard regardless.
Sources
- W3C: How to Meet WCAG (Quick Reference) (accessed 2026-09-11)
- MDN: Keyboard-navigable JavaScript widgets (accessed 2026-09-11)