Customizable Select Menus: 9 UX Checks for Better Website Forms

Customizable select menus let a website form use a fully branded dropdown while keeping the reliability of a real HTML select element. Safari 27 added support in September 2026, joining Chrome, so designers now have a credible native alternative to fragile scripted dropdowns. Support is still not universal, so treat it as progressive enhancement and run the nine UX checks below before launch.

Apple published the Safari 27 feature notes on 17 September 2026, and the September web-platform review on 2 October highlighted Safari joining Chrome. MDN still marks related picker styling as limited availability. In short: the opportunity is real, but a launch plan still needs a fallback and proper cross-browser testing.

Dropdowns look like a small detail. In practice, they sit inside the forms that turn visitors into enquiries, bookings, and sales. When we audit underperforming contact forms, the field that causes hesitation is often a dropdown that asks a vague question or hides the right answer three scrolls deep. That is why this update matters beyond aesthetics.

What Changed in Safari 27

A site now opts a real select element into the new base appearance (appearance: base-select), and the browser unlocks deep styling of both the button and the popup picker (::picker(select)). Designers can place richer HTML inside options, such as an icon or a short description, and control what shows in the closed button with the selectedcontent element.

WebKit describes the result as a native select with built-in keyboard navigation, screen-reader semantics, form submission, validation, and change events. It is not a stack of generic <div> elements pretending to be a form control.

For anyone who has shipped a custom dropdown, this removes an old trade-off. Teams no longer have to choose between a reliable but visually rigid native select and a polished JavaScript widget that has to rebuild focus, state, and accessibility from scratch. Our developers have spent more hours than we would like patching those scripted widgets for keyboard and screen-reader users, so a native route is genuinely welcome.

The new freedom does create more design work, though. There are more states to specify, and an enhanced picker can behave differently from the phone's own picker on mobile.

Choose the Right Control First

A customizable select is not automatically the right answer; the question decides the control, not the design trend.

If a user must search thousands of products or pick several items, an accessible combobox is usually better. If the question has four ordinary answers, visible radio buttons are often faster than any dropdown. In our wireframing stage, we try to settle this before visual design starts, because changing the control later means redesigning the field, its states, and its validation.

Nine UX Checks Before You Publish

• Check 1: Prove the fallback works. Start with a complete ordinary select and enhance it only in browsers that support the new appearance. WebKit recommends a feature query (@supports) so richer styles apply conditionally. Unsupported browsers should get the familiar native control, not an empty shell or a broken popup. We test the fallback before the polished version, never after.
• Check 2: Write a visible label and a clear question. A beautiful dropdown cannot rescue an unclear question. Give the control a persistent visible label and associate it with the select in code. The W3C forms guidance notes that explicit labels make controls easier to understand and give a larger click target. "Project type" is clearer than "Select option."
• Check 3: Keep meaningful text in every option. Icons, logos, and colour swatches can support recognition, but they must never replace the option name. WebKit's golden rule is to keep text in every option so it stays understandable to assistive technology and to browsers that ignore the richer markup.
• Check 4: Control the length and grouping. A dropdown hides its choices, which makes scanning and comparison harder. Keep simple lists short, group related options with meaningful <optgroup> labels, and use a natural order. If people regularly scroll through dozens of near-identical options, a searchable combobox or a two-step flow will reduce effort more than styling.
• Check 5: Design the closed and open states together. The compact button and the open picker are one interaction. Specify spacing, text wrapping, icon alignment, popup width, and how the selected option appears after a choice. Use selectedcontent only when it improves recognition, keeping the closed state concise and readable.
• Check 6: Specify every interaction and error state. Design the default, hover, focus, open, selected, disabled, required, invalid, and error-message states. Include high-contrast and dark-mode behaviour. Never remove the focus indicator unless you replace it with a clearly visible alternative.
• Check 7: Test touch and mobile behaviour. Chrome's documentation warns that opting into the base appearance can replace the phone's built-in picker with the browser's customizable picker. Test one-handed use, zoom, scrolling, orientation, and touch targets on real devices. Ensure the popup is not clipped by sticky headers or chat widgets.
• Check 8: Verify values, validation, and analytics. Rich content must not blur the difference between the label people see and the value the form submits. Test every option, required-field validation, default states, and CRM payload mapping. Track valid submissions and drop-offs without sending sensitive data into analytics.
• Check 9: Release gradually and watch real behaviour. Ship the enhanced version to a controlled audience or one lower-risk form first. Compare browser segments, error rates, and conversions against your baseline. Document tested devices and fallback behaviours in a component note for long-term maintenance.

A Practical Example: The "Project Type" Field

Take a "Project type" field on an agency enquiry form, the kind we design and rework regularly. The options are Website design, Website redesign, Ecommerce store, and Not sure yet.

A customizable select can add a simple icon and one short line of context to each option in the open picker. The closed button shows only the chosen service name, so the form stays compact.

The fallback is a normal text-only select. The field has a visible label, every option has a complete name, and "Not sure yet" gives undecided visitors a safe route instead of a forced guess. Before launch, the value sent to the CRM is tested for each option. On mobile, the popup is checked to fit the viewport and close without losing what the visitor already typed.

This is a useful enhancement because it clarifies a small set of meaningful choices. It is not decoration for its own sake, and that distinction is the whole point of user-centred web design.

Quick Decision Framework

Common Mistakes to Avoid

• Replacing option text with a logo, flag, or colour alone.
• Styling the closed button but leaving the picker, focus, and error states undesigned.
• Assuming universal support because Safari and Chrome now implement the feature.
• Using a dropdown for a searchable, multi-select, or comparison-heavy task.
• Launching without testing submitted values, validation, CRM mapping, and mobile interaction.

Small Fields, Big Impact

New browser features are exciting, but the forms that convert best are rarely the flashiest. They ask a clear question, offer sensible choices, recover gracefully from mistakes, and work on the cheapest phone your visitor might use. Customizable select menus are a welcome tool for that job, as long as the fallback, labels, and testing come first.

Frequently Asked Questions