Keyboard accessibility

Keyboard accessibility means that every action a user can perform on a page can be performed using only the keyboard. It is the most non-negotiable accessibility requirement: without it, no other assistive technology works.

The keyboard interface is the universal interface

Screen readers, switch devices, voice control, eye-tracking — every assistive technology used on the web ultimately routes through the keyboard layer. A user with no motor disability at all might never press Tab, but the same site has to be fully operable that way for disabled users to use it.

This is why 2.1.1 Keyboard is a Level A criterion: failing it doesn’t make the site harder, it makes the site unusable for entire user populations.

What “keyboard operable” actually requires

• Tab and Shift+Tab move focus forward and backward through interactive elements.
• Enter activates links and most buttons.
• Space activates buttons and toggles checkboxes/radios.
• Arrow keys navigate within composite widgets (tab panels, menus, radio groups, listboxes, sliders).
• Escape dismisses modal dialogs, popovers, and dropdowns.
• Page Up/Down, Home/End navigate long content where the platform convention applies.

A widget that doesn’t implement the keyboard contract that screen-reader users expect from its role — say, an ARIA combobox that responds to clicks but not to arrow keys — is technically focusable but functionally broken.

The fastest manual audit

Tab through a page from the very top (address bar focus, then Tab) all the way to the footer. Tab order should match visual order. Every clickable thing should receive focus exactly once. Pressing Enter or Space on a focused element should produce the same result as clicking it. Pressing Escape inside a modal should close it. If anything is unreachable, anything is reached out of order, or anything traps focus, you’ve found bugs.

Five minutes of disciplined Tab navigation finds more accessibility issues than fifteen minutes of axe-core scanning.

Common failure patterns

• <div onclick> for clickable cards. Not focusable, not keyboard-activatable, completely invisible to screen readers as an interactive element. Use <button> (for actions) or <a href> (for navigation).
• Custom dropdowns that don’t open on Enter/Space. Built with click handlers only; keyboard users can focus the trigger but not open the list.
• Modal dialogs that don’t trap focus. Tab moves focus out of the modal and into the (visually-hidden) page behind. Users can’t see where they are.
• Modal dialogs that over-trap focus. Escape doesn’t close. The user is stuck.
• Skip-link target not focusable. The skip-link jumps to #main but <main id="main"> lacks tabindex="-1", so focus doesn’t actually move and the next Tab restarts from the top of the page.

Two libraries are worth knowing: focus-trap for managing focus inside modals, and tabbable for finding the focusable elements inside a container. Both are tiny and unopinionated.