{"id":992954,"date":"2026-06-26T06:49:54","date_gmt":"2026-06-26T06:49:54","guid":{"rendered":"https:\/\/ifdb.io\/accessible-keyboard-navigation-using-a-website-without-a-mouse\/"},"modified":"2026-10-12T11:32:42","modified_gmt":"2026-10-12T11:32:42","slug":"accessible-keyboard-navigation-using-a-website-without-a-mouse","status":"publish","type":"post","link":"https:\/\/ifdb.io\/en\/accessible-keyboard-navigation-using-a-website-without-a-mouse\/","title":{"rendered":"Accessible keyboard navigation: using a website without a mouse"},"content":{"rendered":"\n

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 \u2013 including blind people and many with motor impairments. In this guide, I\u2019ll 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\u2019ll reveal the test that anyone can carry out themselves in five minutes. <\/p>\n\n

What is keyboard navigation?<\/h2>\n\n

Keyboard navigation means operating a website entirely using the keyboard \u2013 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. <\/p>\n\n

There is a clear criterion behind this requirement. Success criterion 2.1.1 \u2018Keyboard\u2019 (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. <\/p>\n\n

What\u2019s 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\u2019t 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. <\/p>\n\n

Anyone who relies on a keyboard<\/h2>\n\n

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\u2019t work with the keyboard, it won\u2019t work with the screen reader either. <\/p>\n\n

Added to this are motor impairments. People with Parkinson\u2019s disease, spasticity or tendonitis are often unable to move a mouse with precision. Instead, they use the keyboard, special switches or voice control \u2013 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. <\/p>\n\n

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<\/a>. <\/p>\n\n

The five rules of accessible keyboard use<\/h2>\n\n

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. <\/p>\n\n

Criteria<\/th>Level<\/th>What it\u2019s all about<\/th><\/tr><\/thead>
2.1.1 Keyboard<\/td>A<\/td>Every function can be operated via the keyboard<\/td><\/tr>
2.1.2 No keyboard trap<\/td>A<\/td>Emerging from each element again<\/td><\/tr>
2.4.3 Focus order<\/td>A<\/td>A logical, sensible tab order<\/td><\/tr>
2.4.7 Focus visible<\/td>AA<\/td>Visible focus indicator<\/td><\/tr>
2.4.11 Focus not obscured (minimum)<\/td>AA<\/td>Focus not hidden behind content<\/td><\/tr><\/tbody><\/table><\/figure>\n\n

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<\/a>. Taken together, these five rules ensure that a page can be navigated entirely without a mouse. <\/p>\n\n

Accessible and usable: native versus custom elements<\/h2>\n\n

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><\/code> element with a click handler, on the other hand, is not. <\/p>\n\n

This \u2018div soup\u2019 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\u2019t included in the tab order and doesn\u2019t respond to the Enter key or the space bar. If you still want to use it, you\u2019ll need to add tabindex=\"0\"<\/code>, a suitable role and your own keyboard handlers. <\/p>\n\n

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<\/a> will help. The rule of thumb remains: look for native elements first; only use your own if there is no alternative. <\/p>\n\n

Avoiding the keyboard trap<\/h2>\n\n

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 \u2018No keyboard traps\u2019 (Level A) expressly prohibits this. <\/p>\n\n

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. <\/p>\n\n

It is worth making an important distinction here. A modal dialogue box is indeed intended to retain focus \u2013 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. <\/p>\n\n

The correct order of focus<\/h2>\n\n

The order in which elements receive focus determines their orientation. Success criterion 2.4.3, \u2018Focus Order\u2019 (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. <\/p>\n\n

This order is disrupted in a typical way. A positive tabindex<\/code> 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. <\/p>\n\n

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<\/a>. <\/p>\n\n

The visible focus: the overlooked detail<\/h2>\n\n

No detail is overlooked more often than the visible focus indicator. Success criterion 2.4.7, \u2018Focus visible\u2019 (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. <\/p>\n\n

A classic mistake is a single line of CSS. Using outline: none<\/code>, developers remove the focus border because they don\u2019t like the way it looks \u2013 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<\/code> 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. <\/p>\n\n

WCAG 2.2 has further tightened the requirements in this area. The new criterion 2.4.11 \u2018Focus Not Hidden\u2019 (Minimum, Level AA) requires that the focused element must not be completely obscured by other content \u2013 such as sticky headers, cookie banners or chat windows. At the highest level, Criterion 2.4.13 \u2018Focus Appearance\u2019 (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<\/a>. <\/p>\n\n

Controlling focus precisely: dialogues and dynamic content<\/h2>\n\n

As soon as content changes dynamically, the focus must be actively managed. When a dialogue box opens, the focus should be placed within it \u2013 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. <\/p>\n\n

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). <\/p>\n\n

It is helpful to understand the `tabindex` values. A value of `0<\/code>` places an element in the natural order. A value of `-1<\/code>` 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. <\/p>\n\n