Keyboard Navigation Accessibility Test: Check Your Site Without a Mouse

Why keyboard navigation matters for accessibility

The W3C explains that content operable through a keyboard can be used by blind people, who cannot use devices such as mice that require eye-hand coordination. It can also be used by people who rely on alternate keyboards or devices that act as keyboard emulators: speech input software, sip-and-puff software, on-screen keyboards, scanning software and a variety of assistive technologies.

People with low vision may have trouble finding or tracking a pointer on screen; for them, software can be much easier, or only possible, to use from the keyboard. Some people with hand tremors find a mouse very difficult and therefore usually use a keyboard. Success criterion 2.4.7 also helps people with attention, short-term memory or executive function limitations, who benefit from being able to discover where the focus is.

A common misunderstanding: MouseKeys, which move the pointer with the keys, do not satisfy success criterion 2.1.1. To the application they look like a mouse, not a keyboard.

Preparing your keyboard test

Pick a few representative pages: the home page, a content page, a form, and the journeys that matter to your visitors, such as sign-up or checkout. Put the mouse away, and if needed click once in the address bar so you start from the top of the page.

Throughout the test, use only these keys:

• Tab to move forward to the next interactive element, Shift+Tab to move back;
• Enter and Space to activate elements: the W3C notes that focused buttons can generally be activated with both keys. Following this convention is best practice, but a custom button that only reacts to Enter still satisfies success criterion 2.1.1;
• the arrow keys to move inside a component when Tab is not enough;
• Esc to close a dialog or leave a component.

Step 1: is everything operable from the keyboard (2.1.1)?

Success criterion 2.1.1 requires all functionality of the content to be operable through a keyboard interface without requiring specific timings for individual keystrokes. The W3C gives examples of such timings: having to repeat or execute several keystrokes within a short period, or having to hold a key down for an extended period before the keystroke is registered.

The only exception covers functions whose underlying nature depends on the path of the movement, not just its endpoints, such as freehand drawing or a watercolor painting program where brush strokes vary with the speed and duration of the movement. The exception concerns the function, not the input technique: handwriting depends on the path, but the text input it produces is not exempt. Likewise, drawing straight lines, resizing windows or dragging objects to a location, when the path to that location is not relevant, do not fall under the exception.

The criterion does not require every visible control to receive focus: there must be a way to perform the same, or a comparable, action from the keyboard. The W3C cites a search form whose submit button does not receive focus, yet passes because users can press Enter in the text field. Similarly, a drag and drop feature can offer cut and paste or form controls to move objects.

What to note during the test:

• a menu, tab, carousel or button that reacts to the mouse but never to the keyboard, with no other way to perform the action from the keyboard (failure F54: using only pointing-device-specific event handlers, including gestures);
• an element that emulates a link (failure F42, which also concerns criteria 1.3.1, 2.1.3 and 4.1.2) and does not work with the keyboard;
• an element that loses focus as soon as it receives it because of a script (failure F55);
• an iframe with interactive elements excluded from the tab order, or scrollable content that cannot be reached with sequential focus navigation.

Step 2: no keyboard trap (2.1.2)

Success criterion 2.1.2 requires that if keyboard focus can be moved to a component, it can be moved away using only a keyboard interface. If this requires more than unmodified arrow or Tab keys or other standard exit methods, users must be advised of the method. The W3C notes that in most environments with a physical keyboard, Esc is a commonly used standard exit method.

This criterion applies to all content on the page, even content not used to meet other criteria: a single trap can interfere with the use of the whole page. Traps often appear when content is rendered with plug-ins or embedded applications, or with custom components and widgets built without keyboard users in mind.

Restricting focus is not always a failure. In a modal dialog, focus can cycle from the last control back to the first, as long as users know how to leave, for instance by closing it with Cancel, OK or Esc. In a rich text editor where Tab sets indentation, an instruction can tell users which shortcut moves focus out, such as Alt+F10 in the W3C example.

To test, enter each component (video player, map, editor, third-party widget, modal) and try to leave with Tab, Shift+Tab, the arrow keys and Esc. The criterion only waives instructions when exit works with unmodified Tab or arrow keys, or a standard exit method; the W3C points out that the specification does not define standard exit methods, which depend on hardware, user agent and operating system. If you cannot leave with the keyboard, or leaving requires another shortcut that no instruction mentions, it is a failure.

Step 3: is the focus always visible (2.4.7)?

Success criterion 2.4.7 requires any keyboard operable user interface to have a mode of operation where the keyboard focus indicator is visible. The W3C is clear: without a focus indicator, sighted keyboard users cannot operate the page. The indicator must not be time limited: when keyboard focus is shown, it must remain visible.

Browsers may show focus only when the keyboard is used; that is acceptable. However, failure F78 covers styling outlines and borders in a way that removes the focus indicator or makes it invisible. Recognised techniques include the browser's or platform's default focus indicator, a visible author-supplied indicator, a two-color indicator to ensure contrast, or the CSS :focus-visible pseudo-class.

Mind the contrast: since a focus indicator is usually non-text content such as an outline, it is also subject to success criterion 1.4.11 Non-text Contrast (Level AA). Success criterion 2.4.13 Focus Appearance (Level AAA) gives guidance on the indicator's size and shape.

During the test, each time you press Tab you should be able to tell at once which element has focus: a border around a button, or a text cursor in a field.

Keyboard navigation checklist

Keep this list at hand, page by page, and record each issue with the element concerned:

• Every link, button, field and custom control can be reached, or its action performed another way, from the keyboard.
• No action requires rapid repeated keystrokes or holding a key down for a long time.
• Scrollable content and interactive iframes are reachable with sequential navigation.
• You can leave every component with unmodified Tab or arrow keys, or a standard exit method such as Esc; otherwise an instruction explains how.
• You can leave every modal dialog from the keyboard, for instance by closing it with Esc or a button.
• Focus is visible on every element and does not disappear after a moment.
• No script removes focus from an element when it receives it.
• Extra good practice, outside the three criteria covered here: note any focus order that feels confusing compared with the reading of the page.

Pairing manual testing with continuous monitoring

Keyboard testing remains a human task: someone has to go through the pages and judge what they see. To avoid letting a regression slip by between two tests, you can run a free test of your site with Conformly, then turn on continuous monitoring and keep your manual keyboard passes for key journeys.

Frequently asked questions

Further reading on Conformly

• Fix invisible focus in HTML
• RGAA criterion 12.9 on keyboard traps
• RGAA criterion 7.3 on keyboard-operable scripts

Sources

This article relies on the official sources listed at the end of the page.

• W3C — Comprendre 2.1.1
• W3C — Comprendre 2.1.2
• W3C — Comprendre 2.4.7