To test your website's keyboard accessibility, put the mouse aside and navigate the page using only the keyboard: press Tab to move forward through links, buttons, and form fields, Shift+Tab to move back, Enter or Space to activate, and the arrow keys inside menus and sliders. As you go, confirm you can always see which element is focused, that the focus order follows the visual reading order, and that you never get stuck in a component you can't escape. This keyboard accessibility test takes about five minutes and surfaces the single most common category of real-world barrier for people who don't use a mouse.
Why does the keyboard test matter so much?
Millions of people never touch a mouse. Screen-reader users, people with motor disabilities, people with tremors or repetitive-strain injuries, and plenty of power users navigate entirely by keyboard. WebAIM's 2025 analysis of the top one million homepages found detectable WCAG failures on 94.8% of them, and the usual suspects are empty links and buttons, missing form labels, and low-contrast text — problems that show up immediately when you stop using a pointer.
This isn't an edge case for site owners, either. More than 5,000 digital-accessibility lawsuits were filed in 2025, and keyboard operability is one of the first things a plaintiff's expert checks. If a critical path — add to cart, book, contact, check out — can't be completed by keyboard, that's a Level A failure of WCAG 2.2.
How do I run a keyboard accessibility test in 5 minutes?
Load your homepage, click once in the browser's address bar to move focus out of the page, then follow these steps. Use a real page a customer would use — a product page or the checkout flow, not just the marketing splash.
- Press Tab and watch the screen. A visible focus indicator — an outline or ring — should jump to the first interactive element. If nothing visibly moves, that's your first failure.
- Keep tabbing through the whole page. Every link, button, form field, and menu should receive focus in an order that matches how the page reads top to bottom, left to right.
- Activate things. Press Enter on links and buttons, Space on buttons and checkboxes. Anything you can click with a mouse you should be able to trigger with the keyboard.
- Open the menus and modals. Trigger the mobile-style nav, a dropdown, a cookie banner, a newsletter popup. Confirm you can reach every option and, critically, get back out.
- Complete one real task. Fill and submit the contact form, or add an item to the cart, using only the keyboard.
Watch for the keyboard trap
The failure that breaks the most sites is the keyboard trap: focus enters a widget — a modal, a video player, an embedded map, a chat window — and Tab cycles inside it forever with no way out. A mouse user closes it with a click; a keyboard user is stuck. Every overlay and popup on your site needs an Escape key and a reachable close button.
Check the skip link
Tab once from the very top of the page. Many well-built sites reveal a hidden "Skip to main content" link so keyboard users don't have to tab through the entire header and menu on every page. It's optional to have one, but if it's there, make sure it actually works.
What are you actually looking for?
A page passes the basic keyboard accessibility test when four things are true. Judge your run against these:
- Visible focus. You can always see where you are. WCAG 2.2 tightened this with Focus Appearance (2.4.11) — a faint one-pixel outline that disappears against your background isn't enough.
- Logical order. Focus moves in a sensible sequence. It shouldn't jump from the header to the footer and back into the middle.
- Full operability. Everything clickable is also keyboard-operable, including custom dropdowns and "buttons" built from div or span tags, which are a frequent culprit.
- No traps. You can enter and leave every component, and Escape closes what it opens.
If any interactive control is skipped entirely when you tab, it's likely not a real button under the hood — a common outcome when a styled div is wired up with a click handler but no keyboard support. Forms are the other repeat offender; our guide to common accessible-form mistakes covers the label and error-handling problems that a keyboard pass often exposes. For a broader self-check across your whole site, work through our website accessibility checklist.
Do overlays or accessibility widgets fix keyboard problems?
No — and this is worth being precise about, because the two things people lump together are not the same.
A surface-layer compliance overlay is a third-party script sold on the promise that it will make a broken website accessible automatically. It won't. WebAIM found sites running overlays averaged roughly as many detectable errors as sites without them, and UsableNet's reports repeatedly find companies that had a widget installed when they were sued. In January 2025 the FTC ordered overlay vendor accessiBe to pay $1 million over deceptive claims that its product could make any site WCAG-compliant. An overlay does not rebuild the div that should have been a button, so your keyboard trap stays trapped. We break this down in why overlay widgets fail.
A user-facing preference widget is a different animal: a button that lets visitors adjust contrast or text size on a site that is already accessible at the code level, making no compliance claims. ADA Fail runs one on this very site. Attack the false compliance claim, never the honest preference button — and never expect either one to substitute for real keyboard operability in your code.
What can't the keyboard test tell you?
The five-minute test is high-value and low-effort, but it's a spot check, not a verdict. It won't reveal missing image alt text, insufficient color contrast, incorrect heading structure, or how your content actually sounds to a screen reader — for that, pair it with a screen-reader test.
It also can't certify conformance. Automated scanners detect only about a third of WCAG 2.2 success criteria, and even a clean manual keyboard pass is one slice of the standard. A site can sail through your Tab-key run and pass automated scans while still failing criteria that only expert human testing catches. That gap — between passing automated scans and genuine WCAG 2.2 AA conformance verified by a person — is exactly where lawsuits live. If your keyboard test turned up traps, invisible focus, or unreachable controls, a free accessibility audit from ADA Fail will map the full picture and show you what to fix first.
Frequently asked questions
What keys should I use for a keyboard accessibility test?
Tab moves focus forward through interactive elements; Shift+Tab moves it back. Enter activates links and buttons, Space toggles buttons and checkboxes, and the arrow keys operate radio groups, dropdowns, sliders, and menus once you're inside them. Escape should close any modal, popup, or menu — if it doesn't, you've likely found a keyboard trap.
Is keyboard access a legal requirement under the ADA?
There is no federal regulation that spells out a specific web standard for private businesses under ADA Title III, but courts and settlements treat WCAG as the de facto benchmark, and keyboard operability is a Level A requirement — the floor. A checkout or contact flow that can't be completed by keyboard is one of the clearest barriers a plaintiff's expert will cite, which is why it belongs at the top of any self-audit.
My site passed the keyboard test. Is it accessible?
Passing the keyboard test is a strong sign for one important dimension, but it doesn't mean the site conforms to WCAG 2.2 AA. Keyboard operability is one category among dozens; alt text, contrast, captions, form labels, and heading structure all need their own checks, and roughly two-thirds of WCAG criteria require human testing that no automated tool covers. Treat a clean keyboard run as encouraging, then verify the rest.
Ready to go past the five-minute check? A free ADA Fail accessibility audit tests your site against WCAG 2.2 AA — keyboard operability included — and hands you a prioritized, plain-English list of what to fix before a demand letter does it for you.