Custom Combobox Accessibility Pitfalls

Building custom comboboxes allows front-end developers to create visually distinct and highly interactive select components, but standard HTML <select> elements handle a complex layer of built-in accessibility that custom implementations often break. This article explores the most common accessibility mistakes made when building custom comboboxes, focusing on role misconfigurations, keyboard navigation failures, broken focus management, and missing assistive feedback mechanisms.

Missing or Incorrect ARIA Attributes

A custom combobox typically consists of an input field coupled with a popup listbox. Assistive technologies rely entirely on WAI-ARIA attributes to understand this relationship. Common mistakes include:

  • Omitting aria-expanded: Screen reader users must know whether the listbox is open or closed. Failing to dynamically toggle aria-expanded="true" and aria-expanded="false" leaves users blind to the component's state.
  • Missing or Broken aria-controls: The input must reference the unique id of the popup listbox using aria-controls. Without it, assistive technologies cannot map the relationship between the trigger and the options.
  • Using Outdated ARIA Combobox Patterns: ARIA 1.0, 1.1, and 1.2 define comboboxes differently. Modern implementations should follow the ARIA 1.2 pattern, where the role="combobox" is placed directly on the <input> element rather than a wrapping container.

Broken Focus Management

Comboboxes generally manage focus in one of two ways: physically moving DOM focus or using virtual focus. Mixing these up or executing them poorly is a frequent failure point.

  • Failing to use aria-activedescendant: In an editable combobox, DOM focus must stay inside the <input> so the user can continue typing. To indicate the currently highlighted option in the dropdown, the input must update aria-activedescendant with the id of that active option.
  • Losing Focus on Selection: When an option is chosen via a click or the Enter key, DOM focus frequently drops to the <body> element instead of returning cleanly to the input or closing the dropdown.

Incomplete Keyboard Navigation

A fully accessible combobox must be operable without a mouse. Developers frequently implement basic click behaviors while neglecting standardized keyboard interactions:

  • Arrow Key Navigation: Pressing the Down Arrow key should open the listbox or move through the options sequentially, while the Up Arrow moves backward.
  • The Escape Key: Pressing Escape must close the dropdown and keep focus on the combobox input without resetting the entire form or propagating the event to parent modals.
  • Tab Key Behavior: Pressing Tab should close the popup and move focus to the next focusable element on the page, optionally selecting the currently highlighted item depending on the design pattern.

Lack of Selection and State Semantics

Options inside the dropdown must explicitly declare their roles and selection states:

  • Missing Option Roles: Dropdown containers must use role="listbox", and each selectable item must use role="option". Without these, screen readers announce generic <div> or <li> tags with no context.
  • Neglecting aria-selected: When an option is active or chosen, it must have aria-selected="true". Unselected options must either explicitly declare aria-selected="false" or omit the attribute according to the specific ARIA implementation. Relying only on CSS classes (like .is-active) provides no context to non-visual users.

Dynamic Filtering Without Screen Reader Announcements

When a user types into an autocomplete combobox, the list of options updates dynamically. Sighted users see the list shrink, but assistive technology users receive no feedback unless explicitly informed. Developers often fail to communicate:

  • Result Counts: If typing filters fifty results down to three, screen reader users should be notified via an aria-live="polite" status region (e.g., "3 results available").
  • No Results State: If a query yields zero matches, an explicit "No results found" option or status announcement must be triggered rather than silently hiding the dropdown.

Inaccessible Touch and Mobile Experiences

On mobile devices, custom comboboxes frequently clash with native operating system keyboards and screen readers like TalkBack or VoiceOver:

  • Virtual Keyboard Obscurity: The virtual keyboard often covers the absolute-positioned dropdown menu, preventing touch users from seeing or scrolling through options.
  • Blur Event Race Conditions: Tapping an option on a touchscreen can trigger a blur event on the input before the click or pointerdown event registers on the option, causing the menu to vanish before the selection is made.