System-forced high contrast can override custom colours and distort the design

What it is

The operating system can replace custom page colours with a system high-contrast palette. A branded button fill may become the system background, a stroke may vanish, and icons that were only visible against the brand colour vanish with it. Forced colours are not another dark toggle inside the product theme; they override the colours you wrote. Distortion in this mode is the expected mechanism. What has to be handled is whether information survives the distortion, not whether the brand colour survives.

Testing an in-product dark theme is not testing system-forced high contrast. The two switches rewrite colour differently.

Why it happens

Forced colours map CSS colours onto a small set of system colours (text, background, link, button border, highlight). The mapping drops the hue you chose and keeps a role: this is text, this is background, this is a button. A card whose only edge was a fill colour may map to the same system background as the page, and the edge evaporates. A control whose focus ring was a box-shadow often loses that ring, because shadows are not in the mapping table. Writing forced-color-adjust: none to keep a brand is refusing the user’s contrast palette and cancelling the mode.

Distortion itself is not a defect. The defect is: after mapping, buttons no longer look like buttons, links no longer look like links, focus is gone, states cannot be told apart. The few role colours the system still gives must be enough to identify parts.

Studying it

Open the product under a Windows contrast theme (or a browser’s forced-colours emulation) and walk a list of “what remains after custom colour is mapped”: button edges, input edges, focus, link underline, selected state, icons.

Independent variables: forced colours on or off, whether forced-color-adjust: none locks the palette, whether control edges depend on shadow or fill alone. Dependent variables: whether parts remain identifiable after mapping, whether focus remains, how many controls melt into the background.

Do not capture only the home page. Forms, menus, dialogs and selected tabs fail more often under mapping. Cross system high contrast with the in-product dark theme: some people run both, some run only the system one.

Where it stops holding

macOS Increase Contrast and iOS Smart Invert are not the same pipe as Windows contrast themes; one cannot stand in for the other’s conclusion. Print, native fullscreen games, and some canvas / WebGL content are not bound by CSS mapping and need their own high-contrast path. If the user chose low contrast rather than high, this override does not apply. Mail clients vary in forced-colour support for HTML mail; a pass on the web is not a pass in the inbox.

Applying it

• Accept under system-forced high contrast: controls need an edge or focus line the system can map. Do not make the only boundary a shadow or a brand fill.
• Do not turn off forced-colour adjustment to keep a brand. Brand is supposed to yield in this mode.
• Links, focus and selected states still need a non-hue shape after mapping (underline, ring, tick), because hue has already been replaced by a system colour.
• How to check: turn on a system contrast theme and walk login or checkout. Every button that melts into the background, every invisible focus, every brand block that “recovers” only after forced adjustment is disabled, is information lost after distortion.

Related

• Same group: J2.15.1 Contrast in dark mode must be recalculated, not reused from the light palette · 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.06 Focus Visibility · J2.10 Non-text Contrast · J5.13 System Accessibility Settings
• Search terms: forced colors · Windows contrast themes · forced-color-adjust