In a design system, how should components handle an operating-system setting that asks for more contrast versus one that replaces the app's colors entirely?

## Two very different settings Operating systems offer users with low vision, light sensitivity or reading difficulties two kinds of contrast help. They look similar in a settings screen but demand opposite responses from a design system: | Setting | What it means | Who controls the colors | The system's job | |---|---|---|---| | **Increase contrast** | Please use stronger contrast | The app | Provide a high-contrast value set | | **Color replacement** | Use my colors instead of yours | The user's palette | Stay usable when your colors are gone | ## Answering a request: the high-contrast value set Because modes are value sets over semantic tokens, a high-contrast mode is one more mapping — two, in fact, because it combines with light and with dark. In a recruiting app's applicant-tracking screens it typically: - darkens secondary text on light surfaces (and lightens it on dark ones), since secondary text is usually the first to fall near the minimum; - strengthens `border.subtle` so the edges of candidate cards and pipeline columns are unmistakable; - removes translucent overlays and faint tinted surfaces, whose effective contrast depends on what lies beneath; - thickens or strengthens the focus indicator; - keeps status colors distinguishable by something besides hue — the stage chip's label and icon carry the meaning. The baseline modes should already meet WCAG 2.2 Level AA — 4.5:1 for normal text and 3:1 for component boundaries and state indicators — so the high-contrast set goes further than the minimum rather than rescuing a failing default. ## Surviving a replacement: design for missing colors In a color-replacement mode the platform substitutes a few user-chosen colors — typically one for text, one for backgrounds, a few for links, selection and controls. What happens to a component then: - **Background fills collapse** into the single background color. A pipeline whose stages were told apart by tinted columns becomes one undivided field. - **Borders and outlines survive**, drawn in the user's color. A border that was transparent in normal modes can become visible here, which is a common technique for keeping a boundary. - **Text survives**, in the user's text color. - **Icons drawn in the text color survive**; icons with baked-in colors may vanish or clash. - **Shadows usually disappear**, so elevation by shadow alone is lost. The rules that follow for component design: 1. **Never mark a boundary with fill alone.** Give cards, inputs and columns a border, even a transparent one in normal modes. 2. **Never mark a state with fill alone.** A selected candidate card needs a border, a check icon or a text change as well as a tint. This also serves WCAG 1.4.1 Use of Color, which does not allow color to be the only visual means of conveying information. 3. **Draw icons in the current text color** so they take the user's color. 4. **Keep a real focus outline**, not a background-only focus style. 5. **Do not override the user's palette.** Adjustments should restore meaning, such as making a boundary visible, and never reimpose brand colors. ## Testing both - Run the high-contrast value sets through the same contrast checks and visual tests as every other mode. - Emulate a color-replacement mode in visual tests of key components, and review them by eye: the question is not a ratio but whether every boundary, state and focus position is still visible. The short interview answer: one setting asks you to do better with your colors, the other takes your colors away — so build a high-contrast value set for the first, and for the second make sure nothing essential ever depended on fill color.