WPT details: There are no specific tests for this scoping fix. The underlying feature relies on the platform's accent color and necessitates a WebDriver extension to simulate the accent-color property accurately, making it difficult to test. However current WPT coverage for the underlying feature was not broken by this change. WPT tests listed for underlying feature: - https://wpt.fyi/results/css/css-ui/accent-color-parsing.html - https://wpt.fyi/results/css/css-ui/accent-color-computed.html - https://wpt.fyi/results/css/css-typed-om/the-stylepropertymap/properties/accent-color.html - https://wpt.fyi/results/css/css-ui/animation/accent-color-interpolation.html
Restricts access to the system accent color for CSS keywords and `accent-color: auto` to be only within a web app and initial profile context. AccentColor and AccentColorText CSS keywords, pose a significant fingerprinting vector when exposing the user's system colors widely on the web. As such, they're only available in installed web app contexts. Form controls with `accent-color: auto` also match this scope with this feature launch. This introduces more consistent developer and user expectations for system colors and aligns with fingerprinting restrictions for AccentColor[Text].
Currently, system accent color features have differing scopes of availability. While `AccentColor[Text]` is planned to only be available in installed web apps, `accent-color: auto` uses system accent color everywhere. This leads to confusing signaling on when developers can expect system accent colors to be available, as well as unintended accessibility and UX side effects as form controls adopt colors on web sites that developers didn't expect. Scoping system accent color availability to installed web apps all up will provide more consistency in this feature intended to allow more native app like styling, while adhering to the fingerprinting restrictions that `AccentColor[Text]` is planned to be subject to (must not be exposed outside of installed web apps).