How to Build Accessible Custom Dropdowns (Comboboxes) That Actually Work

Source: Dev.to

Originally published on the AccessGuard blog.

Step 1: Start with the right roles

A combobox is not just a styled button. The WAI‑ARIA Authoring Practices define a specific role structure:

• A combobox element (usually a button or input) with aria-haspopup="listbox" and aria-expanded reflecting the open state.
• aria-controls pointing to the listbox id.
• The popup itself uses role="listbox".
• Each option uses role="option" with aria-selected on the active option.

Tip: Roles must match behavior. Do not slap role="listbox" on a div that behaves like a menu.

Step 2: Make the trigger reachable and descriptive

• The trigger must be a real focusable element — either a native or an with tabindex="0".
• Give it an accessible name using a visible label, aria-label, or aria-labelledby.
• Announce the current value so screen‑reader users hear “Country, combobox, United States” instead of just “combobox, collapsed.”

Step 3: Keyboard support is non‑negotiable

At a minimum you need:

• Enter or Space – open the listbox.
• Arrow Down – open (if closed) and move to the first or selected option.
• Arrow Up / Arrow Down – move between options.
• Home / End – jump to the first and last option.
• Escape – close and return focus to the trigger.
• Tab – close and move to the next focusable element.
• Typeahead – pressing a letter jumps to the next matching option.

Step 4: Manage focus, not just visual highlight

In a listbox pattern, DOM focus stays on the combobox trigger.
Use aria-activedescendant on the trigger, pointing to the id of the currently highlighted option.
This keeps typeahead and keyboard handlers on the trigger while informing assistive technology which option is active.
Moving real focus into the list is a common mistake that breaks typeahead and confuses screen readers.

Step 5: Announce changes without being noisy

When the listbox opens, screen readers should announce the expanded state and the active option automatically if aria-expanded and aria-activedescendant are wired correctly.
Avoid extra aria-live regions that duplicate announcements—double announcements are worse than none.

Step 6: Do not forget the close behaviors

• Close the listbox on Escape, on outside click, and on blur of the combobox.
• When closing via Escape, restore focus to the trigger.
• When a user selects an option:
  1. Update the trigger’s visible text and its accessible name.
  2. Close the listbox.
  3. Return focus to the trigger.

A quick testing checklist

• Can you open, navigate, select, and close using only the keyboard?
• Does VoiceOver or NVDA announce the role, state, and active option?
• Does typeahead work?
• Does Escape always return focus to the trigger?
• Do touch users on mobile get a usable experience? (Hint: test with TalkBack and VoiceOver on iOS)

If you can answer yes to all of these, you are ahead of 90 % of the custom dropdowns on the web.

When to skip all of this

Honestly, use the native element whenever you can. It is accessible, works on every platform, and mobile browsers provide a great picker for free. Only build a custom combobox when you genuinely need features native cannot provide — searchable options, rich option content, or async loading. The best accessible component is often the one you didn’t have to build.

We will follow this up with a post on accessible autocompletes, which add another layer of complexity on top of this pattern. If there is a tricky component you would like us to cover next, let us know.

Read more from AccessGuard at getaccessguard.com.