The Case for a “Hybrid” Select

Developers have long struggled with the native <select> element. It is notoriously difficult to style, and the lack of control over its internal appearance has driven many to build custom replacements from scratch. But those custom components come with their own burden: they rarely replicate the full range of behaviors that come for free with the native element, particularly for keyboard users and assistive technologies.

One way out of this trade-off is a "hybrid" select: a pattern that serves the native element as the default and only swaps in a fully styled custom version when it is safe to do so. The core principle is simple—deliver the native <select> to anyone who might rely on its default behavior, and save the bespoke UI for mouse users on devices that support hover.

Naming the Problem

Before building anything, it is worth clarifying terminology. The word "dropdown" is often used loosely to describe any component that reveals a list on interaction, but that category contains several distinct patterns with different semantics and accessibility requirements.

Broadly, there are three types of components that commonly get lumped together:

  • Menu: A list of commands or actions the user can perform within the page content.
  • Navigation: A list of links used to move through a website.
  • Select: A form control (<select>) that presents a list of options for the user to choose from within a form.

The distinction matters because each pattern carries different expectations about behavior and keyboard interaction. Mislabeling a select as a menu, for instance, often leads developers to apply inappropriate ARIA roles, further muddying the experience. The <menu> element itself is deprecated, and the ARIA menu role is not recommended for site navigation.

Why Native Is Hard to Replace

Attempting to style a <select> is a well-documented pain point. CSS support for the element's internals is inconsistent, and the effort required to make a custom version behave correctly is substantial. The most challenging part is not the visual polish but reproducing the native features that users expect:

  • The selected option is announced clearly by screen readers, including its role, name, and state.
  • Keyboard navigation is predictable across browsers, including arrow keys, Enter to select, and Esc to cancel.
  • The listbox reposition itself to avoid being cut off by the viewport.
  • Operating system preferences, such as high contrast and color scheme, are respected.

Most custom select implementations fail on at least one of these points. Even the native element behaves differently across browsers and assistive tech combinations. When a team decides to build a custom select, they are inadvertently forcing users into a specific interaction model that may not match what those users expect. That is a serious accessibility risk.

A more balanced approach is to treat the native element as the baseline and layer a styled version only where it does not interfere with that baseline.

Building the Hybrid Pattern

The hybrid select consists of two elements: a native <select> that is always in the accessibility tree, and a custom-styled select that is hidden unless the user is on a device with hover support. The two are kept in sync so that the value is consistent regardless of which one the user sees.

The markup starts with the native select placed before the custom one. This ordering is critical for the CSS switching logic. Use a <span> connected via aria-labelledby for the label, rather than a <label>, to avoid focusing the native select when the label is clicked. The custom select is marked with aria-hidden="true" so assistive technologies never encounter it.

For styling, both selects must occupy the same space. The custom select is absolutely positioned and hidden by default, so only the native element influences the layout. The switch is driven by media queries and the focus state:

  • Use @media (hover: hover) to show the custom select only on devices where hover is a primary input method.
  • Use the adjacent sibling combinator (+) to hide the custom select when the native select receives focus, catching keyboard users who navigate with Tab even on hover-capable devices.

The JavaScript layer is minimal, only handling click events for the custom select, synchronizing values between the two elements, and providing basic keyboard controls such as arrow navigation, Enter/Space selection, and Esc to close.

Testing the Hybrid Approach

Informal usability testing with a small group of users with disabilities revealed that the pattern works as intended across a range of input methods, including mouse-only, keyboard-only, VoiceOver on macOS, NVDA on Windows, and VoiceOver on iOS. One edge case did surface: users who enable a VoiceOver setting to “Moves VoiceOver cursor with mouse” could accidentally trigger the custom select when clicking, even though the native version remained the expected control.

The hybrid pattern offers clear benefits:

  • Mobile and tablet users get the native select, which is generally smoother and faster than a custom overlay.
  • Keyboard users interact with the native select's predictable controls.
  • Assistive technologies read the native element without needing custom ARIA wiring.
  • Mouse users on desktops enjoy the fully styled interface.

This is not a universal solution. Complex selects—those with search, grouping, or multi-select behavior—still require a full ARIA implementation. For run-of-the-mill single-choice fields, however, the hybrid method avoids reinventing navigation that already works.

Selects That Look Like Menus

Some interfaces, such as sort controls, use a <select> to change content immediately upon choice. These components sit in a gray area between menu and select semantics. Regardless of the styling, a <select> that automatically reorders page content must comply with WCAG 3.2.2 (On Input), which states that a change of context should not occur automatically unless the user is warned beforehand.

When a selection automatically re-sorts a list, that reordering is a change of context and requires an explicit warning or a confirm button added after the select. Both a styled select and a custom menu can satisfy this requirement—the choice is a matter of how much custom accessibility work the team is prepared to take on.

The hybrid select is a pragmatic middle ground: it preserves the native behavior that makes <select> dependable while offering the visual control that modern designs demand. It will not replace the need for a proper accessible custom component in every scenario, but it is a strong option for simple cases where both aesthetics and accessibility cannot be sacrificed.