[css-color-adjust-1][mediaqueries-5] Fold `forced-colors` and `prefers-contrast`?

[fantasai]

Was trying to work out authoring advice for responding to forced-colors mode and drafted up

Authors are encouraged to simplify the contrast in their pages when '@media/forced-colors' is ''active'', reducing effects such as shadows, fades, blurs, filters, gradients, and image or pattern fills that add complexity to discerning shape outlines.

But what I noticed is that this advice is probably also applicable any time (prefers-contrast) is true (i.e. when it is low or high but not no-preference). Which made me wonder if forced-colors: active should instead be prefers-contrast: forced?

[fantasai]

More info on forced colors mode, for anyone who's dropping into the issue without context: discussion in #3807 on MSFT proposal yielding current spec text.

[fantasai]

Wondering also how (prefers-reduced-transparency) plays into this... Transparency effects, pattern fills, and bad contrast all interfere with shape recognition.

Basically, I think it'd be nice if authors could have very clear triggers for when to make what adjustments, and if we could make those triggers as simple and straightforward as possible as media queries, and incorporate that authoring advice into the spec.

[AmeliaBR]

I don't think we should be confusing forced-colors and prefers-contrast at all. If there is authoring advice that is specific to creating good contrast, it should go under the prefers-contrast MQ. A forced-color setting (as currently defined) is going to turn off text shadows and block out busy backgrounds behind text, anyway, so I'm not sure why this extra advice is necessary.

Now, it may make sense to combine prefers-reduced-transparency and prefers-contrast. But then, I'm not quite sure who's asking for the reduced transparency case — the MacOS no-transparency setting is as much a performance option as it is an accessibility one.

I do think web browsers should automatically update the prefers-contrast state automatically if they can correctly deduce that the forced color scheme is high/low contrast.

("correctly" being the key point. WHCM can't even figure out if my custom color scheme is dark-on-light or light-on-dark & doesn't give me any way to specify it — it's a hidden setting based on whichever built-in color scheme you started with before you customized it. grumble grumble grouch…)

Basically, I think it'd be nice if authors could have very clear triggers for when to make what adjustments,

This, I very much agree with.

[fantasai]

I believe this is WONTFIX due to Web-compat at this point regardless of any merits the proposal may have had last year. :/ Agenda+ to check.

[fantasai]

I suppose we could add prefers-contrast: forced, if we do think that's a good idea; we just can't remove forced-color: active (due to webcompat).

[css-meeting-bot]

The CSS Working Group just discussed [css-color-adjust-1][mediaqueries-5] Fold `forced-colors` and `prefers-contrast`?, and agreed to the following:

• RESOLVED: add the forced value to prefers-contrast

The full IRC log of that discussion

<dael> Topic: [css-color-adjust-1][mediaqueries-5] Fold `forced-colors` and `prefers-contrast`?
<dael> github: https://github.com//issues/3856
<dael> fantasai: I think we're not going to fold them b/c due to web compat we need to keep forced color MQ.
<dael> fantasai: Could add it to trigger when forced-colors is active so you can know if there is a contrast requirement in place.
<dael> emilio: Who ships prefers-contrast? MS?
<dael> Rossen_: yes
<dael> florian: Not convinced this can work. With prefers you're supposed to pick. With forced it's done for you. Knowing something is changed doesn't tell you want to do
<Rossen_> q?
<dael> fantasai: People will likely want to not use gradients or other content layering. Pull back effects with visual complexity. Those changes which aren't colors are things you'd want with low, high and forced contrast
<dael> Rossen_: Synergy between forced-colors and the other prefer properties makes sense for same reason we made initial change for prefers color scheme. Seems reasonable based on forced-color mode people can allow the effect of forced-colors on large parts of content while providing reasonable experience either for contrast or adjust for appropriate color scheme.
<AmeliaBR> q+
<fantasai> I'm suggesting we make @media (prefers-contrast) { ... } handle high, low, and forced contrast mods
<fantasai> s/mods/modes/
<dael> Rossen_: I would argue for this change for similar reasons fantasai pointed out but also to underline that being able to escape large parts of content and do your own thing is important for this feature.
<dael> Rossen_: I think the current contrast hint is missing here and if people do more with prefers-contrast this is a nice addition
<dael> AmeliaBR: I would argue opposite. Important to keep independent. Forced-color mode can force low-contrast. It' snot common. If we treat forced as prefers-contrast people will assume it means high contrast when it's not true. Keeping them independent options recognizes it's more
<florian> I started skeptical, but I now support the proposal
<dael> fantasai: prefers-contrast also can ack. low contrast. forced-colors says I want a particular contrast. Adding it to prefers-contrast add a preference be it high or low. That's why I think it's appropriate.
<dael> AmeliaBR: How works in authoring boolean perspective? Forced-colors is independent and media prefers-content doesn't match?
<fantasai> https://drafts.csswg.org/mediaqueries-5/#prefers-contrast
<dael> fantasai: We add a kewyrod of forced to prefers-contrast. If you use it without anything it means you have a preference be it high or low and the author should respond
<fantasai> prefers-contrast: no-preference | high | low
<fantasai> proposed to make that
<fantasai> prefers-contrast: no-preference | high | low | forced
<dael> florian: Author you can query to prefers-contrast high o prefers-contrast forced and with forced you can reduce visual complexity
<dael> AmeliaBR: With that I'm okay with prop. Need clear authoring guidance to not assume it's in a specific direction
<dael> astearns: I'm hearing support
<dael> astearns: Obj to add the forced value to prefers-contrast?
<AmeliaBR> s/it's/the preference is/
<fantasai> The fact that 'low' and 'high' both exist as values makes that pretty obvious imho
<dael> RESOLVED: add the forced value to prefers-contrast

[cookiecrook]

How is prefers-contrast intended to work on macOS or iOS, which have neither a forced colors mode nor a “high” contrast mode?

See more in #2943.