Inaccessible custom select

Problem Context

• A team replaces native select styling with divs, popovers, portals, or JavaScript-only menus.
• The control works for pointer users but fails keyboard, screen reader, voice, form submission, or zoom scenarios.
• The popup may lose focus, clip options, close unexpectedly, or update only visual text instead of the actual form value.
• The product needs a single known value, searchable known value, or multiple values but uses one generic custom dropdown for all cases.

Selection Rules

• Flag this anti-pattern when a custom dropdown cannot be opened, navigated, selected, dismissed, and reviewed by keyboard.
• Use native select when the user chooses one value from a finite known list and platform behavior is sufficient.
• Use an accessible custom listbox only when native select cannot meet product requirements and the implementation exposes label, popup, active option, selected option, value, and expanded state.
• Use autocomplete or combobox when users need to type to filter or complete a long known list.
• Use multi-select when users can choose more than one value and need persistent selected chips, removal, and multi-value form submission.
• Do not ship a visual dropdown until it synchronizes visual value, submitted value, accessible value, and validation state.
• Avoid portal or overlay implementations that break focus return, option clipping, Escape dismissal, or screen-reader discovery.

Required States

• Closed state with persistent label, current value, and collapsed state.
• Open popup state with reachable options and visible active option.
• Selected option state that remains visible after the popup closes.
• Validation state when no valid option has been selected.
• Dismissed state where Escape or outside click preserves the current value and restores focus.
• Synchronized form state where the selected value is submitted and announced consistently.

Interaction Contract

• The trigger exposes an accessible name, current value, role, and expanded or collapsed state.
• Keyboard users can open the popup, move through options, select an option, dismiss without change, and continue from a predictable focus position.
• Pointer, keyboard, touch, voice, and assistive technology users can complete the same selection without losing context.
• The active option and selected option are visually and programmatically distinguishable.
• The selected value updates the visible trigger, validation state, and submitted form value together.
• Custom behavior is tested across native browser zoom, mobile viewport constraints, reduced motion, and screen reader modes.

Implementation Checklist

• Start with native select and document why custom behavior is necessary before replacing it.
• If custom, choose the correct pattern: listbox for browseable single choice, combobox for typed filtering, or multi-select for multiple values.
• Expose stable label, popup relationship, expanded state, active option, selected option, and current value.
• Implement keyboard opening, arrow navigation, Home and End where appropriate, Enter or Space selection, Escape dismissal, and focus return.
• Keep options readable and reachable when rendered in portals, scroll containers, small screens, and zoomed layouts.
• Synchronize the selected value with form submission, validation, reset, and server-rendered defaults.
• Test with keyboard only and at least one screen reader before claiming custom select parity.

Common Generated-UI Mistakes

• Using divs with click handlers and no role, label, expanded state, or option semantics.
• Updating the visual label but not the form value that submits to the server.
• Closing the menu before keyboard or assistive technology users can inspect options.
• Losing focus when the popup is rendered in a portal or dismissed with Escape.
• Using a custom select for a long list that needs search or autocomplete.
• Using a single-select-style dropdown for multiple values without chips, removal, or clear selected count.
• Clipping options inside overflow containers or hiding them from screen readers.

Critique Questions

• Can a keyboard-only user open it, inspect options, choose one, dismiss without change, and continue from the trigger?
• Does the screen reader announcement include label, current value, expanded state, option count or option names, active option, and selected state?
• Does the selected value submit, validate, reset, and hydrate like a real form control?
• Is this actually a select, or does the task need autocomplete, combo box, radio group, or multi-select behavior?
• What happens when the popup is clipped, the page zooms, or the user presses Escape?