v158 · css · system colors

AccentColor & AccentColorText follows accent-color value

The accent-color property has tinted native checkboxes, radios, ranges and progress bars since Chrome 93 — but custom UI next to them could not reference that colour from CSS. Chrome 158 implements the CSS Color 4 resolution: the AccentColor system colour keyword now resolves to the element’s effective accent-color value, and AccentColorText to a contrasting foreground for it. One property themes the native controls; two keywords let everything else follow.

concepts

  1. Accent mirror

    The canonical use. Pick an accent: the native checkbox, radio, range and progress recolour in every current browser, and a custom chip styled with background: AccentColor; color: AccentColorText mirrors them where the keywords ship. A three-tier probe reports this browser’s real behaviour — keywords unparsed, parsed-but-static-OS-accent, or following the value.

  2. Resolution inspector

    An inheritance-tree inspection tool. Set accent-color at any level — or type any CSS colour, validated live — and read back, per element, the computed accent-color next to what AccentColor and AccentColorText actually resolve to via getComputedStyle.

  3. One-accent theming

    The product case: a settings card where a single accent-color declaration themes native form controls and a custom primary button, badge and focus treatment — plus a derived tint/shade palette built with color-mix() on top of AccentColor, so a whole component theme hangs off one property.

  4. Contrast & cycles

    The edge cases the WPT suite pins: AccentColorText flipping between black and white as the accent lightens, accent-color: AccentColor resolving to the parent’s accent instead of cycling, accent-color: currentcolor indirection, and what forced-colors mode does to all of it.

why it shipped

Chromium had implemented the two keywords “in a limited capacity”: behind the CSSAccentColorKeyword flag they reflected the OS accent when accent-color was auto and a fixed default otherwise — so authors could not keep custom styling consistent with the form controls they had just tinted. The CSSWG resolved (issue #5900) that the keywords should follow the accent-color value, and CSS Color 4 now says so normatively. Safari has the matching change in flight and Firefox is positive, so Chrome 158 aligning closes the loop on a Baseline-bound pattern: declare the brand colour once, reference it everywhere.

the API

.card { accent-color: hotpink; }         /* tints the native controls */

.card .primary-button {
  background: AccentColor;               /* the SAME hotpink, from CSS */
  color: AccentColorText;                /* UA-guaranteed contrast     */
}

/* derived palette — AccentColor is a real <color>, so it composes */
.card .tint { background: color-mix(in srgb, AccentColor 15%, white); }

With accent-color: auto (the initial value) AccentColor still reflects the UA/OS accent, and in forced-colors mode the forced palette wins — the keywords never fight the user.

references