[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 https://github.com/w3c/csswg-drafts/issues/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/w3c/csswg-drafts/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.

[cookiecrook]

Also, the WG minutes mention @AmeliaBR asked:

How [would forced value work] in authoring boolean perspective? Forced-colors is independent and media prefers-content doesn't match.

But I don’t see that question answered in the minutes. What was the response?

I have a boolean proposal in #2943 that I think could work across platforms, but adding forced might conflict, since that value is Windows-specific.

[AmeliaBR]

What was the response?

I turns out this was already sort of defined. Using @media (prefers-contrast) evaluates true for everything except no-preference, so it is true for high, low, and forced. So it is only useful as a trigger for turning off extra graphical effects.

Which doesn't prevent adding an increased option, but it does conflict with your proposal to have a Boolean mode that distinguishes high and increased from low and no-preference.

[AmeliaBR]

Something I thought about after the call:

The prefers-contrast: forced value reduces the information available to authors who want to customize content for forced colors mode, when browser styles won't be sufficient for that content (e.g., charts, syntax-highlighted code).

As the spec is currently defined, an author could identify that the browser is in forced colors mode, and then use a mix of the prefers-contrast and prefers-color-scheme to toggle between high-contrast, low-contrast, dark and light modes for that custom content, so that it best matches the forced-color scheme and the user's preference. Sample code:

/** pick a syntax scheme, these should cover all possible combinations **/
@import url(solarized-light.css) (prefers-contrast: low) AND (NOT (prefers-color-scheme: dark));
@import url(solarized-dark.css) (prefers-contrast: low) AND (prefers-color-scheme: dark);
@import url(high-contrast-light.css) (NOT (prefers-contrast: low)) AND (prefers-color-scheme: light);
@import url(high-contrast-dark.css) (NOT (prefers-contrast: low)) AND (NOT (prefers-color-scheme: light));

code.highlight {
  forced-color-adjust: none;
  /* always use the syntax highlighting colors for highlighted code */
}

With prefers-contrast: forced, there is no information about what the user prefers if the forced colors aren't sufficient.

One option would be to treat the query values as non-exclusive categories. So both prefers-contrast: forced and prefers-contrast: high could match at the same time. But that just seems like an unnecessary duplication of the forced-colors: active query.

So maybe a better compromise would be to add a prefers-contrast: other value, instead of forced. This would be used if the user agent is in forced color mode, but the forced color mode cannot be clearly defined as either high or low contrast. It would still evaluate true for the Boolean query (if the author is really just interested in knowing if there is a user preference without caring what it is), but would not replace the useful information from prefers-contrast: high and prefers-contrast: low.

[cookiecrook]

I think it would be problematic to have @media (prefers-contrast) match the low value, as this is the opposite of what most authors would intend...

[cookiecrook]

Also, as there is no existing native implementation of a low contrast feature that I am aware of, in what scenario would any browser match @media (prefers-contrast: low)?

[fantasai]

I think it would be problematic to have @media (prefers-contrast) match the low value, as this is the opposite of what most authors would intend...

If the author wants to evaluate against high contrast, they can write @media (prefers-contrast: high). @media (prefers-contrast) literally says "there is a preferred contrast", evaluating to true for low, high, and forced constrast preferencese makes sense afaict.

[cookiecrook]

That negates the usefulness of this feature, since @media (prefers-contrast: high) should never match on iOS or macOS.

Update to clarify. In my original proposal for this contrast media feature, the goal was to make the authoring syntax boolean 99% of the time, as simple as possible...

@media (prefers-contrast) { }

But by folding forced colors and low contrast into the boolean match, now the simplest correct syntax for the most common scenario is this:

@media (prefers-contrast: high) or (prefers-contrast: increase) { }

And it's now much more likely that an author will forget one or the other, which excludes entire platforms...

[cookiecrook]

Using @media (prefers-contrast) evaluates true for everything except no-preference

I understand this, and I was heavily involved in defining this behavior with prefers-reduced-motion in order to keep the syntax flexible. (E.g. it could also match something more specific in the future if needed like no-parallax).

The no-preference boolean behavior also worked well with the original proposal for contrast, which was:

prefers-increased-contrast: [no-preference] | increase | high

But now with name change and the addition of low and forced a boolean match for @media (prefers contrast) can also mean:

• low, aka “does not prefer contrast”
• forced, which is not conveying a preference for the author to style but a state that the author is forced to deal with and should react to.

IMO, forced-colors is a much better landing spot and naming convention for this concept.

[emilio]

Should (prefers-contrast: forced) match alongside some other prefers-contrast value? Or only one at a time?

[cookiecrook]

Microsofts proprietary media features for this were non-exclusive... For example, they could specify both high contrast and forced colors individually: high contrast black-on-white vs high contrast white-on-black among more.

[fuzzbomb]

So maybe a better compromise would be to add a prefers-contrast: other value, instead of forced. This would be used if the user agent is in forced color mode, but the forced color mode cannot be clearly defined as either high or low contrast.

That's a good description of what Windows High-Contrast mode allows users to do. The actual colours aren't always an extremely high contrast. The pre-set colour palettes provided all have very high-contrast, but the feature allows users to specify their own palette. So it's possible to use Windows "high-contrast" mode to specify your own very low contrast palettes. Light brown on beige, for example.

[cookiecrook]

All the more reason to keep the forced-colors feature separate from the contrast-related media feature.

[fantasai]

@cookiecrook Your example in https://github.com/w3c/csswg-drafts/issues/3856#issuecomment-642313572 doesn't work because you're assuming that (prefers-contrast) only matches high or increased contrast modes, but in fact it also matches low contrast modes. So I don't really understand why you think that adding forced to the possible values is problematic: whether we add it or not, (prefers-contrast) on its own already can't tell you whether the user wants high contrast or not.

[cookiecrook]

@fantasai wrote:

Your example in #3856 (comment) doesn't work because you're assuming that (prefers-contrast) only matches high or increased contrast modes, but in fact it also matches low contrast modes.

The spec proposes low, but when would it ever match? It's a theoretical value that's not associated with any real user preference; there is no "low contrast" switch on any common operating system. I proposed in #2943 that the "low" value be removed since it's not implementable.

Meanwhile, macOS and iOS both have a "non-high-contrast-but-increased-contrast" mode (first shipped in iOS 7, over 8 years ago) that the CSS MQ5 spec does not account for. If those platforms ever ship a true "high" contrast mode, the current syntax of the media feature would become incompatible, because it doesn't allow that future flexibility. Adding forced colors into the mix makes the authoring syntax even more complicated.

The preferable, simple boolean:

@media (prefers-contrast) { }

Would become this at minimum:

@media (prefers-contrast: high) or (prefers-contrast: increase) { }

I don't think the most common use case should be so verbose.

We're crossing into the other issue a bit, so instead of going into more detail here, I'll point across to the proposal in https://github.com/w3c/csswg-drafts/issues/2943#issuecomment-599751283.

[alisonmaher]

@fantasai Is there any reason we shouldn't map to high or low in forced colors mode depending on the contrast level between the foreground and background colors rather than adding a new forced value? This would be similar to how we determine if we should map prefers-color-scheme to light or dark depending on the luminance of Canvas: https://drafts.csswg.org/css-color-adjust-1/#forced.

[fuzzbomb]

One benefit of keeping prefers-contrast and forced-colors separate, is that authors have different responsibilities when supporting them....

• prefers-contrast: the user wants higher or lower contrast, but is happy for the website to choose the actual colours. As an author, I need to support that by providing a different palette, and perhaps other things like strong borders for buttons. I can keep the colour palette on-brand, so long as it respects the request for contrast levels.
• forced-colors: the user wants their own colours. As an author, I shouldn't be messing about with colour here; instead, I should make sure my content doesn't break because it relies on a property which has been reverted.

To me, that's a useful distinction, because it provides direction about how I can best help the user.

[frivoal]

Meanwhile, macOS and iOS both have a "non-high-contrast-but-increased-contrast" mode (first shipped in iOS 7, over 8 years ago) that the CSS MQ5 spec does not account for.

I don't understand why you consider that this increased contrast node should not match @media (prefers-contrast: high)

The definition is:

Indicates that user has notified the system that they prefer an interface that has a higher level of contrast.

Seems to me it would be perfectly fine for the macOS/iOS mode to match that, and I am not quite sure what difference you seen between "increased contrast" and "a higher level of contrast". Could you explain a bit more?

[cookiecrook]

Default contrast (exists today)

Increased Contrast (exists today, and what @frivoal and @fantasai are suggesting the high value should match)

High Contrast (this is a 2m crummy comp, not an existing view) similar to Windows HC mode.

[cookiecrook]

@frivoal wrote:

Seems to me it would be perfectly fine for the macOS/iOS mode to match [high]

See the full discussion in #2943

[frivoal]

As @cookiecrook noted in a https://github.com/w3c/csswg-drafts/issues/3856#issuecomment-655806870 or https://github.com/w3c/csswg-drafts/issues/3856#issuecomment-662030770, the scope of this issue is overflowing into a related but distinct topic. The question asked by @fantasai initially has been resolved on, and I've made the edits, so I am closing this issue.

For discussion of whether the high value of prefers-contrast is appropriate for what macOS does or whether we need a separate one, see #2943

Some comments have also suggested that maybe @media (prefers-contrast) {...} should evaluate to true even when none of the existing values (low, high, and now forced) evaluate to true. Either this is because we'd add increased and remove low (and now forced), in which case this fits into #2943, or this goes against the definition of Evaluating Media Features in a Boolean Context, and should be raised separately.

If, as a result of these discussions, we end up changing how this media feature works, we may end up deciding to reopen this issue. But it seems to me that quite a few points that @cookiecrook makes here assume that #2943 will be resolved in the direction he proposes, while the resolution that was recorded here assumes currently specified behavior.

This is not an attempt to stifle discussion, but to consolidate each topic in their respective issue, and hopefully make the discussion easier to follow.

[michael-n-cooper]

@cookiecrook APA wants to know if you're ok with the disposition of this comment.

[cookiecrook]

This issue is closed as resolved (and already merged), but I've opened the remaining issue in #5433. Also, the adjacent prefers-contrast value syntax issue mentioned here has been adequately resolved in #2943.