Testing keyboard navigation: a tour without a mouse

Why is keyboard operation so important?

Many people do not use a mouse: blind people using a screen reader, people with motor impairments who use a keyboard, switches or voice control, and anyone who works quickly with the keyboard. Many assistive technologies rely on the same keyboard interface.

That is why, in criterion 2.1.1 at level A, WCAG requires all functions to be operable by keyboard. A keyboard test needs no tools and still finds some of the most serious barriers. The problems it reveals often have technical causes that affect screen readers too.

Which keys do you need for the test?

Some components deliberately have only one tab stop, such as a row of tabs. Within the group, you then move with the arrow keys. On a Mac, depending on the settings, Safari only moves between form fields with Tab. In the advanced settings, turn on the option for Tab to highlight every item on a webpage, or test in a different browser.

1. 1Tab moves to the next control, Shift+Tab to the previous one.
2. 2Enter follows a link or activates a button.
3. 3The space bar activates buttons, ticks checkboxes and scrolls the page when no element has focus.
4. 4Arrow keys move between radio buttons, menu items, tabs or slider values.
5. 5Escape closes dialogs, menus and drop-down lists.

How does a keyboard test work?

1. 1Reload an important page and do not click into it, so that you start at the top of the document.
2. 2Press Tab once: is there a ‘Skip to content’ link that lets you bypass the repeated navigation (WCAG 2.4.1)?
3. 3Use Tab to move through all interactive elements and watch the order and the focus.
4. 4Open the menu, search and accordions, and close them again.
5. 5Open a dialog, use it and close it with Escape.
6. 6Fill in a form, trigger an error and submit it.
7. 7At the end of the page, check whether footer links, embedded videos or maps can be reached and left again.
8. 8Repeat the tour at 200 per cent zoom and check that the focus stays within the visible area.

What is a sensible focus order?

The focus should move in an order that matches the content and its meaning (WCAG 2.4.3). Usually that means from top to bottom and from left to right, the way you read the page.

Typical causes of jumps are elements that have been visually rearranged with CSS and positive tabindex values such as tabindex="3". A common mistake is hidden menus whose links can still receive focus. The focus then spends ages on invisible elements.

Also check where the focus goes after an action. After adding something to the basket or loading more results, it should not fall back to the top of the page.

What should keyboard focus look like?

The focus must be visible (WCAG 2.4.7, level AA). Many websites remove the browser’s default outline with outline: none without setting their own focus style. Then nobody knows where they are.

Since WCAG 2.2, the focused element must also not be completely hidden by your own content, such as a fixed header or cookie banner (WCAG 2.4.11). A clear, high-contrast focus outline helps everyone; the AAA criterion 2.4.13 contains precise requirements for focus appearance. Also test the focus on coloured areas and images, because an outline in your brand colour can disappear there.

What are typical keyboard problems?

You avoid many of these problems with native HTML elements: button for actions, a with href for links, select and input for choices and input. They come with keyboard operation and focus built in. For custom components, the ARIA Authoring Practices describe which keys are expected.

1. 1Invisible focus: You cannot tell which element is currently active.
2. 2Keyboard trap: Focus can no longer leave an area, such as an embedded video or a map (WCAG 2.1.2).
3. 3Unreachable action: A visible button is a div with a click event and only responds to the mouse.
4. 4Custom drop-down lists or date pickers that can only be opened with a mouse.
5. 5Carousels that keep moving and take the focus with them.
6. 6Dialog with no way back: After closing, the focus lands somewhere unexpected.
7. 7Single-letter keyboard shortcuts that can neither be turned off nor changed (WCAG 2.1.4).

How should dialogs and menus behave?

For modal dialogs, the W3C’s ARIA Authoring Practices describe a clear pattern: when the dialog opens, the focus moves into it. Tab and Shift+Tab only move within the dialog. Escape closes it. The focus then returns to the element that opened the dialog.

Keeping the focus inside the open dialog is intentional and not a keyboard trap, as long as the dialog can be closed again by keyboard. For drop-down menus, Escape should close the menu and return the focus to the button that opened it. Check the cookie banner too: it should be reachable early with Tab and be possible to accept or decline by keyboard.

How do you document keyboard problems?

Note the URL, browser, starting point, key presses and the behaviour you observed. Describe the blocked task rather than just writing ‘keyboard doesn’t work’. That way developers can reproduce the problem and retest it after a change. An example: ‘Chrome, home page, Tab seven times: focus disappears behind the cookie banner, menu cannot be reached.’

The keyboard test is not a complete assessment. Add screen reader tests, zoom and automated findings. A scanner such as the Accessonaut check finds controls without names, for example, but it does not detect an illogical focus order. For key journeys, feedback from people who use these ways of access every day helps.