Keyboard use: the test you can run yourself in five minutes

What this is about

Some of your visitors do not use a mouse. Some because of a motor impairment, some because they use a screen reader, some because they work with voice input. For them the Tab key is the navigation instrument.

For that to work, three things have to be right: every control has to be reachable by Tab, the order has to follow the reading direction, and it has to be visible at all times where the focus is.

On top of that comes the structure underneath: landmarks (header, nav, main, footer), with which screen reader users jump straight into the main content, and a skip link that skips the navigation.

Why it matters

WCAG 2.1.1 (Level A) requires that all functionality can be operated by keyboard. WCAG 2.1.2 requires that users never get stuck anywhere — the classic case is a cookie banner or a dialog that cannot be closed by keyboard. And WCAG 2.4.7 (Level AA) requires a visible focus with at least 3:1 contrast to its surroundings (Rheinwerk, Barrierefreie Webseiten, ch. 8.2).

The skip link is the point where the effort is most visible. Without it a keyboard user has to tab through the complete navigation on every single page before they arrive at the content. With a menu of thirty entries that is thirty presses of Tab — per page.

I see two classes of error regularly.

Focus made invisible. Somewhere in the CSS there is outline: none, because someone found the blue default frame ugly. The page is then still technically usable, but nobody sees where they are any more. It is like hiding the mouse pointer.

Positive tabindex values. An element with tabindex="1" jumps to the start of the document's entire tab order, regardless of where it stands. A few such values make the order unpredictable. The recommendation is unambiguous: achieve a logical order through the HTML structure rather than through tabindex (Rheinwerk, Barrierefreie Webseiten, ch. 8.2).

There is also a range of errors that can be established without any judgement and are therefore hard to argue about: ARIA references that point to nothing. Roles that do not exist. An ID assigned twice that a label or a skip link refers to — then only the first match is found. A skip link whose target is missing or cannot take focus. Such cases are simply broken.

One more thing on controls: WCAG 2.5.8 (Level AA) requires at least 24 × 24 CSS pixels for click targets — with one exception that matters: a smaller target is fine if nothing else lies within 24 pixels of its centre. Well-spaced footer links are therefore not an error.

And a word on accessibility overlays: these widgets that show a control bar via script change nothing about the points named here. What they offer is font sizes and contrast switches. What they do not repair is missing labels, broken focus orders and keyboard traps.

How to check it yourself

This is the test you really can do yourself, and it takes five minutes.

Open your home page in a private window — without accepting cookies, because that is exactly when the banner is in the way and you see how the page actually behaves (Rheinwerk, Barrierefreie Webseiten, ch. 8.2). Put the mouse aside. Then press Tab.

Look out for five things:

Is the very first stop a skip link (“Skip to content”)? It may be invisible as long as it is not focused — but as soon as it has focus, it has to become visible.

Do you see at every step where you are?

Does the order follow what you read — top to bottom, left to right?

Can you get out again everywhere? Deliberately open the menu, an accordion, a modal. Does Escape close it? Do you then get back to where you were?

Can you trigger everything? Links with Enter, buttons with Enter and Space.

If at some point you cannot go on or no longer know where you are, you have found the finding.

What to do if it is missing

Put a skip link as the first focusable element, linked to the id of the <main> element.

Replace every outline: none with a visible focus style of your own. A proven value is an outline of at least 2 px with a little offset:

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

Remove all positive tabindex values. If the order is wrong afterwards, the HTML order is wrong — and that should be repaired, not overridden.

Build the page structure with real landmarks: one <header>, one <main>, one <footer>, <nav> for navigation blocks, and with several <nav> an aria-label each to tell them apart.

For interactive elements, reach for the native ones first: <details>/<summary> for accordions and <dialog> with showModal() for modals bring focus management, Escape behaviour and return of focus without anyone having to program them.

And for click targets: enlarge the clickable area through padding, not through font size.

Sources

• WCAG 2.1.1 (Level A) requires full keyboard operability; WCAG 2.1.2 forbids keyboard traps, classic case a cookie banner or dialog without a keyboard exit; WCAG 2.4.7 (Level AA) requires visible focus with 3:1 contrast under WCAG 1.4.11; test in an incognito window without cookie consent; checklist reachability, tab order, visible focus, getting out, keyboard-only function; positive tabindex values make an element one of the first focusable ones in the document and are error-prone; logical order through HTML structure rather than tabindex; WCAG 2.4.11 Focus Not Obscured; focus order follows source order -- @ctx:atlas-accessibility-rheinwerk-barrierefreie-webseiten-08-02-keyboard-operability@1 -- Rheinwerk, Barrierefreie Webseiten, ch. 8.2
• WCAG 2.4.1 Bypass Blocks (Level A): a mechanism for skipping repeated content; skip link as the first focusable element, linked to the id of the main element; without it every page has to be tabbed through completely -- @ctx:atlas-accessibility-criteria-2-4-1-bypass-blocks@1
• WCAG 2.5.8 Target Size (Minimum), Level AA: at least 24 × 24 CSS pixels; exception with sufficient spacing to neighbouring targets; enlarge the click area through padding -- @ctx:atlas-accessibility-criteria-2-5-8-target-size-minimum@1
• Landmarks header / nav / main / footer on every page, several nav each with aria-label; no positive tabindex; visible focus indicator on all interactive elements, at least 2 px, code example :focus-visible; prefer native details/summary and dialog because of built-in focus management and Escape behaviour; keyboard behaviour per component -- @ctx:atlas-accessibility-wcag22-checklist@1
• Keyboard accessibility and focus management as the technical basis of the EAA/BFSG requirements; the most expensive remediation item is keyboard-operable custom widgets -- @ctx:atlas-legal-eu-accessibility-act@2