I misunderstood the proposal in the CSS call. I thought @tabatkins proposed removing the prefers-contrast feature entirely. I don't have a strong objection to removing the boolean match, since the explicit value matches will remain for the feature. That said, there may be some value to keeping it. See next comment.

If am I understanding the reduced-colors proposal correctly, we may come to the same disagreement about whether there is a correlation between "non more/less contrast but forced colors" and a desire for reduced visual complexity.

For example, I would have suggested something closer to prefers-reduced-complexity matching (prefers-contrast) or (prefers-reduced-transparency) but NOT (forced-colors), because the force color scenarios that would need reduced complexity would already match either more or less contrast...

All forced colors scenarios do require reduced color complexity, and I would be happy to try to convince you of that :)

First, a technical reason:

Because you only have a handful of colors at your disposal, all types of gradients and box shadows are out, irrespective of the colors that the user chose for the theme.

Secondly, a practical use case:

To give you an idea of what a fully-fleshed forced-colors mode that is not high contrast can result into, here is for instance what Outlook looks like using a "Reduced complexity (light blue)" theme, whose purpose is to limit color usage on the screen, and have all "interactive things" be blue, so that it is easy to see at a glance what is clickable on an user interface:

As you can see, while this theme I presented does not match a "high contrast" criteria because of the dark on light gray, achieving this end result still required a reduced color complexity, for things to work properly.

Just in case this needs some context, this is what a page looks like in this forced-colors mode versus not:

As your can see, irrespective of the choice of colors, the use of gradients and visual complexity has been reduced, to achieve the desired effect.

To summarize, forced-colors is not a "theme" feature, it is an accessibility feature, aimed at making user interfaces easier to use by reducing their reading complexity, through the enforcement of a reduced color palette with semantic meaning. For most people this will pair favorably with a high-contrast theme, but for some it might simply mean a sharply reduced color palette, or even a lower contrast, due to particular eye strain sensitivity.

we may come to the same disagreement about whether there is a correlation between "non more/less contrast but forced colors" and a desire for reduced visual complexity.

@fantasai made the argument very well during the meeting that these two concepts correlate by definition: whether you prefer high-contrast, low-contrast, or have a forced color scheme, you are reducing the available space of colors for the page to use. Low-contrast wants the page to more closely-clustered colors, avoiding extremes from using colors far apart in color space; high-contrast wants the opposite, using more extreme colors and avoiding closely-clumped ones; forced-colors gives you about a dozen colors total that you are allowed to use.

In all these cases, because your available set of colors is reduced, you usually want to reduce visual complexity.

• In high-contrast, subtle gradients and shadows are the precise opposite of what the user is asking for; the page should use simpler color blocks and borders to indicate visual hierarchy more obviously instead.
• Low-contrast is typically also associated with a desire for simpler pages, from what I understand of the a11y needs underlying it; it's typically a sensory-processing issue, and again, simpler, plainer visual hierarchy can usually serve their needs better. Even ignoring that, just the fact that you have a narrower band of colors to work with means you can't rely on having as many distinguishable color/lightness levels, and must instead design your page to indicate hierarchy and importance in ways that don't rely as much on color.
• And finally, in forced-colors you simply don't have many colors to play with, and you don't know what they are anyway, so you can't usefully counterpoint them; again, a simpler visual hierarchy is the obvious way to work around the limitations you're saddled with.

Several of us have repeatedly made this argument, and even provided rendering examples showing off the issues we're talking about. It's felt as if your responses have mostly been "I disagree", which has proven frustrating; there's nothing we can discuss there.

because the force color scenarios that would need reduced complexity would already match either more or less contrast...

