Originally published on the AccessGuard blog.
After our post on accessible modals resonated with so many of you, we wanted to tackle another notoriously tricky pattern: the custom dropdown, or combobox. Native select elements are accessible out of the box, but the moment you need custom styling, searchable options, multi-select, or grouped items, you end up reimplementing a lot of browser behavior — and that is where accessibility usually breaks.
This post walks through the pieces you need to get right: semantics, keyboard support, focus management, and announcements. By the end you will have a mental checklist you can apply to any dropdown in your codebase.
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", aria-expanded reflecting open state, and aria-controls pointing to the listbox id. The popup itself uses role="listbox" and each option uses role="option" with aria-selected on the active option. If you only remember one thing: 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 button or an input 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" and not just "combobox, collapsed."
Step 3: Keyboard support is non-negotiable
This is where most custom dropdowns fail. At a minimum you need: Enter or Space to open the listbox, Arrow Down to open and move to the first or selected option, Arrow Up and Arrow Down to move between options, Home and End to jump to the first and last option, Escape to close and return focus to the trigger, Tab to close and move to the next focusable element, and typeahead so pressing a letter jumps to the next matching option.
Step 4: Manage focus, not just visual highlight
Here is the subtle part. In a listbox pattern, DOM focus stays on the combobox trigger. You do not move focus into the list. Instead, you track the active option with aria-activedescendant, pointing at the id of the currently highlighted option. This keeps typeahead and keyboard handlers on the trigger while still telling assistive tech 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. You get this for free if aria-expanded and aria-activedescendant are wired up correctly. Avoid adding extra aria-live regions that duplicate this — 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, update the trigger's visible text and its accessible name, close the listbox, and 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 select element whenever you can. It is accessible, it works on every platform, and mobile browsers give you a great picker for free. Only build a custom combobox when you genuinely need features native select cannot provide — searchable options, rich option content, or async loading. The best accessible component is often the one you did not 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.