Detailed explanation
An accessible custom dropdown must expose its purpose, value, and state to assistive technology while remaining fully usable without a mouse. First identify the interaction: a dropdown for choosing a value is usually a select or combobox, whereas a dropdown containing commands is a menu. Prefer a native <select> when its behaviour meets the requirement, because the browser supplies keyboard support, focus handling, and accessibility semantics. Custom styling alone is not a reason to rebuild it.
For an editable combobox with suggestions, put role="combobox" on the input, provide an accessible label, and use aria-expanded to report whether the popup is open. Connect it to a popup with aria-controls="list1"; give that popup role="listbox" and each selectable item role="option" with a unique ID. Use aria-autocomplete="list" when typing produces suggestions. Represent selection with aria-selected on options. The supplied example uses an older wrapper-based pattern: modern implementations generally place combobox semantics on the input and use aria-controls rather than aria-owns to connect the popup.
Implement keyboard behaviour deliberately. Arrow Down and Arrow Up navigate available options; Enter accepts the active option; Escape closes the popup without unexpectedly committing a new value. Tab should move onward through the page rather than trap the user or visit every option. Editable inputs must retain normal text-editing shortcuts. In the common combobox focus model, DOM focus remains on the input while aria-activedescendant references the active option. Update that reference during navigation, visually highlight the option, and scroll it into view. Active and selected are distinct states, even if your chosen interaction makes them coincide.
Keep ARIA, visual state, and application state synchronised: remove stale active-option references, hide a closed popup from interaction and the accessibility tree, and retain a visible focus indicator. Support pointer and touch selection without losing focus before selection completes. Test with keyboard-only navigation and a screen reader, including filtering and empty results. Interviewers look for a coherent interaction pattern and working behaviour, not simply a list of ARIA attributes.
Key points to remember
- Prefer native <select>; distinguish value selection from command menus.
- Give the combobox an accessible name, aria-expanded, and aria-controls pointing to its popup.
- Use listbox and option roles, unique option IDs, and aria-selected to expose selection.
- Implement arrow navigation, Enter, Escape, and normal Tab movement without breaking text editing.
- Keep focus, aria-activedescendant, visual highlighting, and popup visibility synchronised.
Common mistakes candidates make
- Adding ARIA roles without implementing keyboard interaction or focus management.
- Using menu roles for a value picker or copying an older combobox structure without understanding its focus model.
- Leaving aria-expanded or aria-activedescendant stale after closing, filtering, or removing options.
Likely follow-up questions
What is the difference between aria-activedescendant and moving focus?
aria-activedescendant identifies the active option to assistive technology while DOM focus stays on the combobox. Moving DOM focus instead changes document.activeElement; neither approach automatically implements keyboard navigation.
Should every dropdown use role="combobox"?
No: choose semantics based on the interaction, not the dropdown's appearance. A value picker may use a native select or combobox, while a popup of application commands may use the menu-button pattern.
How would you test a custom dropdown?
Use only the keyboard to open it, navigate options, select, dismiss, and Tab away, checking that focus remains predictable. With a screen reader, verify the label, expanded state, active option, and selection; also test filtered results and ensure closed options are not reachable.
Interview tip: Explain one complete combobox interaction from opening to selection and dismissal, showing how keyboard behaviour, focus, and ARIA state stay aligned.