Testing & Tools

Keyboard-Only Testing: A Practical Guide

Testing a page using only a keyboard — no mouse at all — is one of the fastest, cheapest, and highest-value manual accessibility checks available. It requires no special software, takes a few minutes per page, and directly surfaces real problems that automated scanning can only partially detect.

The basic method

Physically disconnect your mouse (or simply don't touch it), then navigate using only:

• Tab — move focus forward to the next interactive element
• Shift+Tab — move focus backward
• Enter — activate a link or submit a button
• Space — activate a button, toggle a checkbox
• Arrow keys — move within a component that expects them (a select dropdown, a radio group, a menu)
• Escape — close a modal, dropdown, or dismiss a tooltip

What to check as you go

Can you see where focus is at all times? If you lose track of where you are, that's a Focus Visible failure — the focus indicator is missing, too subtle, or hidden behind other content (Focus Not Obscured).

Can you reach every interactive element? Every button, link, form field, and custom widget on the page should be reachable via Tab. If something is skipped entirely, that's usually a Keyboard failure — often a <div> or <span> styled to look interactive with no real keyboard support wired up.

Does the tab order make sense? Focus should move in a logical sequence matching the visual/reading order of the page — see Focus Order. If it jumps around unpredictably, check for CSS-based visual reordering or manual tabindex values fighting the natural DOM order.

Can you operate every custom widget? Dropdowns, modals, custom sliders, tab panels — each has an expected keyboard interaction pattern (documented in the WAI-ARIA Authoring Practices Guide for common widget types). Test that arrow keys, Enter, and Escape all behave the way a keyboard user would reasonably expect for that type of control.

Can you get back out of everything? Open every modal, dropdown, and embedded widget and confirm you can close it and return focus to the rest of the page using only the keyboard — a Keyboard Trap is one of the most severe, complete-blocker failures a keyboard user can hit.

Why this test is worth doing even with automated scanning in place

A significant share of keyboard accessibility issues fall into WCAG's "partially automatable" or "manual only" categories (see Automated vs Manual Testing) — a scanner can flag suspicious patterns like a positive tabindex, but confirming genuinely correct keyboard operability, in practice, requires actually trying it. This five-minute manual pass catches real, high-severity issues that no automated tool available today can fully verify on its own.

Common questions

How do I test a website with only a keyboard?

Disconnect the mouse and navigate with Tab and Shift+Tab to move focus, Enter and Space to activate controls, arrow keys within components, and Escape to close them — checking you can reach and operate everything.

What does keyboard-only testing catch?

Missing or hidden focus indicators, elements you can't reach by Tab, illogical tab order, custom widgets you can't operate, and keyboard traps you can't escape — many of which automated tools only partially detect.

Why do keyboard testing if I already run an automated scan?

Much of keyboard accessibility is partially automatable or manual-only. A scanner can flag a suspicious tabindex, but confirming genuine keyboard operability requires actually trying it — a five-minute pass that catches high-severity issues.