[css-color-4] system colors when NOT forced-colors:active

[BillGoldstein]

I've been doing some testing of system colors when NOT forced-colors:active, and have a few ideas:

1. UA's should use dark color (black-ish) for Canvas, and light color (white-ish) for CanvasText, when prefers-color-scheme:dark
2. UA's should use colors with sufficient contrast for LinkText, VisitedText, and ActiveText, lighter in dark mode, darker when not in dark mode

[AmeliaBR]

I agree, and was suprised to find that our current spec text for system colors only talks about forced color mode. The system colors are also useful for light/dark theming.

Do you have more details about your test results? Which browsers are not updating the used values for their System Color keywords to match their default styles when dark mode is active?

[BillGoldstein]

Tested with Chromium, and Gecko (with an autoland build with new system color support - it's been backed out for now).
Neither adjusted Canvas / CanvasText in dark mode.
Same for LinkText / VisitedText / ActiveText. They have less than WCAG-specified contrast ratios even in light mode, but it's worse in dark mode.

[AmeliaBR]

Agenda+ to confirm that the intention is that system colors will adapt to the used color scheme, whether it is forced or not. And to find out if there are implementation obstacles to make this so.

Note that the resolution to #4608 (comment) implies that system color values will adjust to color scheme

I'd also want a resolution that User Agent stylesheets should use system colors, so that an HTML file with a <meta name="color-scheme" content="dark"> command is readable by default if CSS doesn't load.

We already have text about using “legible” pairs of colors in the default browser/system color schemes, although I'd prefer a more explicit requirement for WCAG AA contrast, unless the colors are user-selected.

[lilles]

The css-color-adjust spec[1] says in a couple of places that system colors are affected by the used color-scheme.

Safari ships color-scheme dependent system colors. In Chrome it's currently behind the same runtime flag as for dark themed forms (--enable-blink-features=CSSColorSchemeUARendering).

[1] https://drafts.csswg.org/css-color-adjust-1/#preferred

[BillGoldstein]

I agree with AmeliaBR about the WCAG AA 4.5:1 contrast ratio requirement for legible "pairs"...as default.

Later, when implementing https://drafts.csswg.org/mediaqueries-5/#prefers-contrast:

when @prefers-contrast:high (or "increased") applies, use WCAG AAA 7:1 contrast ratio,
when @prefers-contrast:no-preference, keep using the WCAG AA 4.5:1 contrast ratio,
when @prefers-contrast:low applies, use WCAG's 3:1 minimum contrast ratio.
@prefers-contrast "extremely high" could use maximum possible contrast.

An example of what it might look like: https://codepen.io/a-ja/pen/qBdwEoq

[css-meeting-bot]

The CSS Working Group just discussed [css-color-4] system colors when NOT forced-colors:active, and agreed to the following:

• RESOLVED: The system colors should have meaning outside of forced-colors and reflect dark and light mode changes
• RESOLVED: Requirement on legible background/foreground colors should be made a should to reflecting WCAGcontrast ratio but with exception that it only applies when browser generates default colors
• RESOLVED: Add to previous resolution that user contrast preference must take precedence

The full IRC log of that discussion

<dael> Topic: [css-color-4] system colors when NOT forced-colors:active
<dael> github: https://github.com//issues/4883
<dael> AmeliaBR: Color adjust spec is written many places where implies system colors are also dynamic for dark and light mode.
<dael> AmeliaBR: Definition in color spec only talks about forced-color mode. Suggestion is to make it clearer in the spec that system colors hsould be tied to dark/light mode differences. Also make sure UA default stylesheet likewise flip when you turn on dark mode default style should be decent for dark mode
<AmeliaBR> https://github.com//issues/4924
<dael> AmeliaBR: Couple other issues here and in HTML in last week on topic of improving UA stylehseet. That's the tracking issue ^
<dael> AmeliaBR: From feedback we did get I think...there isn't any impl reason not to do this. It just hasn't happened to go through and connect system-color system and UA stylesheets with light/dark mode system
<dael> AmeliaBR: Right now big problem where if you use meta tag to set dark but CSS doesn't load you get unreadable page with black canvas and defautl black text from UA stylesheet. UA stylesheet should be basic legible in light or dark mode
<Rossen_> q?
<aja> implication of issue is that those system color "pairs" be wcag2.1 AA by default. AAA when prefers-contrast:high would be a plus, too.
<chris> q+
<dael> AmeliaBR: Other discussion is should we require UA stylehseets to match WCAG contrast ratios. Might be separate issue to discuss with HTML, but it is related since right now default contrast is horrible
<smfr> q+
<Rossen_> ack chris
<aja> lower contrast when prefers-contrast:low too
<dael> chris: I think we hsould put WCAG requirements on these. Color 4 jsut says readable but no requirements. I edited to add examples. I'd like to require AA for all apart from gray text. I think that's right thing to do.
<Rossen_> ack smfr
<dael> smfr: We've had bugs in WK in dark mode because blue link is too dark. Is color 3 the system color list? I don't see link-color.
<dael> TabAtkins: Color 3
<dael> chris: System color and default stylesheet at in Color 4
<TabAtkins> s/Color 3/Color 4/
<fantasai> https://drafts.csswg.org/css-color-4/#css-system-colors
<dael> chris: In color 3 all system colors said deprecated and in 4 it said "no, things depend on these"
<dael> TabAtkins: They're in named colors in Color 4, smfr
<Rossen_> q?
<dael> smfr: Thanks
<dael> AmeliaBR: As far aswhat changes are needed: 1) Colors 4 introductory text that desc system colors should make it clear that it isn't just about forced-colors mode
<dael> AmeliaBR: Make it clear they should adjust to color modes
<AmeliaBR> https://drafts.csswg.org/css-color-4/#css-system-colors
<dael> Rossen_: Is that referring to the second paragraph of section 2.2?
<dael> Rossen_: "When forced colors media features is evaluated to active"
<dbaron> So if the colors come from system settings, and the system settings aren't WCAG AA compliant, what happens?
<dael> AmeliaBR: Expand 6.2 to make it clear system colors are relevent all the time, not just forced-colors. Spec req for forced-colors are still true. As far as defining what system-colors mean we need expectation on UAs to respond to color scheme.
<dael> Rossen_: Okay
<dael> AmeliaBR: 2) Text that says following pairing expected to be legible. Proposed is update to reference WCAG contrast ratios
<dael> AmeliaBR: 3) Update UA stylehseets to actually use system-colors. That's a larger discussion going on in the other issue.
<Rossen_> david?
<dbaron> I'm talking into a very unmuted mic, on the �phone�
<dbaron> so webex doesn't work
<dbaron> just read my IRC above
<dael> dbaron: Requirements about WCAG AA compliant what if they come from system settings and the user has customized and they're not compliant. SHould browser detect and fix?
<dael> AmeliaBR: I would say no. User has priority. Spec mention should be about browser defaults should be compliant.
<dael> florian: Browser defaults defer to OS and broswer can't know if it's because OS is bad or user wanted it.
<dael> Rossen_: I think it would be difficult to impose WCAG restrictions on system colors
<Rossen_> ack dbaron
<dael> fantasai: If we want to reference WCAG it should be informational not normative
<aja> dbaron, re: what happens if non-AA values from forced theme, i say honor theme's choice (i.e. user's choices). just be magic-valued system colors when NOT forced
<chris> Q+
<chris> q+
<dael> dbaron: Other thing I would note is I dug into system colors heavily in 2002 and proposed a bunch than. A buch of that was foreground-background pairs b/c not clear what's meant to be used together. The pairs was to make sure that these two colors are used as a pair in the system UI so that you're using colors meant to go together.
<dael> AmeliaBR: Good point.
<dael> AmeliaBR: One of the things that's changed in spec is clearly ID the pairs. You're right that also has to happen in UI. As someone that's played with Windows high contrast they do have clear pairs that don't get used together with Windows OS settings. Easy to mess things up
<dael> AmeliaBR: As far as what CSS can do is we can try to put guidance so authors have something to go on and hopefully they match up with browsers and OSs
<Rossen_> ack chris
<dael> chris: Asking about WCAG. Understand some is outside of browser and users can customize. At the same time I'm loathe to drop this opportunity. Maybe a SHOULD instead of a MUST. Now that we've IDed what pairs are required together I think we should say these should meet WCAG AA. Rossen_ can you explain objection more?
<dbaron> https://lists.w3.org/Archives/Public/www-archive/2013Aug/0027.html has a bit of the background of color pairs, in particular, how the CSS2 set of colors had some non-obvious pairs for which we needed to make a "Dialog" color to fix
<dael> Rossen_: Windows high contrast is about legibility and cognative overload. WE have a lot of cases where users choose low contrast so they can reduce cognative load. If you say this is not great colors who are you to say since this is user choice.
<dael> chris: Yes, try and differentiate OS and user. If user set it that's what they want and we should call that out explicitly
<dael> florian: THe way the user customized this is changing OS setting. Browser does what OS says. The should we might be able to have is by default OS should match. But we're writing browser requirements and the browser should do what the OS says. Browser doesn't know if OS has bad settings or if user set it.
<AmeliaBR> q?
<dael> fremy: Do browsers use system colors? I had impression Safari stopped using system colors. Maybe requirement can say if browser not using system colors it should match AA.
<dael> florian: Fair
<dael> Rossen_: One point we're circling around. Previous requirements were about forced-colors. THat's prop user choice. Regardless of if it came from OS or how it go to the browser and applied there's nothing we can require if this is user choice. System colors being reflective is valid
<dael> Rossen_: When forced-colors are not active it's fair as to if we can rec browsers improve
<dael> AmeliaBR: Good discussion taht reflects most browsers. The default UA stylesheet colors when not in forced-colors we can put an obligation to meet contrast requirements. With exception of when browser uses colors from outside browser or explicitly set by user you should respect that.
<dael> Rossen_: Given that, going back to 3 points, where do we still need to make changes?
<dael> Rossen_: Second change which is text says pairing have to be legible I think this is only when colors not reflecting user choice
<dael> AmeliaBR: First prop resolution: The system colors should have meaning outside of forced-colors and reflect dark and light mode changes
<fantasai> sgtm
<dael> Rossen_: Comments or objections?
<dael> RESOLVED: The system colors should have meaning outside of forced-colors and reflect dark and light mode changes
<dael> AmeliaBR: Second: Requirement on legible background/foreground colors should be made a should to reflecting wcag contrast ratio but with exception that it only applies when browser generates default colors
<dael> AmeliaBR: Does that cover discussion points?
<dael> Rossen_: Yep.
<dael> Rossen_: Objections?
<dael> RESOLVED: Requirement on legible background/foreground colors should be made a should to reflecting WCAGcontrast ratio but with exception that it only applies when browser generates default colors
<aja> and honor prefers-contrast user prefs if/when implemented?
<dael> AmeliaBR: Last: UA stylesheet rules should be updated to use system colors wherever possible. This may require new system colors.
<fremy> For Chrome: https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/layout/layout_theme.cc;drc=7bf6998a6433c26266180353473b5153ffab0517;bpv=1;bpt=1;l=752?q=css%20system%20colors
<fantasai> +1 to aja
<dael> TabAtkins: We should open that as a separate topic and resolve there.
<dael> Rossen_: Good point. And it's likely a larger discussion.
<fremy> q+
<dael> fantasai: Pointed out that system colors adhering to WCAG needs to account for preference of low contrast. Possible people who want low contrast we dont honor WCAG
<dael> AmeliaBR: Or if someone asks for high contrast system should bump to AAA
<dael> fantasai: Yeah
<dael> Rossen_: I think that's a change to previous resolution.
<fremy> For Chrome on Windows: https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/layout/layout_theme_win.cc;bpv=1;bpt=1;l=23
<dael> AmeliaBR: With adjustment for prefers-contrast setting if applicable
<aja> low still has 3:1 ratio minimum
<dael> Rossen_: Prop: User contrast preference must take precedence
<dael> Rossen_: Objections?
<Rossen_> ack fantasai
<Rossen_> ack fremy
<dael> RESOLVED: Add to previous resolution that user contrast preference must take precedence
<dael> fremy: Checked chrome source code, there's a default if they don't use system. My opinion is the one hard coded in code should meet the obligations. These colors exist and should conform to WCAG. Just pointing out I put the links
<dael> Rossen_: Remaining discussion will be in a different issue about how to reflect these to default UA stylesheet.
<dael> AmeliaBR: It's 4924

[svgeesus]

Added WCAG AA contrast requirement for matching pairs when browser generated