Since June 2025, the European Accessibility Act has made WCAG AA a legal requirement for many websites in the EU. Keyboard navigation is one of the areas it covers, and it is also one of the few that anyone can check in a few steps, without special software. That makes it a practical place to start: the requirement is clear, the mistakes are recognizable, and the fixes are well defined.
The people who navigate without a mouse
Keyboard navigation is using a website without a mouse: moving between links, buttons and form fields, and activating them, only with the keyboard. Many people depend on it: people with motor impairments, people with a temporary injury, screen reader users, and people who simply prefer the keyboard.
The browser keeps one element "in focus" at a time, usually marked with an outline. The keyboard moves that focus from one interactive element to the next, following the order in the HTML (the code that structures the page), and acts on the focused element. A few keys cover almost everything:
- Tab / Shift+Tab: next / previous interactive element
- Enter: follow a link or press a button
- Space: press a button, check a checkbox
- Arrows: move inside menus, selects, radio groups and tabs
- Escape: close menus, dropdowns and modals
The following video shows an example of a website used only with the keyboard.
For the people who rely on the keyboard, a site that fails here is hard or impossible to use. For many sites, it is also a legal issue.
The legal requirement behind keyboard access
Since the European Accessibility Act came into force in June 2025, meeting WCAG AA has been a legal requirement for many sites. The EAA applies to specific services, such as e-commerce, banking, transport and e-books, and exempts microenterprises. It references the European standard EN 301 549, which maps to WCAG 2.1 AA.
WCAG covers keyboard use in several criteria. The main ones are:
- 2.1.1 Keyboard (A): everything works with the keyboard.
- 2.1.2 No Keyboard Trap (A): focus can always move away from any element.
- 2.4.1 Bypass Blocks (A): there is a way to skip repeated blocks like the header.
- 2.4.3 Focus Order (A): focus moves in a logical order.
- 2.4.7 Focus Visible (AA): the focused element is always visible.
- 2.4.11 Focus Not Obscured (AA): sticky headers, cookie banners or chat widgets never fully hide the focused element. This criterion was added in WCAG 2.2.
Other criteria also touch keyboard use, like dismissing content shown on focus or exposing the state of custom controls. The full list is in the WCAG quick reference linked below. In practice, these criteria fail through a set of recurring mistakes.
Common mistakes that block keyboard users
A common source of keyboard problems is something that works fine with a mouse but was never tested with the keyboard. The result is extra Tab presses, a lost focus, or an element that cannot be reached at all.
Header menu: submenus open as soon as the parent item receives focus, or stay hidden only visually but remain in the tab order. Every Tab walks through every child link, on every page, before reaching the main content.
Focus outline removed: a style rule like outline: none without a replacement leaves no way to know where focus is.
Modals: focus does not move into the modal when it opens, or it cannot leave it.
No skip link: without a "Skip to main content" link, every page starts with the whole header.
Fake buttons: a <div> or <span> with a click handler is not focusable and does not respond to Enter or Space.
Each of these mistakes has a specific fix in the site's code.
The technical fix behind each mistake
Each fix is a change in the site's HTML, CSS or JavaScript.
The header menu needs four changes:
- Submenus stay closed until opened with Enter, Space or the down arrow.
- A closed submenu is out of the tab order (
hiddenordisplay: none), so Tab jumps to the next top-level item. - The toggle is a
<button>witharia-expanded="true|false", an attribute that lets screen readers announce whether the submenu is open. - Escape closes the open submenu and returns focus to its toggle.
For the focus outline, the CSS selector :focus-visible styles the outline instead of removing it.
For modals, focus goes inside on open, stays inside while open, and returns to the trigger on close. Escape closes it.
The skip link is a "Skip to main content" link placed as the first focusable element on the page.
Fake buttons are replaced with the native <button> and <a> elements, which are focusable and respond to the keyboard by default.
Knowing which of these mistakes affect a site requires no special tools.
A manual keyboard check with the mouse out of reach
Keyboard navigation is one of the easiest accessibility checks to run. It needs no tools, only the mouse out of reach.
- Put the mouse away and press Tab from the address bar.
- The first stop should be the skip link.
- Focus should be visible on every stop.
- Tab through the header: closed submenus should be skipped. Open one with Enter, close it with Escape.
- Open a modal, close it with Escape, and check focus returns to the button that opened it.
- Fill in and submit a form.
Automated tools like Lighthouse catch only part of this. The manual check is the reliable one.
Conclusion
Keyboard navigation is a requirement, both for the people who depend on it and for WCAG compliance. A site that fails it excludes users and falls short of the legal standard.
This is the accessibility check worth running first. It needs no tools, and every problem it finds maps to one of the fixes above. The manual check shows where a site stands, and the fixes make the site quicker to use for everyone who relies on the keyboard, whatever the reason.
