Keyboard navigation.

Keyboard navigation means a site can be used end to end with only the keyboard, no mouse — one of the most fundamental level A requirements of WCAG.

When asked where to begin an accessibility audit, the answer is nearly always the same: put the mouse away. The keyboard tour is the one method that needs no tools, takes ten minutes, and surfaces the majority of defects.

The reason: keyboard access is an indicator of many other things. A component that does not work with the keyboard is almost always semantically wrong too — a click handler bound to a div, a button imitated with a div, a menu tied to mouse events. The keyboard tour catches all of these at once.

Who navigates by keyboard

The common assumption is that keyboard navigation serves a small minority. The reality is wider.

1. Users with motor impairments — people who cannot perform movements requiring mouse precision, or who have tremors.
2. Screen reader users — they navigate almost entirely by keyboard; the mouse pointer is meaningless to them.
3. Switch access and eye tracking users — these technologies emulate keyboard events, so keyboard support is their only path too.
4. Temporary situations — a broken arm, a mouse in a moving box, a failing touchpad.
5. Power users — everyone who never touches the mouse while filling a form. Numerically the largest group.

The last group shows that keyboard access is as much a usability item as an accessibility item. A good keyboard flow directly benefits everyone who fills forms fast.

The keyboard tour: the ten-minute method

The method is simple and needs no tools. Pull the mouse off the desk, reload the page, and try to use it with the keyboard alone.

1. Tab — move to the next focusable element. Shift+Tab moves back.
2. Enter — open the link, press the button, submit the form.
3. Space — press the button, toggle the checkbox, scroll the page.
4. Arrow keys — move within radio groups, dropdowns and tab groups.
5. Escape — close an open layer, menu or dialog.

During the tour you watch three things: is it visible WHERE the focus is at every step, does the order make sense, and do you get stuck anywhere. Each maps to a separate criterion.

Four common defects

The defects recurring in keyboard tours resemble one another, and each has a known fix.

Focus is invisible. This is the most frequent defect and almost always comes from the same line: a CSS rule removing the focus ring. The rule is usually written because “it looks ugly,” without noticing it cuts keyboard users off from the site entirely. The right fix is not removing the ring but designing your own.

The order makes no sense. The visual layout and the focus order can diverge — especially with elements repositioned by CSS. The user jumps to the right column, then back to the left, then right again. Matching source order to visual order is the only healthy fix; trying to repair it with positive tabindex makes things worse.

The focus trap. When a layer or dialog opens, focus gets caught inside and cannot leave via Escape or a close button. The user has no way out but reloading the page. 2.1.2 forbids this directly — and note, this is a level A violation.

Focus on an invisible element. A menu that is hidden on screen but still in the DOM can remain focusable in the Tab order. The user presses Tab several times seeing nothing and cannot tell where they went. Closed layers must also be removed from the focus order.

A component that cannot be navigated by keyboard is almost always semantically wrong too.

Using the right element solves it from the start

Most keyboard defects are born from choosing the wrong HTML element. When a div is used instead of a link, keyboard support, focusability and role announcement all have to be rebuilt by hand — and are usually rebuilt incompletely.

The rule is clear: a clickable thing that GOES somewhere is a link; a clickable thing that DOES something is a button. Both get keyboard support, focusability and the correct role from the browser for free. Adding these to a div is possible but unnecessary and error-prone.

The same logic holds for form elements. A custom-styled checkbox built by hiding the real checkbox and drawing a visual on top keeps its keyboard support; built from scratch with a div, it loses it. The first approach should always be preferred.

The skip link

If every page starts with the same navigation menu, a keyboard user has to Tab through the whole menu on every page. In a twenty-link menu, that is twenty keystrokes to reach the content — on every page.

The fix is what 2.4.1 asks for: the first focusable element of the page should be a link jumping straight to the main content. Normally invisible, it becomes visible on focus. It must appear on the first Tab and take the user to the main content on Enter.

A small detail is often missed: the skip link must not only scroll — it must move the focus to the target. A link that only scrolls looks like it works, but the next Tab returns the user to the top of the menu. Making the target element focusable solves it.

Tab order and source order

The order in which keyboard focus advances is determined by the HTML source order — not by the visual order CSS creates. When the two diverge, the result is navigation the user cannot make sense of: focus jumps to the top right of the screen, drops to the bottom left, then climbs back up. A page that looks tidy can be completely scrambled on the keyboard.

The most frequent cause of the divergence is modern layout tooling. In grid and flexbox layouts, changing the visual order of elements is a one-line job, and the change never touches the source order. A reordering done for mobile can break the focus flow on desktop — and nobody notices, because nobody Tabs on mobile.

The right fix is making the correction in the HTML, not the CSS: the source order should match the order in which things should be read. That is not always possible; where it is not, at least the critical flows — forms, checkout, search — must have a correct source order.

Trying to force the order with a positive tab index almost always makes things worse. Elements carrying a positive index come before ALL elements that carry none; adding a single positive index to a page moves that element to the very front and scrambles everything else. The only values worth using are zero (make focusable, keep the order) and minus one (make programmatically focusable, remove from the Tab order).

Custom components: the keyboard contract

When custom components — tabs, accordions, dropdown menus and the like — are written, users bring an expected key behavior for that component type. These expectations are not arbitrary; they come from operating system interfaces and are defined per component type in the WAI-ARIA authoring guide.

1. Tab group — Tab enters the group, arrow keys move between tabs, Tab exits into the content. Each tab is NOT a separate Tab stop.
2. Dropdown menu — Enter or arrow-down opens, arrow keys navigate, Enter selects, Escape closes and returns focus to the trigger.
3. Accordion — every header is a button; Enter or Space opens and closes.
4. Modal dialog — focus moves in when it opens, no passing behind while open, Escape closes and focus returns.
5. Radio group — one Tab stop for the group; the selection changes with arrow keys.

The shared logic of these contracts: Tab navigates BETWEEN components, arrow keys navigate WITHIN a component. Making every tab in a tab group its own Tab stop technically works but breaks the expectation and exhausts the user in a ten-tab interface.

Rather than writing these components from scratch, using built-in elements whose keyboard behavior is already correct — wherever possible — is always safer. A built-in element’s keyboard support is provided by the browser, tested, and compatible with assistive technologies.