Contrast in dark mode must be recalculated, not reused from the light palette

What it is

A pair that passes in light appearance can invert or collapse when the background goes dark. Dark mode is not the light palette dimmed as a whole, and it is not finished by swapping each pair. Contrast in dark mode must be recalculated: every foreground against its adjacent background has to be sampled again under the dark appearance. Ratios already written down for light mode cannot be reused.

Light grey type fails on white and may scrape through on near-black. White type on a branded blue button may pass in light and drop if that button is restyled to a darker blue. Reusing the old table mis-judges both directions.

Why it happens

Contrast is a relative luminance gap between a pair, not the absolute lightness of a colour. Changing the background replaces one member of the pair, so the gap must be recomputed. Naive “auto dark” multiplies light values by a factor or inverts them: pairs that were already short can get shorter, pairs that sat just above the bar can be pushed below it. The visual system is also not symmetric for small type on dark versus light — a second reason to recalculate, beyond the arithmetic.

Translucent stacks are more dangerous in dark. An 8% black veil on white in light mode is almost invisible; the same black veil on near-black is nothing. A white veil on a dark ground washes contrast out. An alpha that passed in light is a different pair of pixels in dark.

Studying it

Sample every foreground–neighbour pair under both light and dark color-scheme, in two columns, and mark “pass light / fail dark” and “fail light / pass dark.” Do not copy the light column into the dark column.

Independent variables: appearance (light / dark), whether dark was produced by automatic inversion, whether translucent stacks keep their original alpha. Dependent variables: how many pairs cross the threshold, failures in each direction, error of automatic inversion against a hand-tuned dark.

APCA can be a research check on the asymmetry of small type on dark; conformance claims still usually cite WCAG 2.x ratios. Both must be re-run on dark pixels, not only on light. Split system dark appearance from an in-product theme toggle — they do not always produce the same pixels.

Where it stops holding

When the OS appearance is light and the product forces dark (or the reverse), the pixels that actually win are the ones to measure; do not assume the two switches point the same way. Photographs, video and embedded third-party light blocks will not recalculate with your palette; they sit as light islands on a dark page, and contrast has to be judged inside the island and at the island’s boundary with the dark page. OLED near-black and grey-black differ in absolute luminance; a lab-display ratio is not phone appearance, but the ratio remains a cross-product judgement. Print has no dark mode.

Applying it

• Run a separate contrast pass for dark appearance, resampling every pair. Do not tick the light ratio table again.
• Do not generate dark type and buttons by inverting everything or multiplying by one factor. Tune pairs by hand, especially type on branded buttons, translucent stacks, and disabled states.
• When in-product theme and OS appearance disagree, measure the set that actually applies, not the set you assumed the user would choose.
• How to check: turn on dark appearance and eyedrop rendered pixels for every text, icon, border and button pair on the primary path. Where the light table passes and the dark pixel fails, the dark pixel wins.

Related

• Same group: J2.15.2 System-forced high contrast can override custom colours and distort the design · J2.15.3 Images and icons need variants prepared for dark backgrounds · J2.15.4 Theme switches must not drop state or focus
• Nearby: J2.01 Text Contrast · J2.10 Non-text Contrast · J5.13 System Accessibility Settings
• Search terms: dark mode contrast · color-scheme · recalculated contrast