Keyboard Accessibility: What Automated Scans Miss

A huge range of people never touch a mouse. Screen reader users navigate entirely by keyboard. People with tremors, repetitive strain injuries, or limited fine motor control rely on the Tab key, switch devices, or voice control that maps to keyboard commands. Even power users on a laptop often keep their hands on the keys. WCAG treats this as non-negotiable: success criterion 2.1.1 Keyboard requires that all functionality be operable through a keyboard, full stop.

The reason keyboard access is such a good proxy for overall accessibility is that it forces your interface to expose its structure honestly. A button that only responds to a click, a menu that only opens on hover, a modal that traps focus — these break the moment you remove the mouse. If your site works with a keyboard, it is usually well on its way to working with assistive technology generally. For the broader legal context on why this is enforceable, see our ADA website compliance guide.

The same handful of patterns account for the overwhelming majority of keyboard failures we see across scans and manual reviews:

• Clickable <div>s and <span>s. A styled div with an onClick handler looks like a button but isn't focusable and can't be triggered by Enter or Space. Use a real <button> or <a>.
• Hover-only menus. Dropdowns that open on mouse hover but never on focus leave keyboard users unable to reach nested links at all.
• Invisible focus indicators. A designer removed the “ugly” outline with outline: none and never replaced it. Now you can tab, but you can't see where you are.
• Focus traps. A modal, cookie banner, or carousel that grabs focus and never lets go — the keyboard user is stuck until they reload the page.
• Illogical tab order. Positive tabindex values or DOM elements shuffled around with CSS send focus jumping around the page in an order that makes no sense.
• No “skip to content” link. Without one, keyboard users have to tab through your entire nav on every single page before they reach the actual content.

You don't need a lab or a screen reader to start. Open your most important page, click once in the address bar to move focus off the page, and then run this:

1. Tab forward through the whole page. Every link, button, and form field should receive focus, in a logical order, with a clearly visible indicator at each stop. Use Shift+Tab to go backward and confirm it's symmetrical.
2. Operate everything with Enter and Space. Buttons should fire, links should follow, menus should open. If something only works when clicked, it fails 2.1.1.
3. Escape out of overlays. Open a modal or dropdown, then press Esc and Tab. Focus should return to where you were, not vanish or loop forever inside the closed element.
4. Watch for the disappearing cursor. Any moment where you lose track of where focus is means the indicator failed — a real barrier, even if the element is technically reachable.

Pair that manual pass with a scan to catch the mechanical issues you can't see by tabbing. Run the page through our free WCAG checker or the ADA compliance checker, then keep the printable WCAG checklist open so nothing slips through the manual half.

You will see widgets that claim to add keyboard navigation automatically. Be skeptical. A JavaScript layer bolted on top of broken markup can't reliably teach a <div> to behave like a button, restore a sane tab order, or untangle a focus trap without introducing new ones. Testers who file accessibility complaints often specifically look for these tools, and the underlying page still fails. If you're weighing one, read our honest comparisons of accessiBe and UserWay first. Real keyboard access comes from real HTML, not a paint job.

And because keyboard behavior regresses easily — a new component, a theme update, a third-party script — it's worth re-checking on a schedule rather than once. That's the whole point of continuous monitoring: catch the regression the week it ships, not the day a demand letter arrives.