The forced-colors Mode for Windows High Contrast: Making CSS Robust

1. What Windows high contrast mode does to websites

Windows high contrast mode is not a cosmetic software feature but a hard system switch: anyone who activates it replaces, in practically every application including the browser, the app's own color palette with one chosen by the user themselves, usually a strongly simplified palette with only a handful of colors. Background images disappear, custom background colors get ignored, and text appears in one of the few system colors. For people with severe visual impairment, this is often the only way to see a website as usable at all, which is why forced-colors as a CSS feature is not a niche topic but decisive for a relevant group of users.

Without deliberate handling of forced-colors, the same pattern shows up regularly: thin, colored borders disappear entirely because their original color is too similar to the system theme's new background color, icons built from pure CSS background images become invisible, and custom checkbox or radio designs lose their visual state. This article shows how to build an interface with forced-colors, system color keywords and targeted exceptions that works reliably in high contrast mode.

2. Detecting forced-colors: active

The media feature forced-colors supports two values: active, when the browser currently renders in forced color mode, and none in the normal case. The query @media (forced-colors: active) { ... } groups all rules that specifically apply to this state. Unlike most other media features, this is not about reinforcing your own design, but about reacting deliberately where the browser has already automatically replaced colors and where custom adjustments are needed so nothing becomes invisible.

An important detail: once forced-colors: active applies, the browser already automatically replaces most color values such as color, background-color and border-color with system colors, even before custom CSS takes effect. Developers therefore do not need to manually reset every single color, only intervene where the automatic replacement causes a problem, for example with background images, box shadows or SVG fill colors, which are not covered by the automatic system color replacement.

/* Normal styles, ignored while forced-colors is active for most color properties */
.badge {
  background: #f0fdf4;
  color: #166534;
  border: 1px solid #86efac;
}

/* Explicit handling for what the browser cannot auto-replace */
@media (forced-colors: active) {
  .badge {
    /* Background images and box-shadows are not auto-replaced */
    background-image: none;
    box-shadow: none;
    /* Use a system color keyword for a reliable, high-contrast border */
    border: 1px solid CanvasText;
  }
}

3. CSS system color keywords in detail

CSS defines a fixed list of system color keywords that dynamically adapt to the active operating system theme, regardless of which specific color values the user has chosen in high contrast mode. Canvas and CanvasText represent the default background and default text, LinkText and VisitedText the link colors, ButtonFace and ButtonText the default colors for form elements, Highlight and HighlightText the selection color of highlighted text. These keywords are the central building block for making custom components appear consistent with native browser elements under forced-colors.

The decisive advantage of these system colors over fixed hex values: they automatically respect whichever specific color scheme the user has chosen in the operating system, whether black on white, white on black, or a custom combination. A forced-colors ready design therefore never uses fixed hex colors inside the media query, only these semantic keywords, so the website works with whatever system palette the user has selected.

@media (forced-colors: active) {
  /* System color keywords replace hardcoded hex values */
  .card {
    background: Canvas;
    color: CanvasText;
    border: 1px solid CanvasText;
  }

  a {
    color: LinkText;
  }
  a:visited {
    color: VisitedText;
  }

  .button-primary {
    background: ButtonFace;
    color: ButtonText;
    border: 1px solid ButtonText;
  }

  ::selection {
    background: Highlight;
    color: HighlightText;
  }
}

4. Using forced-color-adjust: none deliberately

Sometimes the automatic color replacement by forced-colors is undesirable for a particular element, for example a status logo that must keep its exact original color for legal or brand reasons, or a chart whose color coding carries semantic meaning that would become useless under the system palette. The property forced-color-adjust: none deliberately excludes an element from automatic replacement, the element keeps its original CSS colors regardless of the active high contrast mode.

This tool should be used sparingly, because any element with forced-color-adjust: none automatically loses the benefits of the system palette, including the guaranteed contrast against the system background. A proven pattern: set forced-color-adjust: none only for the actual color chart or logo, while surrounding frames, borders and text continue to respond normally to forced-colors, so overall usability is preserved.