I don't understand what forced-colors scenario could possibly not want reduced visual complexity. Forced colors needs reduced visual complexity because the colors are forced and from a small palette - the actual identity of the colors doesn't factor into this at all, as far as we can tell. Can you give an example of a forced-colors palette that you think would not benefit from reduced visual complexity (or rather, that wouldn't be harmed by leaving a reasonably-high visual complexity page alone while applying the forced colors), but would if we tweaked the colors to be higher or lower contrast?

@FremyCompany

Because of this, I suggest we drop (prefers-contrast) as a boolean flag, while keeping both (prefers-contrast: more) and (prefers-contrast: less)

This isn't possible without doing some bizarre special-casing. Every media query matches in boolean form, based solely on whether at least one non-nil value matches. Without a very good reason to break from this simple generic rule, I'm not okay with adding odd special cases.

@FremyCompany for the reason given by @tabatkins in the previous comment, I don't think removing the booleanness of the feature is likely to be what we want to do here.

That said:

• The "reduced complexity" use case is now discussed under both (prefers-contrast) (used in boolean form) and forced-colors. Maybe some massaging of the examples could make this better? Suggestions on this front appreciated.

• Adding a new reduced-colors (or reduced-complexity) query might be the path forward, but I'd like to be careful about this: there might be quite a few factorings of existing queries that could be useful queries on their own, and I don't think we want to add many of those, as it eventually gets complicated for authors to know what's what. If we need lots of these, that feels like a sign we didn't quite land on the right design.

I have no problems with a media feature as specific as “reduced color complexity”… If that’s all we’re talking about, I think it’s clear, and I agree with the assessment that forced colors necessitates a reduced amount of color complexity.

The prior disagreement may have been another vocabulary ambiguity. In the accessibility space “simplification” or “reduced complexity” often refers to both visual and functional interface changes, sometimes in the context of developmental disability. Even if we limit the scope to reducing visual complexity (slightly broader term than color complexity), we get into needs that include distractability, as with autism or ADD. The use cases are not limited to vision disabilities.

I remain unconvinced that forced colors is a 1:1 correlation with my understanding of the broader terms “reduced complexity” or “reduced visual complexity.” However, I agree with @FremyCompany et al that it’s a 1:1 correlation with “reduced color complexity.”

However, I agree with @FremyCompany et al that it’s a 1:1 correlation with “reduced color complexity.”

@cookiecrook Ok, if we agree on that, could you explain a bit what kind of styling you expect authors to write under the
@media (prefers-contrast) { … } other than "reduced color complexity"? (specifically talking about prefers-contrast without an explicit value).

One other option could be to have forced colors mode always map to a more or less value for prefers-contrast. Currently @alisonmaher's experimental implementation has > 7:1 mapping to more and < 2.5:1 mapping to less. Per #5224, the WG has thus far chosen not to be prescriptive on what the thresholds are - having a single threshold would allow for the desired usage of (prefers-contrast) as a boolean.

So this perhaps comes down to a question of what styles an author might apply via prefers-contrast (other than 'reduce visual/color complexity') that would have an effect in forced colors mode. If it is a limited set that wouldn't be harmful for users in this 'middle' band of forced colors, then maybe this is a path forwards. From my understanding current guidance is for authors or design systems to use prefers-contrast: less and prefers-contrast: more as a signal to how color palettes are selected which would be overridden when in forced colors mode.

@dlibby- This sounds like a good proposal overall. I guess Forced Colors can map to more contrast by default (if only for the effect of the reduced palette and back plate) until the colors get really close,where the behavior switches to less contrast; therefore setting the boundary so that one of either is always active. I like that proposal I must say.

@tabatkins @cookiecrook @fantasai - any thoughts on having prefers-contrast always evaluate as more or less in forced colors mode?

Having @media (prefers-contrast) (without explicit value) match when you're in forced color mode despite not picking a particularly low nor high contrast is precisely what we were pushing for in #5433, and got overruled about.

If we're having second thoughts about that—because we do agree after all that forced colors does imply reduced color complexity, and that it is appropriate for all cases of forced colors to match @media (prefers-contrast)—I'd rather go back to the earlier design (which is to have one more value of prefers-contrast that matches forced colors that are neither particularly low nor high contrast), rather than pretend mid-contrast things are high contrast. For @media (prefers-contrast) without an explicit value, it would make no difference, but it would avoid having to misleadingly claim a “more contrast” preference that isn't real.

For me, this issue comes down to whether or not the range between more and less is considered a valid contrast preference. Depending on the answer to this, we can narrow down potential options for a path forward.

If we agree that the range in between more and less is NOT a valid contrast preference, then we should not add back forced. This leaves us with the following options:

1. Leave everything as-is (i.e. don’t add any new media queries or new keywords to prefers-contrast).
2. Look into adding a new media query to encapsulate the various intersections of existing media queries (forced-colors, prefers-contrast, etc.) similar to what is being suggested here by @FremyCompany .

If we agree, however, that the range in between more and less represents a valid contrast preference, we have the following options:

1. Add a third value (name TBD) that strictly represents the contrast range between more and less.
2. Adjust the cut-off between more and less, similar to what @dlibby- mentioned in [mediaqueries-5] Remove (prefers-contrast) as a boolean, and replaced by a new color reduction media query #6036 (comment), to ensure that the two values cover all possible ranges of contrast ratios.
3. Add back forced to capture users who lie in the middle range in forced colors mode.

If we were to add prefers-contrast: forced, I think that we would also need to add prefers-color-scheme: forced for consistency, since both are affected by forced colors mode. This would add even more confusion for authors. For this reason and for the various reasons outlined in #5433, my preference in this case would be for option 1 or 2.

And as a note, we'd like to ship prefers-contrast to better serve users with a contrast preference on non-Windows platforms, but we'd like to get clarity on this issue before proceeding given that there is still a divide on the best path forward.

Reading and thinking through this again, I realize that my main objection in #5433 was specifically about the forced value - it seems confusing to authors, is redundant with forced-colors: active, and it is unclear what action they should take. However, to the extent that forced colors maps to a contrast preference on the extremes, it seems to logically follow that it should also map to a contrast preference for a forced color scheme that is not particularly high nor low contrast.

Proposal: add a middle value to prefers-contrast (following @alisonmaher's suggestion above), which would match when the less and more thresholds are not exceeded in forced colors. This also allows for the expression of a user saying they prefer neither high nor low contrast (assuming some eventual UI affordance would expose this), which is different than having no preference.

@cookiecrook would you have any objections to adding a middle value?

@tabatkins @frivoal - any further thoughts on this?

Agenda+ to discuss the most recent proposals.

And I will be out the second half of next week (5/26), so proposing this for the agenda for the week of 6/2. (CC: @cookiecrook to see if that timing would work well for you, too.)

@dlibby- wrote:

@cookiecrook would you have any objections to adding a middle value?

If I'm understanding correctly this would match when "forced" colors is either:

• inactive (e.g. Windows default)
• unavailable (e.g. Mac)
• active near a default contrast threshold matching neither more nor less.

If so, I have no objections other than the suggestion that this be called no-preference to match similar media features. There is no discernible preference related to contrast so the other prefers-color-scheme and forced-colors media features would give the author sufficient opportunity to respond.

However, if the intention of the middle value is limited to matching forced colors that are neither more nor less, then it seems like this is a renaming of the forced value that was already discussed in #5433.

I will attend the discussion in case I am missing something.

@alisonmaher wrote:

…agenda for the week of 6/2. (CC: @cookiecrook to see if that timing would work well for you, too.)

Yes, today works. Sorry for the late reply.

@cookiecrook There is already a no-preference value for prefers-contrast. The intention of middle would be for users who have a contrast preference that is neither more or less. (It would not match if forced colors mode or any other contrast preference were not enabled).

Currently, it would only be possible to match middle in Windows High Contrast Mode, but adding a middle value would allow extensibility for any hypothetical features that may allow a contrast preference that falls in the middle range in the future.

And adding middle would be different than adding back forced since forced matched in forced colors mode, no matter what the contrast ratio was, whereas middle would only match for forced color schemes with ratios between more and less.

The CSS Working Group just discussed [mediaqueries-5] Remove (prefers-contrast) as a boolean, and replaced by a new color reduction media query, and agreed to the following:

• RESOLVED: Add 'custom' property for defined color schemes that are not high or low

The pair of screenshots given by @FremyCompany in #6036 (comment) is great for illustrating the situation:

I'd like to include it as an example in the spec to illustrate a realistic usecase and the corresponding styling choices. However, these images are of a real web site, and include someone's brand (Microsoft Edge). Is that considered inappropriate content for a spec and I should created an unbranded equivalent, or is it fine as is?

cc: @astearns @atanassov

@cookiecrook, does this custom value work for you?

If I understand correctly, custom is a renaming of the middle value from the June 2 meeting? If so, that seems fine.

Update: I reread the minutes from that meeting and my recollection was confirmed.

The custom value would NOT match anything on the Apple platforms atm, because it is mainly a consolation for the rare Windows forced color configuration that matches neither more nor less contrast.

My arguments against the new value were that 1) it was ambiguous what authors should do with this match, and 2) it was only circumstantially associated with contrast. However, I didn’t feel strongly enough to file an objection, so the CSS WG consensus was to accept the custom value. Mostly harmless AFAICT, so no serious concern.

Thanks for double-checking @hober.