Guide

Keyboard accessibility testing: how to test without a mouse

Last updated: 29 June 2026

Many people navigate the web entirely by keyboard — people with motor disabilities, screen-reader users, and plenty of power users. If your site only works with a mouse, it excludes them. The good news: keyboard testing needs no special tools, just your Tab key and a few minutes. This guide shows you what to check and the WCAG criteria behind each one.

The five-minute keyboard test

Put your mouse aside and use only these keys:

  • Tab / Shift+Tab — move forward/back between interactive elements.
  • Enter — activate links and buttons.
  • Space — activate buttons, toggle checkboxes, scroll.
  • Arrow keys — move within menus, radio groups, sliders, and custom widgets.
  • Esc — close menus and dialogs.

What to check

  • Can you reach everything? Every link, button, form field, and control should be focusable with Tab. Anything you can click with a mouse, you must be able to operate by keyboard (WCAG 2.1.1 Keyboard).
  • Can you always see where you are? The focused element needs a clearly visible focus indicator (an outline or ring). If focus is invisible, keyboard users are lost (WCAG 2.4.7 Focus Visible).
  • Is the order logical? Tab order should follow the visual reading order — left to right, top to bottom — not jump around (WCAG 2.4.3 Focus Order).
  • Are you ever trapped? You should be able to Tab into and back out of every component, including modals and embedded widgets. Getting stuck is a "keyboard trap" (WCAG 2.1.2).
  • Can you skip repetitive content? A "skip to main content" link near the top lets keyboard users bypass the nav (WCAG 2.4.1 Bypass Blocks).
  • Do custom widgets behave? Dropdowns, tabs, accordions, and sliders built with divs need keyboard handlers and ARIA so they work like native controls.

Common keyboard failures

  • Clickable <div>s used instead of real <button> / <a> — they aren't focusable or operable by default.
  • Focus styles removed in CSS (outline: none) with nothing put back.
  • Modals that don't trap focus while open, or don't return focus when closed.
  • Custom dropdowns that open on click but ignore the keyboard.
  • Focus order scrambled by CSS positioning or large positive tabindex values.

Where automated tools help (and where they don't)

An automated scan catches some keyboard-related issues — for example, interactive elements with no accessible name, or controls that aren't real focusable elements. But "is the focus order sensible?" and "can I actually complete this flow by keyboard?" are judgment calls only a human can make. So use automation to clear the obvious failures fast, then do the manual Tab-through. Scan your site free with WCAGwise to find the machine-detectable issues and where they are; then run the five-minute test above. WCAGwise is an audit aid, not a legal guarantee.

Related guides