What goes wrong with keyboard-only operation
The most common mistake in keyboard-only navigation is that interactive elements are visible but not reachable with the Tab key. Think of a menu that only opens with a mouse click, a button that doesn't receive focus, or a pop-up that cannot be closed without a mouse. For people who cannot use a mouse due to motor disabilities, or who operate a screen reader that relies on keyboard navigation, this means that part of the website is simply unusable.
The cause almost always lies in custom-built elements: a developer builds an attractive dropdown, a custom date picker, or an expandable filter using their own HTML and JavaScript, but forgets to add the keyboard support that a standard HTML button or link provides for free. The element looks good and works with the mouse, so during testing no one notices that the Tab key simply skips over it.
Why this often gets overlooked
This error is persistent because it's not visible to the naked eye. Anyone who clicks through a webshop with a mouse won't see a problem anywhere. Only when you set the mouse aside and navigate through the page using only Tab, Shift+Tab, Enter, and the arrow keys does it become apparent where navigation breaks down. Because this kind of testing is rarely part of a standard handover process, the problem often goes unnoticed for years — until a visitor or a regulator encounters it.
A second reason is that these defects often occur precisely in the places that stand out most during use: the checkout process, the login screen, a search filter. These are exactly the components that are often built separately from the rest of the site, using custom components that don't always receive the same care as the main navigation.
How to spot this yourself
A simple first check is to put down the mouse and work through a page flow using only the keyboard. Watch for three things: is every clickable element reachable via Tab, is it clear at all times which element has focus, and can every element that opens — a menu, a filter, a pop-up — be closed again without the mouse. If focus gets stuck in a pop-up, jumps to an unexpected location, or disappears from view entirely, that's a signal that there's work to be done.
An automated scan can detect some of these problems, for example missing focus indicators or elements without keyboard access that are technically recognizable in the source code. However, whether a dropdown can actually be operated logically and predictably is something a scan cannot fully assess — that remains fundamentally a human evaluation. This applies to several WCAG requirements, which we always mention in the report. start the free quick-scan of your most important pages to see which part of these kinds of problems already comes to light automatically.
How to prevent this
The solution usually doesn't lie in adding extra technology to the website, but in correctly using existing building blocks. A standard HTML button or link is inherently reachable with Tab and operable with Enter; anyone who instead makes a piece of text or an image clickable with JavaScript must add that keyboard support themselves. For custom components such as menus, filters, and pop-ups, there should be a clear agreement with the developer: every element must be openable, operable, and closable with the keyboard, and focus must remain visible and predictable.
What won't help here is an accessibility widget that claims to fix these kinds of defects with a separate script. Such an overlay doesn't change the underlying code and therefore doesn't change the actual usability; the law requires an accessible website, not a layer on top of it. We deliberately do not sell such widgets.
Do you want to know which parts of your website or app contain these kinds of structural problems, and how much weight they carry in the priority list for your improvement plan? In the knowledge base organized by topic you can read for each type of defect what the issue is, and how our testing works in detail you can see which part of it is tested automatically and which part requires manual attention.
Do you have any questions about what is and isn't covered by this requirement, or about the rest of the testing framework? The answers to frequently asked questions already provide clarity on most of them.
The free quick-scan from axessia.eu gives you an immediate indication of whether this kind of keyboard navigation problems occur on your site, without needing an account.