Keyboard accessibility: make websites usable without a mouse

Many people never operate websites with a mouse. People with motor impairments, blind users working with a screen reader, people with tremors – and not least many experienced users – navigate with the keyboard. If a page only works with a mouse, it shuts these groups out. The WCAG therefore make keyboard accessibility a fundamental requirement. This article explains what is required, how keyboard navigation works and how you can check it yourself in a few minutes. It is part of our pillar guide on making a website accessible; what the WCAG are overall is explained in the WCAG guide

Why keyboard accessibility matters

Many people rely on the keyboard: people who cannot guide a mouse precisely, blind users who control a screen reader by keyboard, and people with tremors or strain-related pain. On top of that, keyboard accessibility is the foundation for screen reader use – what cannot be operated by keyboard cannot be operated with a screen reader either. So this is not an edge case but a foundation.

What the WCAG require

Several success criteria revolve around the keyboard:

• All functions must be operable by keyboard (2.1.1, Level A).
• There must be no keyboard trap – you must always be able to move out of any element again (2.1.2, Level A).
• The focus order must be logical (2.4.3, Level A).
• The keyboard focus must be visible (2.4.7, Level AA).
• A skip link should let users bypass repeated blocks of content (2.4.1).

WCAG 2.2 added that the focus must not disappear behind fixed elements (2.4.11). Most of these points sit at Level A, the visible focus at AA – all within the AA scope that the EAA and EN 301 549 point to. See the WCAG guide for how the conformance levels fit together.

The basics of keyboard operation

Users expect a familiar pattern that custom components must follow too: the Tab key moves you forward through the interactive elements, Shift and Tab move you back. Enter and the Space bar activate links and buttons. Within a component – such as a radio group, a menu or a slider – you navigate with the arrow keys. Escape closes dialogues and menus.

The keyboard test: how to check it yourself

Set the mouse aside and navigate with the keyboard alone. Watch for five things: Can you reach every interactive element? Is the focus always visible? Does the order follow the visible layout (top to bottom, left to right)? Can you activate everything and get out of everywhere again (no traps)? And do dialogues hold the focus while they are open, and return it sensibly when they close?

This test takes only a few minutes and reveals a lot. For how it fits into a full review, see testing accessibility

Common problems

• Custom controls built from non-semantic building blocks (clickable divs) that cannot be focused or operated at all.
• A focus indicator removed via CSS (outline: none) without a visible replacement.
• An illogical focus order because elements were visually rearranged with CSS.
• Keyboard traps in dialogues, embedded content or third-party widgets.
• Unmanaged focus when opening and closing dialogues, so that users lose their place.

Automated tools catch some of this – such as missing focusability – but whether the order is logical or a custom component really works is something they do not judge reliably. More on this in our guide to testing accessibility

This guide is not legal advice. For a binding assessment of your specific case, consult a qualified professional.