Keyboard Testing — Manual and Automated Keyboard Accessibility Testing

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

Keyboard Accessibility Testingity" >}} testing combines manual Tab navigation through all interactive elements with automated tools that check for focusable elements, visible focus, and keyboard handlers.

In this tutorial, you'll learn Keyboard Navigation testing.

What You'll Learn

By the end of this lesson, you'll have a systematic keyboard testing workflow, automated test techniques, and a comprehensive checklist.

Why It Matters

Keyboard issues are easy to miss during visual development. Systematic testing catches focus traps, missing focus indicators, and broken keyboard interactions.

Real-World Use

DodaTech runs keyboard tests as part of every Pull Request using both manual checklists and automated axe-core rules.

Testing Workflow

flowchart TD
  A[Load page] --> B[Press Tab]
  B --> C{Skip link visible?}
  C -->|Yes| D[Activate skip link]
  C -->|No| E[Tab through navigation]
  E --> F[Tab through all interactives]
  F --> G{Any keyboard trap?}
  G -->|Yes| H[Fix and retest]
  G -->|No| I[Test Enter/Space]
  I --> J[Test arrow keys]
  J --> K[Test Escape]
  K --> L[Test with screen reader]

Manual Testing Checklist

### Keyboard Testing Checklist
- [ ] Skip link is first focusable element
- [ ] Skip link is visible on focus
- [ ] Tab order follows visual layout
- [ ] All interactive elements are focusable
- [ ] All links and buttons are operable with Enter
- [ ] All buttons are operable with Space
- [ ] Custom widgets respond to arrow keys
- [ ] Modals trap focus
- [ ] No keyboard traps exist
- [ ] Focus indicator is visible on all elements
- [ ] Focus indicator meets WCAG 2.2 requirements
- [ ] Dropdowns and menus close with Escape

Automated Testing

// Cypress keyboard test example
describe('Keyboard Navigation', () => {
  it('Should tab through all focusable elements', () => {
    cy.get('body').tab();
    cy.focused().should('have.class', 'skip-link');
    cy.tab().tab().tab();
    cy.focused().should('have.id', 'search-input');
  });

  it('Should have visible focus indicators', () => {
    cy.get('button').focus();
    cy.get('button').should('have.css', 'outline-width').and('not', '0px');
  });
});

// Axe-core keyboard check
axe.run({
  runOnly: ['color-contrast', 'focus-order-semantics']
});

Testing Different Widgets

Each widget type needs specific keyboard tests:

Common Mistakes

• Testing only in one browser: Keyboard behavior varies across browsers.
• Not testing with a screen reader: Some keyboard issues only manifest with screen readers.
• Not testing dynamic content: Keyboard interaction with dynamic content often breaks.
• Only testing happy path: Test what happens when Tab is pressed on the last element.
• Not documenting the expected tab order: Write down the expected sequence for verification.

Practice and Challenge

1. What is the first element to test on page load? The skip link.

2. What three keys should every button support? Tab (to focus), Enter and Space (to activate).

3. What should happen when Escape is pressed on a modal? The modal closes.

4. What should you test for custom widgets beyond basic Tab? Arrow keys, Home, End, and Escape.

5. Challenge: Run the full keyboard testing checklist on your website. Document all issues found.

FAQ

Mini Project

Create a keyboard testing protocol for your team. Include a checklist, test script, and automated test examples. Run the protocol on your website.

What's Next

Continue to Keyboard Project to build an accessible custom select menu.