Keyboard accessibility: the third that scanners miss

Automated accessibility scanners reliably catch about a third of issues. Keyboard access is squarely in the other two thirds, and it is where the most serious failures live — because a keyboard trap does not degrade the experience, it ends it.

The test takes ten minutes

Put the mouse away and complete your primary journey — sign-up, checkout, contact — using only Tab, Shift+Tab, Enter, Space and the arrow keys.

You will find problems. Everyone does the first time.

What to look for

• Can you see where you are? A focus indicator must be visible at every step.
• Does the order make sense? Focus should follow the visual reading order, not the DOM order if those differ.
• Can you get out? Open a modal, then try to leave it. Trapped focus is the most common serious failure.
• Does everything reachable do something? If Tab lands on a div nobody can activate, it is noise.
• Can you skip the navigation? Forty links before the content is a bad experience every single page load.

Never remove the focus outline

`outline: none` without a replacement is probably the single most damaging line of CSS for accessibility, and it is extremely common because the default outline is considered ugly.

Replace it rather than removing it. A custom focus ring that matches your design satisfies both concerns, and `:focus-visible` lets you show it for keyboard users without showing it on every mouse click.

Use the right element

Most keyboard problems come from a div being used where a button or link belonged.

A real `<button>` is focusable, activates on Enter and Space, and announces itself correctly — all for free. A div with a click handler does none of that, and reimplementing it correctly takes more code than using the right element in the first place.

Is keyboard accessibility a legal requirement?

Yes, in effect. WCAG 2.1 and 2.2 make keyboard operability a Level A requirement — the baseline level — and legislation including the European Accessibility Act and the ADA references those standards. It is also among the most clear-cut failures to demonstrate, which makes it a poor thing to be wrong about.

What about screen readers — do I need to test with one?

For anything beyond a simple content site, yes. Keyboard testing finds operability problems; a screen reader finds comprehension problems, which are different. VoiceOver ships with macOS and NVDA is free on Windows, so a basic pass costs nothing but an hour and reliably finds issues no automated scan reports.

For the issues that can be automated, our accessibility checker runs the same axe-core rules Lighthouse uses, and our contrast checker grades a whole palette at once.