Interface Lab
Login
Back to knowledge
Typography Color Accessibility

Forced Colors and High Contrast Support

High contrast is not dark mode; forced-colors can override many color properties, so components need system colors, real outlines, and non-color redundancy.

forced-colorshigh-contrastfocusnon-text-contrast

Design Principle

Accessible color systems should respect user-agent high contrast rendering instead of forcing brand color. Critical states must remain understandable when system colors take over, shadows are removed, and background images disappear.

Large Theory

High contrast support is a user-controlled rendering contract, not another dark theme. prefers-contrast expresses a user preference for more or less contrast; forced-colors: active means the browser or system may replace author colors with system colors at paint time. The design system must preserve meaning, state, and focus after that replacement.

Small Points

  1. forced-colors can affect text color, background, border, outline, SVG fill/stroke, and related color properties.
  2. box-shadow and text-shadow may be forced to none, and non-URL background images may be removed.
  3. System colors such as Canvas, CanvasText, ButtonFace, ButtonText, Highlight, and HighlightText are more reliable than hard-coded brand colors.
  4. forced-color-adjust: none belongs only in small controlled exceptions, such as custom-drawn icons whose geometry carries meaning; do not globally disable user high-contrast settings.
  5. Focus, selected, error, disabled, and chart states cannot rely only on hue; add outline, border, text, icons, shape, line style, or pattern redundancy.
  6. WCAG Non-text Contrast and Focus Appearance require visible component boundaries, focus indicators, and adjacent color relationships, not only body-text contrast.

Design Judgment

A UI has high-contrast resilience when buttons, inputs, selected items, errors, links, focus rings, and SVG icons remain identifiable after author colors are disabled. If focus is only a glow or a state is only a brand background, it can disappear or distort in forced colors.

Implementation Notes

Create a high-contrast state table for default, hover, focus-visible, active, selected, disabled, error, and loading. Use real outline and outline-offset, keep borders for boundaries, make SVG use currentColor or system colors, and avoid placing critical states inside box-shadow or background-image. Verify forced-colors: active, prefers-contrast: more, keyboard Tab order, and 200% zoom with browser DevTools or OS settings.

Counterexamples/Risks

Treating dark mode as high contrast, setting forced-color-adjust: none globally, replacing outlines with shadow-only focus, red/green states without text or icons, transparent borders that become unpredictable in forced colors, and custom SVG without currentColor or a label.

Case Study

MDN's forced-colors documentation explains that colors can be forced to the system palette at paint time and that shadows and non-URL background images can be removed. WCAG 2.2 Non-text Contrast and Focus Appearance include focus indicators, component boundaries, and adjacent-color relationships. The reusable lesson is that high-contrast design starts from component state and system colors, not brand palettes.

Source Links

MDN prefers-contrast: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/At-rules/%40media/prefers-contrast MDN forced-colors: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/At-rules/%40media/forced-colors WCAG 2.2 Non-text Contrast: https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html WCAG 2.2 Focus Appearance: https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance.html

Agent Directive

When implementing component color, check forced-colors and prefers-contrast; critical states use system colors, real outlines/borders, and non-color redundancy instead of relying only on brand color, shadows, or background images.