Keyboard navigation is the litmus test for any accessible website. After all, if a site cannot be navigated using only the keyboard, it effectively excludes everyone who cannot use a mouse – including blind people and many with motor impairments. In this guide, I’ll draw on practical audit experience to show you who relies on a keyboard, which WCAG criteria apply, how to avoid keyboard traps, incorrect focus sequences and invisible focus indicators, and why this particular area cannot be checked by a scanner alone. Finally, I’ll reveal the test that anyone can carry out themselves in five minutes.
What is keyboard navigation?
Keyboard navigation means operating a website entirely using the keyboard – without a mouse at all. Users can use the Tab key to move from one control to the next, and Shift+Tab to go back. The Enter key and the Space bar trigger actions, the arrow keys navigate within components, and the Escape key closes open dialogue boxes.
There is a clear criterion behind this requirement. Success criterion 2.1.1 ‘Keyboard’ (Level A) stipulates that every function on a page must be accessible via the keyboard. There are no exceptions to this: anything that can be done using a mouse must also be possible using the keyboard.
What’s important is the underlying insight. Keyboard navigation is not just a niche feature for a select few. It is, in fact, the foundation on which many assistive technologies rely to function in the first place. If you get this wrong, you don’t just lose one user, but an entire group at once. That is why keyboard navigation is one of the first things we check in an audit.
Anyone who relies on a keyboard
A larger group of people rely on the keyboard than most people realise. First and foremost are blind people. This is because a screen reader is controlled entirely via the keyboard. This leads to a stark conclusion: if something doesn’t work with the keyboard, it won’t work with the screen reader either.
Added to this are motor impairments. People with Parkinson’s disease, spasticity or tendonitis are often unable to move a mouse with precision. Instead, they use the keyboard, special switches or voice control – and all these inputs ultimately end up as keyboard commands in the system. Users of screen magnifiers are also affected, as they need to see where the focus is at any given moment. Then there are people with only a temporary impairment, such as a broken arm.
The figures underscore this. Depending on the survey, keyboard and focus issues account for around 15 to 20 per cent of all WCAG violations. This makes them some of the most common barriers of all. I explain in detail how screen readers work in my guide to screen readers.
The five rules of accessible keyboard use
Accessible keyboard navigation can be broken down into five key criteria. Together, these form the basis against which an audit assesses keyboard usability. Three of these are already mandatory at the minimum Level A, whilst two further criteria are required at Level AA.
| Criteria | Level | What it’s all about |
|---|---|---|
| 2.1.1 Keyboard | A | Every function can be operated via the keyboard |
| 2.1.2 No keyboard trap | A | Emerging from each element again |
| 2.4.3 Focus order | A | A logical, sensible tab order |
| 2.4.7 Focus visible | AA | Visible focus indicator |
| 2.4.11 Focus not obscured (minimum) | AA | Focus not hidden behind content |
The final criterion is new. It was first introduced in WCAG 2.2 and fills a gap that frequently arose in practice. I discuss the details of these changes in the guide to the changes in WCAG 2.2. Taken together, these five rules ensure that a page can be navigated entirely without a mouse.
Accessible and usable: native versus custom elements
Most keyboard issues stem from a single mistake. Developers build control elements using the wrong components. A genuine button element and a link are, by design, accessible and actionable via the keyboard. A <div> element with a click handler, on the other hand, is not.
This ‘div soup’ is tricky. When using the mouse, this sort of pseudo-element appears to work perfectly. However, you can never access it using the keyboard because it isn’t included in the tab order and doesn’t respond to the Enter key or the space bar. If you still want to use it, you’ll need to add tabindex="0", a suitable role and your own keyboard handlers.
My practical advice is therefore simple. Use native HTML elements wherever possible. This is because they already provide focus, role and keyboard navigation without the need for any additional code. Where you need to use your own components, the guide to ARIA in web applications will help. The rule of thumb remains: look for native elements first; only use your own if there is no alternative.
Avoiding the keyboard trap
One particularly frustrating barrier is the keyboard trap. This occurs when a user navigates into an element using the Tab key but cannot navigate out of it again. Success criterion 2.1.2 ‘No keyboard traps’ (Level A) expressly prohibits this.
The causes are almost always the same. A custom-built dialogue box locks the focus but does not provide an Escape key to close it. A list that reloads endlessly ensures that the tab key never reaches the footer. Or an embedded third-party widget in an iframe takes the focus and refuses to give it back.
It is worth making an important distinction here. A modal dialogue box is indeed intended to retain focus – that is by design. The crucial point is simply that you can exit it at any time, usually by pressing Escape, and that the focus then returns to the point where it was triggered. The pitfall is not that the focus is retained, but rather the absence of an exit. Incidentally, it is precisely this return of focus that is most frequently overlooked in practice.
The correct order of focus
The order in which elements receive focus determines their orientation. Success criterion 2.4.3, ‘Focus Order’ (Level A), requires an order that preserves meaning and usability. As a general rule, this means that the focus follows the visual reading order, i.e. from top to bottom and from left to right.
This order is disrupted in a typical way. A positive tabindex value disrupts the natural sequence of individual elements and is therefore considered an anti-pattern. Reordering via CSS is also tricky: if the display is rearranged using Flexbox but the source code remains unchanged, the focus suddenly jumps across the page.
This can be prevented by following clear rules. Stick to the order in the source code and avoid positive `tabindex` values. Also, ensure that collapsed menus only allow their elements to be focused once they are open. I go into more detail about the relationship between source code and display in the guide to DOM structure.
The visible focus: the overlooked detail
No detail is overlooked more often than the visible focus indicator. Success criterion 2.4.7, ‘Focus visible’ (Level AA), requires that it must always be clear where the focus is currently located. It is precisely this criterion that is among the most frequently breached of all.
A classic mistake is a single line of CSS. Using outline: none, developers remove the focus border because they don’t like the way it looks – and replace it with nothing. This renders the page unusable for keyboard users, as they can no longer see where they are. The proper solution uses :focus-visible and a border with sufficient contrast of at least 3:1. This way, the highlight only appears when using the keyboard and does not interfere with mouse users.
WCAG 2.2 has further tightened the requirements in this area. The new criterion 2.4.11 ‘Focus Not Hidden’ (Minimum, Level AA) requires that the focused element must not be completely obscured by other content – such as sticky headers, cookie banners or chat windows. At the highest level, Criterion 2.4.13 ‘Focus Appearance’ (AAA) even specifies the minimum size and contrast of the focus indicator. I explain what matters when it comes to contrast in the guide on colours and contrast.
Controlling focus precisely: dialogues and dynamic content
As soon as content changes dynamically, the focus must be actively managed. When a dialogue box opens, the focus should be placed within it – usually on the first control or the close button. When it closes again, the focus must return to the point from which it was opened.
This is particularly important in modern single-page applications. If the view changes without the page reloading, the focus will otherwise lose its position. You should therefore place it deliberately at a suitable point, such as the new main heading, and announce the change via a status message (4.1.3 Status messages).
It is helpful to understand the `tabindex` values. A value of `0` places an element in the natural order. A value of `-1` makes it focusable only via script, for example to aid navigation when switching views. You should, however, avoid positive values, as they disrupt the order. With these three values, you can manage focus cleanly in almost any situation.
Jump links and keyboard shortcuts
Keyboard users need shortcuts; otherwise, navigating with the Tab key becomes a nightmare. This is precisely where Success Criterion 2.4.1 ‘Skipping blocks’ (Level A) comes into play. It requires a mechanism for skipping recurring blocks – in practice, a ‘Skip to main content’ link right at the top of the page.
Without a link like this, it becomes a bit of a hassle. That’s because a keyboard user would then have to tab through the entire navigation menu again on every subpage before reaching the actual content. A jump link saves them exactly that and can be implemented in just a few lines of code.
Keyboard shortcuts also deserve attention. If a page responds to individual letter keys, this may conflict with assistive technologies (2.1.4 Character Keyboard Shortcuts). It must be possible to disable or reconfigure such shortcuts. And since WCAG 2.2 came into force, drag gestures also require a keyboard alternative (2.5.7 Drag Gestures).
Operating your own components correctly using the keyboard
Whenever you create your own user controls, you must replicate their keyboard behaviour yourself. This is because users expect a menu, a tab or a drop-down list to behave in a certain way. And this behaviour is not arbitrary; it is defined in the W3C’s ARIA patterns.
In practice, this means something slightly different depending on the component. In a menu or tab bar, you navigate using the arrow keys, not the Tab key. You open and close an accordion section using the Enter key or the space bar. And you can scroll through a drop-down list using the arrow keys and close it again using the Escape key.
A tried-and-tested pattern behind this is the ‘wandering focus’. In this approach, only one element in the group has the value tabindex="0", whilst all the others have a value of -1. This means the tab key moves to the group as a whole, and the arrow keys navigate within it. Anyone who follows these conventions will build components that feel instantly familiar.
Keyboard navigation in forms
Forms are where keyboard navigation most often breaks down. This is because many control elements are crammed into a small space. You use the Tab key to move from field to field, and native fields such as text boxes, drop-down menus and tick boxes have their own built-in behaviour.
The problems start with custom solutions. A custom drop-down list or date picker is often a classic keyboard trap: you can get into it, but you can’t get out of it properly. You should therefore ensure that every field is accessible and that the focus moves to any error message as soon as it appears.
Another hidden risk is the automatic form submission. If simply moving the focus to a field triggers an action or even submits the form, this confuses keyboard users (3.2.1 When in Focus). You must avoid this at all costs. I cover more about design in the guide to accessible forms.
Keyboard navigation on mobile devices
Ein verbreiteter Irrtum lautet: Auf dem Smartphone zählt nur der Touchscreen. Das stimmt nicht. Denn auch mobile Geräte werden per Tastatur bedient – über angeschlossene Bluetooth-Tastaturen oder über Schalter-Steuerungen für Menschen mit starken motorischen Einschränkungen.
This criterion therefore applies across the board. Even on tablets and smartphones, every function must be accessible via the keyboard alone, without the use of a mouse or touchscreen. An interface that only responds to swiping or tapping excludes these users.
It is therefore important to take a holistic view. Don’t just test your application on a desktop; test it on a mobile device with an external keyboard as well. I go into more detail about what else matters when it comes to mobile services in the guide to mobile accessibility.
Common keyboard barriers in practice
The same mistakes recur time and again across many audits. These are the seven I see most frequently – and they can all be rectified:
- The incorrect component: a
<div>used as a button instead of a proper button. - Invisible focus: < 2 > with no visible replacement.
- A positive `tabindex` value that disrupts the order.
- A dialogue box with no exit: a modal window that cannot be closed using the Escape key.
- Custom selection lists that cannot be navigated using the arrow keys.
- A lost focus that vanishes into thin air after an action.
- Hidden but accessible: collapsed menus that you can tap to open.
One thing stands out here. Almost no errors arise from malice. Rather, they arise because development and testing are carried out using a mouse – and the mouse simply skips over all these problems.
Testing keyboard usability: the test anyone can do themselves
You don’t need to be a developer to spot the biggest keyboard problems. A simple test is all it takes.
A practical exercise – the five-minute tab key test: Put your mouse aside and navigate your page using only the keyboard. Press the Tab key repeatedly and pay close attention to five things. Firstly: Can you actually reach every control, every link and every form field? Secondly: Can you see where the focus is at all times? Thirdly: Does the focus follow the order of the visible layout, or does it jump around? Fourthly: Can you exit every dialogue box and every menu, using the Escape key if necessary? Fifthly: Can every element be activated using the Enter key, the space bar or the arrow keys? This test alone reveals most barriers – free of charge and without a single tool. Once you’ve done it, you’ll see your website in a whole new light.
Why scanners reach their limits here
The limitations of automated testing are particularly evident when it comes to keyboard navigation. This is because, of all the focus criteria in WCAG 2.2, only one can be tested fully automatically – the new 2.4.11, of all things. Everything else eludes the scanner.
The reason lies in the nature of the matter. Whether every element can actually be accessed, whether the order makes sense, and whether it is possible to exit a dialogue box can only be determined by a person actually tabbing through the page. A scanner may detect a missing focus marker in the code – but it cannot tell whether the interface actually works in practice.
This is exactly where our in-depth ‘Access Ready’ audit comes in. We test your website’s keyboard navigation manually and with real users of assistive technology – in other words, exactly as your visitors actually experience the site. Whereas a simple scan only picks up a fraction of the issues, we uncover the real barriers. This means you don’t receive a theoretical result, but a true picture of the site’s usability.
Would you like to know whether your website can be used without a mouse? In 30 minutes, we’ll walk you through the key navigation paths.
Frequently asked questions about keyboard navigation
To round off, here are the questions I come across most frequently in my practice. Die Antworten fallen dabei kürzer aus, als viele erwarten.
Isn’t it enough if the page works when you use the mouse?
No. Because blind people and many people with motor impairments do not use a mouse at all. Anything that can only be done using a mouse is simply not available to them.
Can I remove the focus border using CSS?
Only if you replace it. A outline: nonewith no visible alternative contravenes 2.4.7 ‘Focus visible’. A cleaner solution is :focus-visible with sufficient contrast.
Are positive `tabindex` values permitted?
They are permitted, but rarely used to good effect. This is because they disrupt the natural order of elements and almost always lead to confusion. It is better to rely on the order in the source code.
How do I use a website without a mouse?
With just a few keys: Tab moves to the next interactive element; Shift+Tab moves back. Enter opens links and activates buttons; the space bar activates buttons and tick boxes. Use the arrow keys to navigate through option groups, drop-down lists and menus; use Escape to close dialogue boxes and expanded menus.
Which WCAG criteria apply to keyboard navigation?
The most important ones are 2.1.1 Keyboard, 2.1.2 No keyboard trap, 2.1.4 Keyboard shortcuts, 2.4.3 Focus order and 2.4.7 Focus visible. With WCAG 2.2, 2.4.11 was added: The focus must not be completely obscured by other content, such as a fixed header or a cookie banner.
How to secure your keyboard navigation
The process begins with a quick overview and ends with reliable certainty. The free Access Score provides an initial assessment in a matter of minutes. It identifies measurable issues, such as missing focus styles or structural errors in the code.
However, the actual keyboard testing requires human input. With Access Ready, our testers navigate their way through your entire application using the Tab key, test every component and, upon completion, issue a legally compliant certificate. Whilst other providers leave you to your own devices with an automated report, we support you every step of the way, from analysis to certification.
| Approach | Checks keyboard operation | Real users | Evidence |
|---|---|---|---|
| Pure Scanner | only certain aspects of the code | no | no |
| Overlay-Widget | Covers up, does not fix | no | no |
| Access Ready (ifdb) | Fully manual operation | yes | yes |
The difference lies in our approach. Others check what is easy to measure and leave the rest to you. We check what really matters: whether a person can navigate your website from start to finish without using a mouse. This turns ‘should work’ into a proven ‘works for everyone’.
