Keyboard Navigation Is the Accessibility Test Most Sites Fail

Here is the cheapest accessibility test there is. Open your site, put your mouse in a drawer, and try to complete the most important task using only the keyboard. Tab to move forward, Shift+Tab to move back, Enter and Space to activate things, arrow keys inside menus and lists, Escape to close whatever opened.

Most sites fail within a minute. Not in obscure corners, either, but on the main navigation, the signup form or the checkout. I run this test on every project before any automated tool, because it finds the problems that matter most to real people and it takes almost no setup.

Who actually uses the keyboard

It is easy to imagine keyboard users as a tiny group. They are not. People with motor impairments who cannot use a mouse precisely rely on keyboards, switch devices or voice control, all of which move through the page in the same order the Tab key does. Screen reader users navigate largely by keyboard. People with a broken trackpad, a temporary wrist injury or a baby on one arm use the keyboard. And plenty of power users simply prefer it because it is faster.

So keyboard access is not a feature for a niche audience. It is the foundation that several other kinds of assistive technology are built on. If the keyboard path through your site is broken, those tools break too.

The five failures I see most often

After running this test on a lot of sites, the same handful of problems turns up again and again.

• Invisible focus. Someone added outline: none years ago because the default ring looked ugly, and now nobody can see where they are on the page.
• Fake buttons. A <div> with a click handler looks like a button but cannot be reached with Tab and does nothing on Enter or Space.
• Focus traps. A modal, an embedded map or a chat widget swallows focus and there is no way out short of reloading.
• Lost focus. A modal closes, or content is deleted, and focus jumps back to the top of the page, forcing the user to tab through everything again.
• Illogical order. CSS has moved things visually so the tab order jumps from the header to the footer and back to the middle.

Every one of these is invisible to a mouse user and immediately obvious to someone pressing Tab.

Fix focus visibility first

If you only fix one thing, make the focus indicator visible. The :focus-visible pseudo-class solved the old argument between designers and accessibility advocates: it shows a focus style for keyboard users but not for mouse clicks, so nobody has to choose between looks and usability.

A good focus style has strong contrast against both the element and its background. A two or three pixel outline with an offset, in a colour that stands out from your palette, works on almost any design. Avoid relying on a subtle background tint alone, which disappears on some screens and for people with low vision. The WCAG 2.2 focus appearance criteria give concrete numbers if you want a target.

Use real elements and the platform does the work

Nearly every fake button problem goes away when you use <button> for actions and <a href> for navigation. Real buttons are focusable, respond to Enter and Space, announce themselves to screen readers as buttons, and can be disabled properly. Recreating all of that on a <div> takes a tabindex, a role, two key handlers and careful state management, and most attempts miss something.

The same applies to dialogs, menus and disclosure widgets. Native <dialog> handles Escape and keeps focus inside, and <details> gives you an accessible expand and collapse with no script. We cover these elements in more depth in what modern CSS can do now that used to need JavaScript.

Manage focus when the page changes

Single-page apps and dynamic interfaces move content around without a page load, and the browser does not know where focus should go next. You have to tell it.

When a modal opens, move focus into it, usually to the first interactive element or the dialog heading. When it closes, return focus to the button that opened it. When a route changes in a single-page app, move focus to the new main heading so screen reader users hear where they are. When an item is deleted from a list, move focus to the next item or to a sensible container. These are small pieces of code, but they are the difference between an interface that feels coherent and one that keeps dropping you at the top of the page.

Why automated audits are not enough

The usual advice is to run Lighthouse or axe and fix whatever they flag. Do run them, they catch real problems like missing labels and poor contrast. But I disagree with treating a clean automated score as proof of accessibility, which is how many teams use it.

Automated tools can check whether an element has a role and a name. They cannot tell whether the tab order makes sense, whether focus returns to the right place after a modal closes, or whether a custom dropdown actually works with arrow keys. Studies of automated checkers commonly estimate they catch somewhere between a quarter and a half of real accessibility issues. A perfect Lighthouse score on a site you cannot use without a mouse is common, and it is worse than useless if it makes the team think the job is done.

Use the tools for what they are good at, then do the keyboard pass yourself. It takes ten minutes and finds things no scanner will.

A ten minute keyboard checklist

Pick your three most important user journeys and run through each one:

1. Can you see where focus is at every step?
2. Can you reach every interactive element, and only interactive elements?
3. Does the order follow the visual layout and reading order?
4. Do Enter and Space activate buttons, and do arrow keys work in menus and tabs?
5. Can you open and close every overlay, and does focus land somewhere sensible afterwards?
6. Is there a skip link to jump past the navigation?

The same checks apply well beyond business sites. Games are a good example of how much difference this makes, and our article on finding online game platforms built with accessibility in mind shows what thoughtful keyboard and controller support looks like in practice.

Run this once and you will probably find two or three things to fix. Run it every release and those problems stop coming back. Keep reading in our Accessibility section.