Does your page still read well in dark mode?

• Contrast in each scheme.axe-core's colour contrast rule runs once in light and once in dark, and every failure is labelled dark only, light only or both, with the colours and ratio for each.
• Invisible text. Text the same colour as its background, a 1:1 ratio, is pulled out as its own finding.
• Links lost in text. Links that differ from the words around them only by colour must reach 3:1 against that text, under WCAG 1.4.1. A link colour chosen for white often fails on dark.
• Dark mode signals. The color-scheme meta tag, the CSS color-scheme on html and body, prefers-color-scheme rules and light-dark() in the stylesheets, and whether any colour the page sets actually changes between the two modes.
• Adaptive Dark Mode readiness. Whether Safari will adapt the page, and the images, canvases and effects it may not handle well.

The most common dark mode bug is a page that declares color-scheme: light dark but hard-codes its text colour. In dark mode the browser paints the page background near-black (rgb 18, 18, 18 in Chrome) while your dark grey text stays dark grey. In our tests that pair measured 1.17:1.

axe-core, the engine behind most automated checkers, reports no failure here. When the html and body backgrounds are transparent it assumes the page is white, so it measures dark grey against white and passes it. This is an open axe-core issue, number 4608. Before running axe, this checker sets the root background to the browser's own Canvas colour, which changes nothing on screen but gives axe the real background to measure against.

The reverse case, a white card with the default text colour, turns into white on white. axe-core reports that as needing review rather than as a failure, so the checker lists it separately as invisible text.

Safari 27.3 beta adds Adaptive Dark Mode. When a visitor turns it on, Safari darkens light pages itself, using a colour transform that WebKit says aims for 4.5:1 contrast. WebKit gives the reason: almost 40% of page loads come from people in dark mode, but only 10% of page loads support it.

What decides whether your page is changed:

• light dark declared: in the meta tag or as color-scheme on :root or body, and Safari leaves the page alone. WebKit advises declaring it in the HTML or CSS, not later from JavaScript.
• light only: the opt-out. WebKit notes that the only keyword is not supported in Safari 27.3 beta 1.
• Nothing declared: Safari estimates whether the page is mostly light or dark, and adapts it if it is light.

Safari leaves most images and all canvas content unchanged, inverts simple black and white logos, and may turn off masks and blend modes. The preview in the results uses Chromium's automatic dark theme, which follows the same skip rules in our tests but uses a different colour algorithm, so treat it as a rough guide. Read more in what Safari's Adaptive Dark Mode means for accessibility.

WCAG 1.4.3 Contrast (Minimum) asks for 4.5:1 for normal text and 3:1 for large text, and 1.4.11 Non-text Contrast asks for 3:1 for controls and meaningful graphics. Note 6 of the WCAG 2.2 contrast ratio definition says authors need not consider "color changes made by the user agent, except where caused by authors' code".

So Safari's Adaptive Dark Mode and Chrome's automatic dark theme are outside your conformance: the checker reports them as readiness, not failures. A dark theme you wrote, or the dark canvas your color-scheme declaration switches on, is caused by your code. Whether every theme an author provides must conform is still an open W3C question (issues 2889 and 4317). Many auditors test both, and fixing dark-only failures is the safe course.

• Set colours in pairs. Whenever you set a text colour, set its background too, and give both a dark value. The CSS spec itself warns that mixing default colours with author colours cannot guarantee contrast.
• Use light-dark() or prefers-color-scheme. light-dark() picks a value from the used colour scheme; a prefers-color-scheme media query swaps custom properties.
• Declare it early. Put the color-scheme meta tag in the head so form controls, scrollbars and the page background match from the first paint.
• Give images a dark version. Use SVG logos that draw with currentColor, or a picture element with a source for prefers-color-scheme: dark.
• Check focus indicators. A dark blue focus ring vanishes on a dark page. The two-tone focus ring recipe works on any background.

<meta name="color-scheme" content="light dark">

:root {
  color-scheme: light dark;
  --text: light-dark(#1f2937, #e5e7eb);
  --surface: light-dark(#ffffff, #111827);
}
body { color: var(--text); background: var(--surface); }

<picture>
  <source srcset="logo-dark.png" media="(prefers-color-scheme: dark)">
  <img src="logo.png" alt="Acme">
</picture>

To build a palette that holds up in both modes, see the guide to OKLCH and APCA colour systems, and check single colour pairs with the contrast checker.

• One page, at 1280 by 800 pixels, as a first-time visitor with no cookies. Content inside iframes is not tested.
• Only the system preference is tested. A theme toggle on your site that sets a class when clicked is not exercised.
• Text over images and gradients cannot be measured automatically, so it is listed for checking by eye. Non-text contrast and focus indicators are not measured.
• The dark canvas colour differs between browsers; Chrome's is rgb 18, 18, 18. A ratio near the threshold may come out slightly differently in Safari or Firefox.
• The Adaptive Dark Mode verdict follows WebKit's published rules. Safari's test for whether a page is mostly light is not documented, and nothing a page or tool can measure shows Safari's adapted colours.