WPT details: https://wpt.fyi/results/forced-colors-mode/accent-color-keyword-forced-colors.html?label=master&label=experimental&aligned https://wpt.fyi/results/css/css-ui/accent-color-keyword-animation.html?label=master&label=experimental&aligned https://wpt.fyi/results/css/css-ui/accent-color-keyword-cyclic.html?label=master&label=experimental&aligned https://wpt.fyi/results/css/css-ui/accent-color-keyword-resolution.html?label=experimental&label=master&aligned https://wpt.fyi/results/css/css-ui/accent-color-text-keyword-resolution.html?label=experimental&label=master&aligned Note: the broader `forced-colors-mode` WPT suite covers substantially more than `AccentColor` and `AccentColorText`, so existing Blink failures in that directory are not specific to this feature. Dedicated WPT coverage for this change has now landed, but these tests are expected to fail until the dependent implementation change ships.
`AccentColor` and `AccentColorText` reflect the element's effective `accent-color` value instead of only platform-provided system accent colors. This allows CSS to reference the same colors used by `accent-color` styling, making it easier to keep custom styling consistent with form controls and other accented UI. It aligns Chromium's behavior with the CSS Color Module Level 4 specification.
Currently, `AccentColor` and `AccentColorText` keywords have been implemented in a limited capacity for Chromium. They reflect the OS' chosen system accent color when `accent-color` is set to `auto` and return a default value otherwise. The CSSWG resolved that the keywords should reflect the value of `accent-color`, allowing developers to use the keywords for intuitive styling of elements. Without this change, the keywords provide no additional value unless being used specifically for a system accent color.
Samples: https://kyerebo.github.io/demos/system-accent-color/index.html