Keyboard Accessibility: The Part Scanners Cannot Check
No scanner can tell you whether your site can be operated without a mouse. You can find out in ten minutes.
The part the tools cannot reach
Automated scanners detect somewhere around 30 to 40 percent of what WCAG asks for. A large slice of the remainder is keyboard operability, and it is the slice where the most severe real-world failures live. A missing alt attribute degrades an experience. A keyboard trap ends it.
The good news is that you do not need software or expertise to find the worst of it. You need a keyboard and about ten minutes. This is the single highest-value manual check there is, and almost nobody does it.
The ten-minute check
Put the mouse down. Physically move it out of reach if that helps — the temptation to grab it is strong and it invalidates the test. Then work through your most important page, which is usually whatever leads to money: a checkout, a booking flow, a contact form.
- Press Tab once from the top.Did a “skip to content” link appear? If nothing visible happened at all, you have already failed two criteria — 2.4.1 Bypass Blocks and 2.4.7 Focus Visible.
- Keep tabbing and watch where focus goes. You should always be able to see it, and the order should follow the visual layout. If focus jumps from the header to the footer and back, look for positive
tabindexvalues. - Check focus is never hidden. Tab slowly down a long page. Sticky headers, cookie banners and floating chat widgets routinely cover the focused element — that is 2.4.11 Focus Not Obscured, new in WCAG 2.2, and it is very common.
- Open every menu and dropdown. Can you open it with Enter or Space? Move through options with the arrow keys? Select with Enter? Close with Escape? Custom dropdowns built from divs usually fail all four, and if a required field is one of them, nobody can submit your form without a mouse.
- Open a modal, then try to leave. Focus should move into it, stay inside while it is open, close on Escape, and return to the thing that opened it. Tabbing out of an open modal into the page behind is the most common version of this bug.
- Complete the form. Every field, every dropdown, every checkbox, the submit button. If you cannot finish it, neither can a real customer.
- Trigger an error deliberately. Submit it empty. Does focus move to the problem or at least get announced? Is the message text, or just a red border?
- Try the carousel, the tabs, the accordion, the date picker. These four components account for a startling share of all keyboard failures on the web.
- Play a video. Can you reach play, pause and volume, and get back out of the player afterwards?
- Zoom to 200% and repeat the first three steps. Reflow problems and hidden focus often only appear here.
What you will probably find
In rough order of how often these turn up on a site that has never been checked:
| What you see | Criterion | The fix |
|---|---|---|
| No visible focus anywhere | 2.4.7 (AA) | Stop removing the outline. Style :focus-visible instead. |
| Custom dropdown cannot be opened | 2.1.1 (A), 4.1.2 (A) | Give it role="combobox", tabindex="0", arrow-key handling and aria-expanded. Or use a native <select>. |
| Clickable div does nothing on Enter | 2.1.1 (A) | Use a <button>. If you cannot, add tabindex="0", role="button" and a keydown handler for Enter and Space. |
| Modal leaks focus to the page behind | 2.4.3 (A) | Trap focus while open, close on Escape, restore focus to the trigger. |
| Focus hidden under a sticky header | 2.4.11 (AA) | scroll-margin-top on focusable elements, sized to the header. |
| Tab order jumps around | 2.4.3 (A) | Remove positive tabindex values. Fix the DOM order instead. |
| Menu only opens on hover | 2.1.1 (A) | Make it open on focus and on click too. |
| Cannot escape an embedded widget | 2.1.2 (A) | Usually a third-party script. Report it, or replace it. |
Almost all of it comes from one habit
Nearly every failure above traces to the same decision: building an interactive control out of a <div> because it was easier to style than the native element.
A native <button> is focusable, activates on Enter and Space, announces itself as a button, and participates in forms — for free, in every browser, forever. A <div onclick> has none of that, and you have to rebuild all of it by hand, correctly, and keep it working. Most teams rebuild the click handler and stop there, which is precisely how you end up with a page that works perfectly for everyone holding a mouse.
So the shortest possible advice: use the real element. <button>, <a href>, <select>, <input>, <details>, <dialog>. Style those. Every hour spent recreating a native control in ARIA is an hour spent reintroducing bugs the browser had already fixed.
Then what
Once the keyboard pass is clean, run the automated scan for the markup-level failures a person cannot easily eyeball — missing alt attributes across hundreds of images, contrast ratios, missing labels, heading structure. The two are complementary, and neither is sufficient.
Run the free scan, or read WCAG 2.2 AA in plain English for the full set of requirements without the specification language.
Frequently asked questions
Why can no automated tool test keyboard accessibility?
Because the question is not "does this element have a tabindex" but "can a person get to this thing, use it, and get back out again". That requires actually moving focus through a live page and judging whether the result is usable — including whether the focus indicator is visible against whatever is behind it, and whether a modal returns focus sensibly when it closes. A scanner reads markup. It can flag suspicious patterns like positive tabindex values, and that is genuinely useful, but it cannot tell you whether your dropdown works.
How many people actually navigate by keyboard?
More than the obvious estimate. It includes screen reader users, people with motor impairments or tremor, people with repetitive strain injuries, people using switch devices or voice control, and a large population of power users who simply prefer it. It also includes anyone whose trackpad has just died. Keyboard operability is the substrate that most other assistive technology sits on top of, so breaking it breaks several things at once.
Is it acceptable to remove the focus outline?
Only if you replace it with something at least as visible. Removing it and putting nothing back fails WCAG 2.4.7 Focus Visible at Level AA, and it is probably the single most damaging line of CSS in common use. If the default outline clashes with your design, style it — a 3px solid ring in a brand color with a 2px offset looks deliberate and passes. Use :focus-visible so it appears for keyboard users without ringing every mouse click.
What is a keyboard trap?
Any component you can tab into but not out of. Modals that do not release focus, embedded players that capture the tab key, and custom editors are the usual offenders. It fails WCAG 2.1.2 at Level A, and it is one of the worst failures there is: the user cannot continue and cannot go back, so their only option is to close the tab and leave.
Keep reading
- ADA Website Compliance, Explained Without the Legalese — There is no federal web rulebook, yet thousands of suits get filed every year. Here is what is actually being enforced, and against whom.
- WCAG 2.2 Level AA in Plain English — The spec is written for standards bodies. This is the same requirements written for whoever has to go and change the site.
- Why Accessibility Overlay Widgets Do Not Work — One line of JavaScript, compliance solved. Except the lawsuit numbers went up, and the FTC fined the biggest vendor $1M.
Nothing here is legal advice. Accessibility obligations vary by jurisdiction and by how a site is used. If you have received a demand letter, talk to a lawyer.