Customizable `<select>` is still a `<select>`: keep the text

Every time the platform hands us a styleable form control, the same thing happens: someone replaces the visible label with a tidy icon, ships it, and quietly cuts off the people who navigate the web by voice, by braille, or by ear. Customizable <select>, landing in Safari 27, is the next test of that habit. WebKit has published its "golden rule" for the feature, and the rule is doing real work — it is the difference between a form control that opens up and a form control that just looks open.

The temptation, named

The pitch for customizable <select> is genuinely exciting: per WebKit, authors can finally style the control without reaching for a JavaScript library or wrapping it in extra <div>s. That is a long-asked-for win. The trouble is that the moment the visual surface of an <option> becomes paintable, the next idea is usually "let's replace the words with an icon" — a colour swatch, a bird silhouette, a tiny flag. It looks great in the comp. It also disappears the entire control for anyone whose browser is talking to them.

This is not a hypothetical. This is the same anti-pattern the web has shipped over and over: a control that means something to sighted mouse users and means nothing to everyone else.

The rule, in the source's own words

The WebKit post states it plainly: always provide text content or accessible text attributes for your option elements. The corollary the post draws — and this is the line worth pinning above your monitor — is that "Icons, swatches, and illustrations are additions to an option — never substitutes for it."

The mechanism behind that rule is the accessibility tree. Per WebKit, text inside an option that you hide visually with a .visually-hidden class still stays in the accessibility tree, which means screen readers, braille displays, and speech recognition all still have something to work with. The control reads, the control speaks, the control responds to "click Wildlife" — even when the pixels are showing you a small bird.

The shape of doing this right

WebKit's example for an option that pairs an icon with a label is exactly the structure to copy:

<option>
   <img src="bird.svg" alt="">
   <span>Wildlife</span>
</option>

Two things to read off that snippet. First, the <img> carries alt="" — it is marked decorative, because the meaning is already in the <span> next to it. Second, the meaning lives in text, not in the picture. Per WebKit's guidance: if you use an icon as an <img>, add an alt or aria-label — or mark it decorative with alt="" and let the visible (or visually-hidden) label carry the meaning. Either path works. The path that does not work is the picture on its own.

The other half of the rule is for the browsers that have not shipped this yet. WebKit's advice is to wrap your enhancements in @supports (appearance: base-select) and keep plain text as your baseline. That is progressive enhancement in its purest form: a native <select> with real <option> text everywhere, and the painted version layered on for the engines that support it.

@supports (appearance: base-select) {
  /* Your customised select styles go here. */
}

If you build it this way, you have not made a choice between "modern" and "accessible." You have the native control's semantics, the native control's keyboard model, the native control's voice-control hooks — and your design on top.

The verdict

The reason this guidance matters is not that customizable <select> is dangerous. It is the opposite. It is one of the cleanest "use the platform" wins HTML has shipped in years: a real, native form control that finally bends to a design system without a script. The golden rule is what keeps that win a win.

Treat it as a hard constraint on your next form PR:

• Every <option> has real text content, or an accessible text attribute that carries its meaning.
• Visual additions — icons, swatches, illustrations — sit next to the text, not in place of it.
• Decorative <img> inside an option uses alt=""; a meaningful image uses alt or aria-label.
• The customised styling is gated behind @supports (appearance: base-select), with the native <select> as the baseline for everyone else.

Ship it like that and the people whose browsers speak instead of paint get the same control as everyone else. That is the bar. The good news is the source already wrote the rule down — your job is to hold the line.