Keyboard navigation accessibility

Keyboard access is not a niche concern. It covers people with motor disabilities who cannot use a mouse, people using switch devices or voice control, screen reader users, people with temporary injuries, and a large number of people who simply prefer the keyboard. Anything reachable by mouse but not by keyboard is unusable for all of them.

• 2.1.1 Keyboard (A) — all functionality must be operable through a keyboard. This is the core requirement.
• 2.1.2 No Keyboard Trap (A) — if focus can move into a component, it must be able to move out. Modals are the classic offender.
• 2.4.3 Focus Order (A) — focus must move in an order that preserves meaning and operability.
• 2.4.7 Focus Visible (AA) — there must be a visible indicator showing where focus is.
• 2.4.11 Focus Not Obscured (AA, WCAG 2.2) — the focused element must not be hidden behind sticky headers, cookie bars or chat widgets.

2.1.1 and 2.1.2 are Level A, the baseline. Failing them is about as serious as web accessibility failures get.

One pattern accounts for a large share of keyboard failures: a non-interactive element wired up with a click handler.

<!-- not focusable, not announced, keyboard users cannot reach it -->
<div class="btn" onclick="submit()">Submit</div>

<!-- focusable and operable for free -->
<button type="button" onclick="submit()">Submit</button>

A div is not focusable and does not respond to Enter or Space. Using the right element gives you focusability, keyboard activation and the correct role without writing anything extra. Reach for tabindex and ARIA roles only when no native element fits, because then you also own the key handling.

The second most common failure is cosmetic in origin. Someone dislikes the default focus ring and removes it globally:

/* breaks 2.4.7 for every keyboard user on the site */
*:focus { outline: none; }

If the default ring does not suit the design, replace it rather than delete it. :focus-visible shows the indicator for keyboard users while keeping it off for mouse clicks, which is usually what people actually wanted:

:focus-visible {
  outline: 3px solid #1a73e8;
  outline-offset: 2px;
}

• Positive tabindex. tabindex="2" and friends override the natural order and almost always produce a confusing sequence. Use tabindex="0" to make something focusable and -1 to make it programmatically focusable only.
• Modals that do not manage focus. When a dialog opens, focus should move into it and be contained until it closes, then return to the element that opened it. Without this, keyboard users tab into the page behind the overlay.
• Custom widgets built from scratch. Dropdowns, tabs, carousels and comboboxes each have expected key behaviour. If you build your own, implement it or use a tested library.
• No skip link. Without a "skip to content" link, keyboard users tab through the entire navigation on every page.
• Sticky headers and chat widgets covering the focused element, which is the 2.4.11 failure.

The manual test takes about two minutes and finds most problems. Put the mouse aside and press Tab from the top of the page. Ask:

• Can I see where focus is at every step?
• Can I reach every control, including menus, modals, carousels and the cookie banner?
• Does the order follow the visual layout?
• Can I activate things with Enter and Space, and close them with Escape?
• Can I always get back out, or does focus get stuck?

Automated testing helps with part of this. A scan reliably catches controls with no accessible name, form fields with no label, and invalid ARIA, all of which cause keyboard and screen reader failures. It cannot judge whether the focus order makes sense or whether your indicator is visible enough, so it flags what it can prove and leaves the rest to you. Both halves are needed here.