Accessibility Quick Check

Fixing an Unreachable Search Field

A site's search popup opens with the keyboard — but focus never reaches the search field, so keyboard users can open the search and do nothing else. This review shows why it fails WCAG 2.1.1, and why it isn't the keyboard trap it looks like.

Read the full transcript ↓

What Is It?

A full-screen search popup opens by keyboard and places focus on its Close button. Pressing Tab or Shift+Tab never moves focus to the search field or the Search button — so the feature can be opened, but never used. It looks like a keyboard trap, but it isn't: Esc and the Close button both exit. The failure is that the search itself can't be operated (2.1.1), not that focus is trapped (2.1.2).

Why It Matters

Keyboard-only users — including many people with motor disabilities and screen reader users — can never type or submit a search. The feature is effectively mouse-only, leaving the fastest path to content unavailable to anyone who doesn't use a pointer.

How To Test

  1. Tab to the search icon in the header and press Enter.
  2. Observe that focus lands on the Close button.
  3. Press Tab — check whether focus reaches the search field.
  4. Press Shift+Tab — check whether focus moves at all.
  5. Confirm the search input and submit button can never receive keyboard focus.

The Fix

Give the popup role="dialog" with an accessible name, and move focus to the search input when it opens. Ensure Tab cycles through search input → submit → close, and that Esc closes the popup and returns focus to the search toggle that opened it. Replace the anchor-based close control with a native <button> so it activates on both Enter and Space. This satisfies WCAG 2.1.1.

WCAG Reference

Related Skills

  • Accessibility Testing
  • Keyboard Navigation
  • Screen Reader Support
  • Manual QA