Safari 27 makes the native select customizable

Safari 27.0 shipped on 16 September 2026. Apple's release notes list build 27.0 (20625.1.29) for iOS 27, iPadOS 27, visionOS 27, macOS 27, macOS 26 and macOS Sequoia. A Web Standards summary, published on 17 September, counts 83 new features.

The release is wide rather than deep: a rewritten ES module loader, subpixel inline layout, scroll anchoring that needs no opt-in, the service worker static routing API and a long tail of accessibility fixes. Two of the 83 features decide what a Form embedded in someone else's page can assume: a native select you can style, and a way to announce a message without a live region.

The native select, now styleable

The select element was the control you styled least and replaced most. Customizable select changes that arithmetic. Applying appearance: base-select switches the element to new user-agent defaults and unlocks the rest of the feature.

select,
select::picker(select) {
  appearance: base-select;
}

• ::picker(select) targets the popup itself, and ::picker-icon targets its chevron.

• ::checkmark targets the mark on the chosen row.

• selectedcontent decides what the closed control shows for the current option, so the summary can be markup rather than a copy of the label.

• An option may now hold HTML, so an option can carry an icon or a two-line label.

None of that replaces the control. It is still a real form control, so keyboard navigation, screen reader semantics, form submission, constraint validation and the change event keep working. A dropdown rebuilt from div elements throws all of that away and then rebuilds a worse version. Opting into base-select does not.

ariaNotify() without a live region

Apple's release notes add support for the ariaNotify API, which queues text for a screen reader to announce without an ARIA live region. For a Form this closes a specific gap. A live region speaks when its contents change, so an error summary that repeats the same sentence produces no change and no announcement. ariaNotify() queues the message itself.

The risk is volume. An announcement is not a validation message. If an embedded Form announces every field change, a screen reader user hears a running commentary and leaves the page. Announce what the person has to act on: the first invalid field after Send, a Submission that did not go through, a Step that has just opened.

What to test in an embedded Form

• The closed select on a long option list, in light and dark mode.

• A select inside the Generated component's own layout, at 320px.

• An error summary that is announced once, not twice.

• forced-colors mode, because base-select ships defaults of its own.

FormFlow's Generated component renders native HTML form controls, so Safari's new defaults can reach an embedded Form without any change on our side. We have not verified the Generated component against Safari 27 for this post, and we will not imply that we have. If you embed a Form, render it in the Safari versions you support before you rely on the default look.

What this does not decide

Safari shipping customizable select does not make it interoperable. The Web Standards summary says the new default design went to the CSS Working Group for further refinement, and that an identical starting place depends on other browsers updating their implementations. A style that looks right in Safari 27 can look wrong in another engine on the same day.

ariaNotify() is a browser addition, not a form standard. It does not decide which announcements are appropriate, and it does not replace a label, a fieldset with a legend, or a visible error beside the field.

Nothing here is a FormFlow support statement for Safari 27, and nothing here changes how an embedded Form behaves in a Safari version that does not ship these features. For the POST contract the embedded Form posts to, read the API reference.