Keyboard Accessibility: The Test Anyone Can Run in Ten Minutes

There is one accessibility test that requires no software, no training and no budget, and it finds more real problems than almost anything else you can do in an afternoon. Put your mouse aside and try to use your website with the keyboard alone.

Tab moves forward. Shift+Tab moves back. Enter activates links and buttons. Space activates buttons and scrolls. Arrow keys move within components like menus, radio groups and sliders. That is the whole vocabulary.

If you cannot complete your primary user journey with those keys, a significant group of people cannot use your site at all — and no amount of colour contrast or alt text compensates.

Who this affects

Keyboard access is often described as a screen reader issue. It is much broader than that.

Screen reader users do navigate by keyboard, so it covers them. But so do people with motor conditions who use a keyboard because a mouse demands fine pointer control they cannot reliably produce; people using switch devices, sip-and-puff controls or head pointers, all of which emulate keyboard input; people using voice control software, which drives the same underlying focus model; people with tremor, arthritis or repetitive strain injury; people using a laptop with a broken trackpad; and a large population of power users who simply move faster by keyboard.

You will find confident percentages online for how many people are "keyboard-only" users. Treat them with suspicion — there is no credible published measurement of that population, and the category is poorly defined because most people move between input methods depending on context and fatigue. The case for keyboard access does not need a statistic. It rests on the fact that the keyboard is the common substrate that every one of those assistive technologies is built on top of.

What WCAG actually requires

Four success criteria carry most of the weight.

2.1.1 Keyboard (Level A). All functionality must be operable through a keyboard interface, without requiring specific timings for individual keystrokes. Everything a mouse can do, a keyboard must be able to do.

2.1.2 No Keyboard Trap (Level A). If focus can move to a component, it must be possible to move focus away again using only the keyboard. This is one of the four criteria that applies even to content you are not claiming conformance for, because a trap does not degrade the experience — it ends it.

2.4.3 Focus Order (Level A). When the order of navigation affects meaning or operation, focus must move in an order that preserves that meaning. Practically: focus should follow the visual reading order of the page.

2.4.7 Focus Visible (Level AA). There must be a visible indication of which element has keyboard focus. If you cannot see where you are, you cannot navigate.

WCAG 2.2 adds 2.4.11 Focus Not Obscured (Minimum) at AA: the focused element must not be entirely hidden behind sticky headers, cookie banners or floating widgets.

The most damaging thing you can do

outline: none.

Browsers ship a visible focus indicator by default. Designers frequently find it ugly — it is a plain ring drawn by the browser, and it does not match anyone's design system. So it gets removed, and unless something replaces it, keyboard users are now navigating an invisible cursor.

This is not a rare mistake. The HTTP Archive's Web Almanac, which analyses millions of sites annually, found that the share of sites explicitly removing the default focus outline was 67% in 2025, up from 53% in 2024 — a reversal, since the same measure had fallen from 86% in 2022. The long-run direction is not settled, but two-thirds of sites removing the indicator is a poor position from which to argue the problem is solved.

The fix is not to accept the browser default. It is to design a focus indicator you actually like — a ring in your brand colour, an inversion, a thick underline — and apply it consistently. :focus-visible lets you show it for keyboard users without drawing it on every mouse click, which removes the aesthetic objection almost entirely. What you must not do is remove it and replace it with nothing.

While you are there: a focus indicator needs contrast too. Under 1.4.11 Non-text Contrast, the indicator needs 3:1 against adjacent colours. A pale grey ring on a white background is technically visible and practically useless.

The ten-minute test

Start at the top of your home page, put the mouse down, and press Tab repeatedly. Watch for these seven things.

1. Can you always see where you are? If the indicator disappears at any point, note the element. This is the most common failure and usually the easiest fix.

2. Does focus move in a sensible order? It should follow the visual layout. Focus jumping from the header to the footer and back into the middle of the page usually means the DOM order does not match the visual order — often the result of CSS positioning or flexbox order.

3. Can you escape everything you enter? Open every modal, dropdown, date picker, video player and embedded widget, and try to get out with the keyboard. A modal that traps focus permanently is a hard stop. A modal that does *not* trap focus while open is a different bug — focus should cycle within an open dialog and return to the trigger when it closes.

4. Can you reach everything a mouse can reach? Hover-only menus are a classic failure: the submenu appears on mouse hover and is unreachable by keyboard. So are custom controls built from <div> elements, which are not focusable unless you add tabindex and key handlers. This is where the first rule of ARIA earns its keep — if a native <button> will do the job, use a native <button>, because it comes with focusability, keyboard activation and the right role already built in.

5. Is there a skip link? A keyboard user landing on a page with forty navigation links must tab through all forty on every page unless you provide a way past. A "Skip to main content" link as the first focusable element, visible when focused, solves it. WebAIM found skip links on only 17.1% of home pages in February 2026.

6. Is anything hidden but still focusable? Off-screen menus, collapsed accordions and hidden carousel slides often remain in the tab order. The symptom is distinctive: you press Tab and the focus indicator vanishes into nowhere for several presses. Content that is visually hidden must be removed from the tab order too.

7. Does the sticky header eat your focus? Tab down a long page and watch whether the focused element scrolls up underneath a fixed banner. That is the WCAG 2.2 criterion 2.4.11 failure, and it is extremely common on sites with sticky navigation.

Why automated tools find so little of this

A scanner can tell you that a <div> has a click handler and no keyboard handler. It can flag positive tabindex values, which distort focus order. It can detect that a focus style was removed in CSS.

It cannot tell you whether the focus order makes sense, whether a modal returns focus to the right place, whether your custom dropdown behaves like a dropdown, or whether a person can actually complete your checkout without a mouse. Those questions require a human pressing keys.

That gap is exactly why the UK Government Digital Service's monitoring of public sector websites found 2.4.7 Focus Visible as the single most common failure in its 2022–2024 programme, at 13.3% of all issues found, with 2.1.1 Keyboard third at 10.8%. These are not obscure problems; they are the everyday result of testing with a mouse only.

Ten minutes with the Tab key will tell you more about your site's accessibility than an hour reading the specification. Then, when you know where the problems are, our guide to running a structured accessibility audit covers how to work through them systematically.

*Success criteria are from the W3C's published WCAG 2.2 Recommendation. Focus outline removal figures are from the HTTP Archive Web Almanac 2025 accessibility chapter; the skip link figure is from the WebAIM Million 2026 report (analysis run February 2026, published March 2026); public sector failure rankings are from the UK Government Digital Service accessibility monitoring report covering 2022 to 2024.*