Test Your Site for Keyboard Accessibility in 10 Minutes

Most accessibility testing needs special software or a developer. This one doesn’t. With nothing but the Tab key and about ten minutes, you can reproduce roughly how a keyboard-only visitor — someone with a motor disability, a screen-reader user, a person with a temporary injury — actually moves through your site. It is the single most useful self-test a non-technical business owner can run, and it surfaces some of the exact problems that show up in ADA demand letters.

The catch: finding problems is not the same as fixing them. You’ll need a developer for the repairs. But you can’t fix what you can’t see, and a quick keyboard pass shows you a lot. Here’s how to do it.

Why the keyboard test matters

Keyboard operability isn’t optional under the Web Content Accessibility Guidelines. WCAG Success Criterion 2.1.1 (Keyboard) requires that “all functionality of the content is operable through a keyboard interface” — every link, button, menu, and form field. If a visitor can’t reach or activate something without a mouse, that’s a failure, and it’s a Level A failure, the most basic tier.

This affects more people than most owners assume. Anyone who navigates with a keyboard relies on it, and as WebAIM explains, “a keyboard user typically uses the Tab key to navigate through interactive elements.” Sighted keyboard users in particular need to see where they are — which is why a visible focus indicator is its own requirement. (WebAIM keyboard accessibility)

Step 1 — Park your mouse and press Tab

Open your homepage. Now move your hand off the mouse entirely. Press Tab once.

Something on the page should light up — usually a logo, a skip link, or the first navigation item — with a visible outline, box, or highlight around it. That highlight is the focus indicator, and it’s how a keyboard user knows where they are.

Keep pressing Tab. Focus should jump from one interactive element to the next: links, buttons, and form fields. Use Shift+Tab to move backward. To “click” the focused item, press Enter (for links and buttons) or Space (for buttons, checkboxes, and to expand menus), and Esc to close a dialog or menu — the standard keys WebAIM documents.

Step 2 — Can you always see where you are? (Focus Visible)

As you Tab through, ask one question at every stop: Can I see what’s focused?

If the highlight disappears on some elements — you press Tab and nothing visibly changes — that’s a WCAG 2.4.7 Focus Visible failure. This Level AA criterion requires that “any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.” A common culprit is a stylesheet that removed the browser’s default outline (outline: none) without replacing it.

Watch for a weak indicator, too. A faint gray line on a white button is technically present but practically invisible. The newer WCAG 2.4.13 Focus Appearance criterion sets concrete targets — an indicator at least as large as a “2 CSS pixel thick perimeter” of the element, with “a contrast ratio of at least 3:1 between the focused and unfocused states.” You don’t need to measure that by hand; just flag anything you struggle to spot and note it for your developer.

Step 3 — Does the order make sense? (Focus Order)

Now pay attention to the path your focus takes. It should follow the visual layout in a logical sequence — generally top to bottom, left to right. WebAIM’s guidance is to make the order “logical and intuitive,” matching the page’s visual flow.

Red flags: focus jumps from the header straight to the footer and back up; it skips your main menu entirely; or it lands on things in a scrambled sequence that wouldn’t make sense if you couldn’t see the screen. That’s a WCAG 2.4.3 Focus Order problem, often caused by a developer hard-coding positive tabindex values — something WebAIM explicitly warns against: “do not use tabindex values of 1 or greater to change the default keyboard navigation order.”

Step 4 — Can you always get back out? (No Keyboard Trap)

Keep tabbing through the whole page — through any embedded video, ad, chat widget, map, or pop-up. At each one, confirm you can Tab back out the other side.

If you ever Tab into something and can’t escape — no Tab, no Shift+Tab, and no Esc frees you — you’ve found a keyboard trap. WCAG 2.1.2 No Keyboard Trap prohibits this: if focus can move to a component with the keyboard, it must be able to move away with the keyboard. Traps most often appear in third-party embeds and custom modals. For a keyboard-only user, a trap doesn’t just degrade the experience — it can make the rest of your site completely unreachable.

Reload the page and press Tab just once. Many well-built sites reveal a hidden “Skip to main content” link as the very first stop. As WebAIM notes, the accessible pattern is to hide the link off-screen and “cause it to be positioned on screen when it receives keyboard focus.” Press Enter on it; focus should jump past your navigation to the main content. No skip link is a missed best practice; a broken one that goes nowhere is worse.

Finally, trigger any pop-up or modal (a newsletter sign-up, a cookie banner) and try to operate and close it with the keyboard alone. If you can’t reach the “X,” or focus leaks behind the overlay onto the page beneath, note it.

What to do with what you found

Write down each problem — the page, the element, and which of the four checks it failed. That short list is genuinely valuable: it’s the difference between telling a developer “make my site accessible” and “the cookie banner traps the keyboard and the buttons have no visible focus.”

A few honest caveats. First, this is not legal advice, and a passing keyboard test does not make you ADA compliant — consult a qualified attorney about your specific risk, and see how self-testing fits into avoiding a lawsuit. Second, the keyboard is just one input. It won’t catch low-contrast text — still the most common issue on the web, found on the large majority of home pages in WebAIM’s annual Million report — nor whether a screen reader announces your content correctly. That’s why a complete accessibility audit pairs keyboard testing with screen-reader testing and code review.

Third, if you’re tempted to skip all this and install a one-line widget instead: don’t. An accessibility overlay won’t pass the test you just ran, because it doesn’t repair the underlying HTML. At Curbcut we do manual remediation — fixing the real markup, focus management, and ARIA so the keyboard test passes for real, which is the only thing that holds up for users and in court. It’s the same reason keyboard access is a cornerstone of genuine ADA website compliance.

Want a fast machine-readable baseline to go with your manual pass? Start with a free scan.

Frequently asked questions

Do I need to be a developer to test my site with a keyboard?

No. This is the one accessibility check anyone can run without writing code. You only need the Tab, Shift+Tab, Enter, Space, and Esc keys and about ten minutes. You won't be able to fix what you find without a developer, but you can absolutely find it — and knowing where the problems are is the first step toward manual remediation.

What WCAG rules does the keyboard test check?

Mainly four Level A and AA success criteria: 2.1.1 Keyboard (everything must be operable without a mouse), 2.1.2 No Keyboard Trap, 2.4.3 Focus Order, and 2.4.7 Focus Visible. These are part of the WCAG 2.1 AA standard most U.S. courts and the DOJ point to.

If I pass the keyboard test, is my site ADA compliant?

No. The keyboard test covers a meaningful slice of accessibility, but it can't tell you whether your alt text is accurate, whether a screen reader announces your form errors, or whether your color contrast passes. A real audit combines keyboard testing with screen-reader testing and code review. This is a smoke test, not a clean bill of health.

My site uses an accessibility overlay — do I still need to test the keyboard?

Yes, and you'll often find the overlay didn't fix the underlying problems. Overlays bolt a widget onto broken HTML rather than repairing it, which is why businesses running them still get sued. See the evidence on whether overlays actually work.

What does a 'keyboard trap' look like?

You Tab into an element — often a video player, ad, modal, or embedded widget — and then no combination of Tab, Shift+Tab, or Esc gets you back out. A keyboard-only user is stuck and can't reach the rest of the page. WCAG 2.1.2 prohibits this outright.