Keyboard Accessibility Testing — Complete Guide

In this tutorial, you will learn about Keyboard Accessibility Testingity" >}} Testing. We cover key concepts, practical examples, and best practices to help you master this topic.

Keyboard accessibility testing verifies that every interactive element can be reached and operated using only the Tab, Enter, Escape, and arrow keys, with visible focus indicators and no keyboard traps at any point in the interaction.

What You'll Learn

You will perform systematic keyboard tests, identify focus order issues, detect keyboard traps, verify custom key handlers, and document keyboard accessibility violations.

Why It Matters

Many users rely entirely on keyboard navigation -- users with motor disabilities, power users who prefer keyboard shortcuts, and screen reader users who navigate by keyboard. If your site fails keyboard testing, it is inaccessible to these users.

Real-World Use

A banking app adds a new loan calculator widget. Keyboard testing reveals that the slider input traps focus -- once tabbed in, the user cannot tab out. The widget also has a hidden close button that is reachable by keyboard but invisible to sighted users.

Keyboard Testing Flow

flowchart TD
  A[Start Page Load] --> B[Tab Through Elements]
  B --> C{Focus Visible?}
  C -->|No| D[Fail: Missing Focus Indicator]
  C -->|Yes| E{Tab Traps?}
  E -->|Yes| F[Fail: Keyboard Trap]
  E -->|No| G{Order Correct?}
  G -->|No| H[Fail: Wrong Focus Order]
  G -->|Yes| I[Test Interactive Elements]
  I --> J[Enter, Space, Arrow Keys]
  J --> K[Test Escape for Dismissal]
  K --> L[Continue Until End]

Performing Keyboard Tests

Start at the top of the page and press Tab repeatedly. Each press should move focus to the next interactive element in a logical order.

<!-- Keyboard test: tab order -->
<nav>
  <a href="/">Home</a>          <!-- Tab stop 1 -->
  <a href="/products">Products</a>  <!-- Tab stop 2 -->
  <a href="/contact">Contact</a>    <!-- Tab stop 3 -->
</nav>
<main>
  <button>Search</button>       <!-- Tab stop 4 -->
  <button>Filter</button>       <!-- Tab stop 5 -->
</main>

/* Required: visible focus indicator */
*:focus-visible {
  outline: 3px solid #4A90D9;
  outline-offset: 2px;
  border-radius: 2px;
}

/* Bad: removing focus outline */
*:focus {
  outline: none; /* Never do this without replacement */
}

// Testing custom keyboard handlers
document.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') {
    closeModal();
    // Ensure focus returns to trigger element
    document.querySelector('[data-modal-trigger]').focus();
  }
});

Common Mistakes

• Using tabindex values greater than 0 (positive values)
• Removing focus outlines without providing alternatives
• Creating keyboard traps in custom widgets
• Forgetting to test dropdown menus and autocomplete fields
• Not testing with both Tab and Shift+Tab
• Assuming mouse-only interactions are keyboard accessible
• Overlooking skip-link functionality

Practice and Challenge

Practice 1: Tab through a complex page and note the focus order. Practice 2: Identify any elements that are not keyboard reachable. Practice 3: Test a dropdown menu with arrow keys. Practice 4: Check that modals trap focus within themselves. Practice 5: Verify that pressing Escape closes overlays.

Challenge: Create a keyboard testing script for a dashboard with 10 interactive widgets. Define expected focus order, keyboard interactions for each widget, and escape behavior for modals and dropdowns. Execute the script and document failures.

FAQ

Mini Project

Build a keyboard testing harness that logs every focus event during a Tab sequence. Use it to test a multi-page form. Identify at least three focus order issues and document the expected vs actual order with selectors.

What's Next

Screen Reader Testing covers testing with NVDA, VoiceOver, and JAWS screen readers.