Safari 27.3 beta's Adaptive Dark Mode may miss WCAG contrast, reimplementation finds

Apple has added Adaptive Dark Mode to the Safari 27.3 beta, announced on November 3, 2026 in a WebKit blog post. The feature addresses a mismatch the WebKit team quantifies: almost 40% of page loads now come from people browsing with dark mode turned on, while only about 10% of pages actually declare support for it. When Safari loads a page that makes no dark-mode declaration and judges it to be mostly light, it rewrites the page's colors — flipping lightness while holding hue steady — and says it targets WCAG's 4.5:1 contrast ratio for text.

An independent test of the transform

A dev.to post published a day later examines what that kind of transform does to real colors. Unable to run the beta, the author rebuilt a minimal version of the described algorithm in about 30 lines of Python and ran two transforms over a 12-color palette of typical light-mode UI colors: naive per-channel RGB inversion, and a lightness flip in HLS space that keeps hue and saturation.

The results expose a clean trade-off. Naive inversion cleared the 4.5:1 bar on 9 of 10 text colors but rotated hues by an average of 135 degrees across the palette — link blue came out orange and success green came out magenta. The lightness flip preserved every hue but passed only 7 of 10. Its three failures were danger red at 4.06:1, muted gray at 4.24:1 and code red at 4.41:1 — near misses, not blowouts.

The difficult cases are saturated colors sitting near the middle of the lightness range, which describes much of a real design system. Pure red, parked exactly at lightness 0.5, comes through untouched. The author's argument: if Safari shipped a pure lightness mirror it would reproduce these exact failures, so WebKit's contrast claim implies an extra correction step — pushing failing colors beyond the mirrored position — that the blog post does not document. The caveat is that these figures measure the reimplementation, not Safari itself.

The parts developers can't detect or escape

Three operational details stand out. Canvas content is left untransformed, and blend effects such as mix-blend-mode are sometimes switched off when they would clash with the rewrite, so a page can end up dark overall with patches of bright content. JavaScript that reads CSS colors receives the authored values rather than the transformed ones, which means the effect cannot be feature-detected from script — verifying a page takes human eyes. And the declared escape hatch, color-scheme: light only, does not function in beta 1 because the "only" keyword is unsupported, leaving one realistic opt-out: ship a genuine dark theme.

Which sites get rewritten

The author also grepped the served HTML of nine homepages. Five clearly declared dark support — Wikipedia, GitHub, MDN, Node.js and Tailwind. Python.org, mozilla.org and Stack Overflow's redirect page showed no declaration, and React's page produced a single ambiguous match. The method misses declarations hidden in external stylesheets, so the count is a lower bound, and the sample skews toward sites that already care about dark mode. The corollary is uncomfortable: the pages likeliest to be rewritten are those that have given dark mode the least thought.

Why it matters

Adaptive Dark Mode hands developers an appearance they never built and cannot detect from code. Until the opt-out keyword works, the realistic choices are declaring color-scheme and shipping a real dark theme, or reviewing pages by hand in the beta. The dev.to numbers also show what the failure mode looks like: contrast ratios between 4.0 and 4.5 can seem fine at a glance yet fail WCAG AA, and they cluster in the saturated accent colors design systems use for links, errors and status messages. For anyone maintaining a light-only site, the beta period is the window to find out what Safari will do to it.