/* Chart colors carry semantic meaning and must stay untouched */
.status-chart {
  forced-color-adjust: none;
  background: #fef3c7; /* stays exactly this color, even in forced-colors mode */
}
.status-chart .segment-critical { background: #dc2626; }
.status-chart .segment-warning  { background: #f59e0b; }
.status-chart .segment-ok       { background: #16a34a; }

/* But the surrounding card frame still respects forced-colors */
.status-chart-wrapper {
  border: 1px solid CanvasText;
  background: Canvas;
}

5. Common bugs: disappearing borders and icons

The most common forced-colors bug involves thin, colored borders based on light gray or pastel colors. As soon as the system enforces its own palette, such a border often merges completely with the new background, because both colors can become identical in high contrast mode. The fix is to define critical borders explicitly with the keyword CanvasText, instead of relying on the automatic replacement of a weak original color.

A second classic bug involves icons implemented via background-image with an embedded SVG, or as a CSS ::before pseudo element with background-color: background images are fundamentally not automatically adjusted by forced-colors and either stay visible in their original color or disappear entirely if they sit transparent on transparent. Icons embedded as plain SVG markup with fill="currentColor", on the other hand, automatically inherit the text color and work reliably under forced-colors without additional adjustment.

/* PROBLEM: background-image icon disappears or stays wrong-colored */
.icon-warning {
  background-image: url("warning.svg"); /* not auto-adjusted by forced-colors */
  width: 20px;
  height: 20px;
}

/* SOLUTION: inline SVG with currentColor inherits text color automatically */
/* <svg fill="currentColor" viewBox="0 0 20 20">...</svg> */
.icon-warning-inline {
  color: CanvasText; /* only needed as an explicit override if required */
}

/* PROBLEM: light border merges with the forced background */
.subtle-divider {
  border-top: 1px solid #f1f5f9; /* invisible once forced-colors replaces bg */
}

@media (forced-colors: active) {
  .subtle-divider {
    border-top: 1px solid CanvasText;
  }
}

6. Securing buttons, focus states and custom controls

Native form elements such as <button>, <input> and <select> are automatically rendered with correct contrast by the browser under forced-colors, because they are treated as known UI roles. It becomes critical with custom controls, meaning self built checkboxes, toggles or dropdown menus based on <div> elements that have no native semantics. These need to explicitly reproduce their states, selected, disabled, focused, through forced-colors rules using system color keywords, otherwise the visual difference between active and inactive becomes invisible.

Focus indicators are the most important individual case: a custom styled focus ring based on a custom color can completely disappear under forced-colors. The most robust solution is an outline using the system keyword Highlight, which is guaranteed to be interpreted by the operating system as a visible selection color, combined with sufficient outline-offset so the ring does not merge with the element's own border.

7. Testing forced-colors on Windows and in DevTools

The most reliable test for forced-colors is actually activating it on Windows through "Settings, Ease of Access, Contrast themes", combined with reloading the page in Chrome, Edge or Firefox. Only this way can you observe how the user's real system palette interacts with your own forced-colors rules, including the automatic replacement of color values that no DevTools emulator fully reproduces.

Chrome and Edge DevTools nonetheless offer a fast approximation: in the rendering panel you can enable "Emulate CSS media feature forced-colors", which is already sufficient for most layout and visibility problems to catch them early in the development process. For the final test before a release, however, a real Windows environment with an actually activated contrast theme remains the most reliable path, especially for the exact rendering of system color keywords such as Highlight and ButtonFace.

8. Using forced-colors and prefers-contrast together

Both media features address contrast needs, but at different levels: forced-colors reacts to a hard, enforced system state, prefers-contrast to a gentle preference where the website keeps color control. A robust architecture treats both independently, with their own media query blocks, instead of trying to construct a shared solution for both cases. An element can certainly respond to both prefers-contrast: more and forced-colors: active, but with different, appropriately matched rules.

A common mistake is setting forced-color-adjust: none across an entire layout to supposedly "keep control", while completely cutting off the actual target group of forced-colors, users with severe visual impairment, from the guaranteed high contrast system palette. The better approach is to reserve forced-color-adjust: none only for the few elements where the original color is truly indispensable, for example brand logos or semantic status colors in charts.

9. forced-colors compared: strategies for robust components

Different component types benefit from different strategies for handling forced-colors.

The table shows the consistent principle behind robust forced-colors handling: native elements usually work automatically, everything that relies on background images, box shadows or custom states without native semantics needs explicit rules using system color keywords. Working through this list systematically before every major UI release avoids most of the forced-colors problems that occur in practice.

10. Summary

forced-colors describes the hard system state enforced by Windows high contrast mode and comparable operating system features: most colors of a website are automatically replaced by a limited system palette. System color keywords such as Canvas, CanvasText, ButtonFace and Highlight make it possible to design custom components consistently with this palette, instead of relying on fixed hex values that the automatic replacement does not cover.

The most common sources of error under forced-colors are background image icons, weak border colors and custom controls without native semantics. forced-color-adjust: none should be used deliberately and sparingly, only for elements whose original color is truly indispensable. The most reliable test remains a real Windows environment with an activated contrast theme, DevTools emulation only covers part of the real effects.

11. FAQ: The forced-colors Mode for Windows High Contrast