HIGHWCAG 2.1.1 A

Keyboard-Inaccessible Select

A styled select menu opens on click but cannot be opened or navigated with the keyboard.

Try It Yourself

Demo warning

The control looks interactive but ignores keyboard input entirely.

Try opening the dropdown with Enter or Space. Only mouse interaction succeeds.

Select a plan

Keyboard input does not open or move through this custom select.

Manual Testing Protocol

Follow this sequence to reproduce the failure consistently and verify the fix with the same workflow.

1. Setup

Place focus on the custom select trigger using Tab.
Avoid mouse input for the entire demo.

2. Reproduction Steps

Press Enter or Space to open the dropdown.
Attempt to navigate options with Arrow keys.
Try to select an option using Enter.

3. Expected Failure Signals

Dropdown does not open with keyboard input.
Options are not reachable via arrow keys.
User cannot make a selection without the mouse.

4. Fix Verification

Trigger supports Enter/Space to open.
Options are focusable and arrow-key navigable.
Selection is confirmed with Enter and announced properly.

Evidence Capture Checklist

Record the exact user goal that fails (for example: submit form, complete checkout, navigate menu).
Capture screen recording + keyboard path from first interaction to failure state.
Map failure to WCAG 2.1.1 (Level A) and affected user groups.
Document business impact: conversion loss, support burden, legal/compliance risk, or trust damage.

Share evidence with Accessibility.build

The Impact

What Happens

Keyboard users cannot complete selection tasks
Forms become unusable without mouse
Accessibility regressions slip into custom UI kits

Who Gets Hurt

Keyboard-only users

Motor-impaired users

Screen reader users relying on keyboard

The Broken Code

<div class="select" onclick="openMenu()">
  <span>Choose a plan</span>
  <ul hidden>
    <li>Starter</li>
    <li>Pro</li>
  </ul>
</div>
<!-- No button semantics, no keydown handlers -->