Skip to main content
Technique

Keyboard Navigation Testing Guide

A step-by-step guide to testing web page keyboard accessibility — covering focus order, focus visibility, interactive element operability, and keyboard traps.

Why Keyboard Testing Is Non-Negotiable

Keyboard accessibility is the foundation of all accessibility. Screen readers, switch-access devices, eye-tracking systems, and voice control software all operate through the keyboard API. A page that works with a keyboard works with all of these technologies. A page that requires mouse interaction breaks all of them.

WCAG 2.1.1 (Keyboard) requires that all functionality is operable through a keyboard interface. WCAG 2.1.2 (No Keyboard Trap) requires that users can navigate away from any component using only the keyboard. These are Level A criteria — the most critical level — meaning they apply to every page of every website.

Setting Up for Keyboard Testing

Before you begin, configure your testing environment:

  • Disconnect or ignore your mouse/trackpad — true keyboard testing means not touching pointing devices.
  • On macOS, enable keyboard access for all controls: System Settings → Keyboard → Keyboard Navigation (toggle on). Without this, Tab does not reach buttons or links in Safari.
  • Use multiple browsers — keyboard behavior varies. Test in Chrome, Firefox, and Safari minimum.
  • Use your browser's devtools to inspect focus state and element properties during testing.
  • Keep a spreadsheet open to log issues: page URL, element description, issue type, WCAG criterion.

Core Keyboard Interactions to Test

These are the standard keyboard interactions that all interactive elements must support:

  • Tab — moves focus forward to the next focusable element.
  • Shift + Tab — moves focus backward to the previous focusable element.
  • Enter — activates links and buttons.
  • Space — activates buttons and checkboxes; scrolls the page when no element is focused.
  • Arrow keys — navigate within composite widgets: select options, radio button groups, tabs, sliders, menus, date pickers.
  • Escape — closes dialogs, menus, tooltips, and popups.
  • Home / End — move to first/last item in a list or widget.

Step-by-Step Keyboard Test Procedure

  1. Load the page and press Tab to move focus to the first focusable element. Verify a skip link appears (WCAG 2.4.1).
  2. Tab through the entire page. Verify every interactive element receives focus — buttons, links, form controls, custom widgets.
  3. At each focused element, verify the focus indicator is visible and has sufficient contrast (WCAG 2.4.7, 2.4.11).
  4. Verify focus order is logical and follows the visual reading order (WCAG 2.4.3). Note any jumps or skips.
  5. Activate every link (Enter) and verify it navigates to the correct destination.
  6. Activate every button (Enter, Space) and verify it triggers the expected action.
  7. For every form control, verify you can enter or select values using keyboard alone.
  8. For dropdowns, comboboxes, and custom selects, verify arrow key navigation works within the component.
  9. For modal dialogs: when opened, verify focus moves inside the dialog; verify Tab stays trapped within the dialog; verify Escape closes it and returns focus to the trigger.
  10. For navigation menus with sub-menus, verify arrow keys navigate between items and Escape collapses sub-menus.
  11. Scroll through the page with keyboard (arrow keys, Page Down, Space) and verify no focus loss occurs.

Identifying Keyboard Traps

A keyboard trap (WCAG 2.1.2 failure) occurs when focus enters a component and cannot leave using standard keyboard controls. Common sources of keyboard traps:

  • Embedded iframes without keyboard exit handling.
  • Custom date pickers that capture all key events.
  • Map widgets (Google Maps embeds) that intercept arrow keys without providing an exit mechanism.
  • Third-party chat widgets that steal focus without an Escape handler.

To verify: navigate to the suspected trapping element with Tab. Try to Tab or Shift+Tab out of it. If focus is stuck, document it as a critical keyboard trap failure.

Common Keyboard Accessibility Failures

  • Focus indicator removed with outline: none or outline: 0 in CSS without a replacement.
  • Custom buttons implemented as <div> or <span> without role="button" and tabindex="0".
  • Links that only work on click due to JavaScript onclick handlers without keyboard fallbacks.
  • Dropdown menus that open on hover with no keyboard trigger.
  • Modals that do not trap focus or do not return focus to the trigger on close.
  • Focus order that does not match visual order due to CSS flexbox/grid reordering.
  • Interactive content inside SVGs that is not keyboard-reachable.

Documenting and Reporting Issues

For each keyboard accessibility issue found, document: the page and URL, the element and its role, the key(s) that fail, the expected behavior, the actual behavior, the WCAG criterion violated (typically 2.1.1, 2.1.2, 2.4.3, or 2.4.7), and the severity (critical/serious/moderate/minor using Deque's severity scale).

Issue: Keyboard trap in date picker
URL: /checkout/step-2
Element: Date of birth date picker, id="dob-picker"
Keys tested: Tab, Shift+Tab, Escape
Expected: Tab/Shift+Tab exits the date picker; Escape closes it
Actual: Tab is captured by the date picker; no exit possible
WCAG: 2.1.2 No Keyboard Trap (Level A)
Severity: Critical

Resources