[mediaqueries-5] prefers-contrast: high media feature doesn't account for macOS and iOS

[cookiecrook]

[mediaqueries-5] prefers-contrast: high media feature does not accurately describe the macOS/iOS state

https://drafts.csswg.org/mediaqueries-5/#prefers-contrast

Unlike Microsoft's "high contrast" mode, the "Increased Contrast" settings on macOS and iOS do not result in "high" contrast, but an intermediate "increased" value. It's possible that a future update to these and other systems would allow a user-end "high" contrast value in addition to the current implementation of "increased" contrast.

The media feature should account for values other than "high" and "low." Ideally there'd be a shorthand way to match both the macOS/iOS value, or the extreme end value used by Microsoft.

[cookiecrook]

A few possible variants to solve this:

1. Perhaps a numeric value, 0-100 where 50 is the default (or -100-100, where 0 is the default). There could be named values too. e.g. high = 100, increase = 60? The queries could include a greater-than/less-than (</>) syntax such as:

@media (prefers-contrast > 50) {}
@media (prefers-contrast > increase) { /* matches both 'increase' and 'high' values */ }

2. Have two separate media features that would allow use in a boolean context:
   prefers-increased-contrast: no-preference | increase | high and prefers-reduced-contrast: no-preference | reduce | low

@media (prefers-increased-contrast)  { /* matches 'increase' or 'high' */ }
@media (prefers-reduced-contrast)  { /* matches 'reduce' or 'low' */ }

[Wolfr]

Just posting that I have an active need for this feature as a web dev trying to make websites more accessible. Not sure if this is the right place, I am new here.

My 2 cents on syntax, I would rather have a simpler @media (prefers-increased-contrast) { } without values since the surrounding implementation depends on the OS.

I know it is a slider in macOS but essentially it needs to map to a high contrast checkbox in the host OS (Windows/Mac/Linux). It is up to the OS to set good defaults to what it means. But to start working with numbers is too complex imo and will not drive usage in actual CSS.

[cookiecrook]

Another suggestion I recently discussed with @grorg:

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

In the boolean context @media (prefers-contrast) should match both increase or high, but not reduce or no-preference.

[cookiecrook]

@Wolfr wrote:

I know it is a slider in macOS

The legacy slider (rarely used) would not likely affect this media feature. Currently the thinking is to have it match the highly used "increase contrast" checkbox/switch on macOS or iOS...

[alice]

To recap, I think there are several distinct concepts of contrast preference:

• True high contrast, along the lines of the Windows High Contrast Mode. This is often a light-on-dark colour scheme with white or yellow text, black background, reduced detail, few gradations of colour etc. This is intended for users with unusual vision impairments, who may also use other accommodations such as screen magnification to be able to access content.
  • Despite typically being light-on-dark, this is quite different from a "night mode" theme.
  • This is often an operating system setting which affects how text, borders and images are displayed. In this case, developers may wish to make adjustments to ensure that these modifications don't create other problems. This is the "forced" case, I think.
  • However, certain apps also provide high contrast themes, and it would be good to be able to allow users to opt in to these themes on all sites which support a common theming mechanism, such as a media query.
• Enhanced contrast, along the lines of OS X's setting and Gmail's current high contrast theme, which retain much of the "standard" palette and level of detail but enhance borders and increase text contrast to around the WCAG AAA level or better. The WCAG AAA level is intended for users with moderate vision impairments with a visual acuity of 20/80-20/40.
• Acceptable contrast, which is denoted by WCAG AA level. This is intended to be a standard contrast level perceivable by people with 20/40 vision or better - considered "minimal vision impairment" and comprising around 10% of the population of a typical wealthy country.
• There is also a small subset users who prefer reduced contrast for various health reasons.

These seem to map nicely onto the levels in #2943 (comment) - although we seem to have lost the concept of "forced" from #443

I don't know that we'd want to conflate "high contrast" and "enhanced contrast", since they really look quite different and target different audiences. Perhaps they'd need to be separate boolean queries?

[Wolfr]

You are right, they are separate concepts. Conflating them would lead to confusion. Thanks for the clear explanation.

…

On Tue, Jan 8, 2019 at 4:40 AM Alice ***@***.***> wrote: To recap, I think there are several distinct concepts of contrast preference: - *True high contrast*, along the lines of the Windows High Contrast Mode. This is often a light-on-dark colour scheme with white or yellow text, black background, reduced detail, few gradations of colour etc. This is intended for users with unusual vision impairments, who may also use other accommodations such as screen magnification to be able to access content. - Despite typically being light-on-dark, this is quite different from a "night mode" theme. - This is often an operating system setting which affects how text, borders and images are displayed. In this case, developers may wish to make adjustments to ensure that these modifications don't create other problems. This is the "forced" case, I think. - However, certain apps also provide high contrast themes <https://blog.jetbrains.com/idea/2018/10/intellij-idea-2018-3-eap-high-contrast-theme-and-more-accessibility-improvements/>, and it would be good to be able to allow users to opt in to these themes on all sites which support a common theming mechanism, such as a media query. - *Enhanced contrast*, along the lines of OS X's setting and Gmail's current high contrast theme, which retain much of the "standard" palette and level of detail but enhance borders and increase text contrast to around the WCAG AAA level or better. The WCAG AAA level is intended for users with moderate vision impairments with a visual acuity of 20/80-20/40. - *Acceptable contrast*, which is denoted by WCAG AA <https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html> level. This is intended to be a standard contrast level perceivable by people with 20/40 vision or better - considered "minimal vision impairment" and comprising around 10% of the population of a typical wealthy country. - There is also a small subset users who prefer *reduced contrast* for various health reasons. These seem to map nicely onto the levels in #2943 (comment) <#2943 (comment)> - although we seem to have lost the concept of "forced" from #443 <#443> I don't know that we'd want to conflate "high contrast" and "enhanced contrast", since they really look quite different and target different audiences. Perhaps they'd need to be separate boolean queries? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2943 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAxkh92ypKO5VuvTeqMSQ8btEWM4yWiks5vBBMvgaJpZM4VZRI8> .

[cookiecrook]

@alice wrote:

although we seem to have lost the concept of "forced" from #443

That seems to be addressed sufficiently by the forced-colors media feature in the MQ5 draft.

[frivoal]

true high contrast mode, as MS does it, is forcing colors, often but not always to high contrast (it can be used to force low contrast, or any color scheme you want). This is primarily meant to be addressed through the forced-colors MQ together with forced colors mode, though it does also trigger the prefers-contrast: high if the forced colors are indeed a high contrast set rather than low contrast one.

prefers-contrast: high alone, as I understand it, is more meant to reflect something along the lines of macOS's Enhanced Contrast.

Is there a situation where we have higher contrast than macOS's enhanced contrast, yet not have forced colors? If yes, it may be worth distinguishing between prefers-contrast: increase and prefers-contrast: high, but I have a bit of a hard time figuring what it is. If there isn't, what is the benefit of introducing the two levels on the prefers-contrast MQ in addition to having the forced-colors MQ?

[Wolfr]

From the author end it seems realistic to assign colors for 3 situations, but not more.

• Regular - the design as intended
• Enhanced contrast (not the colors you wanted as an author but fixing them up to accord to a11y guidelines - and help users with this setting - while still not making them an extreme “other” version of the design)
• Max contrast (akin to Microsoft's almost black and white mode)

Most websites would implement (1) and (2) - the max contrast (3) would be more like a system thing.

[cookiecrook]

FYI that leaves out the "reduced" contrast value that some have requested, but I don't know of any native OS implementations of reduced contrast, so it might be okay to forego that value until a similar feature is adopted by at least one major OS.

[fuzzbomb]

@Wolfr

Max contrast (akin to Microsoft's almost black and white mode) [...] would be more like a system thing.

That's what the forced-colors media query is for; it's not an author choice at all.

Note that Windows High-Contrast feature isn't always black and white. Users can specify any colours they want for a Windows High-Contrast theme... including low contrast colours (e.g. brown text on a beige background, which suits some users with dyslexia). That's why it's being called forced-colors in the standards track, instead of "high/max contrast".

[cookiecrook]

Is there a situation where we have higher contrast than macOS's enhanced contrast, yet not have forced colors? If yes, it may be worth distinguishing between prefers-contrast: increase and prefers-contrast: high, but I have a bit of a hard time figuring what it is.

I am not aware of any current platform that supports multiple built-in levels of increased contrast, but it's possible for any platform to add them in the future.

I'm trying to avoid having the value vocabulary locked to an extreme end ("high") which limits future flexibility: the syntax now implies platforms could only ever implement no-preference (default) or high contrast with nothing in-between. Furthermore, it does not accurately describe the current Mac/iOS setting, which is not a "high" contrast of +10:1, but instead an "increased" contrast of +4.5:1.

The same underlying technologies that allow Mac/iOS native and 3rd-party apps to support light and dark modes, also allow "increased" contrast color variants in each light and dark mode. There is nothing (other than a lot of engineering effort) technically stopping Mac/iOS from adding a non-forced "high contrast" mode (+10:1) using the same underlying system. If that were to happen, which CSS value should the existing "increased contrast" user match? It wouldn't make sense to match the high value, if the user and web author expectation of what "high" contrast means had changed.

A possible solution is to remove the current high value and replace it with a new one: increase. This could match either the Mac/iOS modes and the Windows mode today, but allow for future flexibility. If/when any platform shipped multiple contrast modes, the CSS WG could add the high value. At that point, Microsoft's current user setting could match both prefers-contrast or prefers-contrast: high (but not increase), and Mac/iOS's current user setting could match prefers-contrast or prefers-contrast: increase (but not high).

[cookiecrook]

Updating the suggested solution summary:

Current values according to the CSS MQ5 spec:

prefers-contrast: [ no-preference | high | low ]

Option 1: Change the current value high to increase.

Forego additional values (low and high) until any native platform implements a feature that makes the distinction necessary.

Con: Microsoft would need to remove their existing match for high.

Con: If any web author used the explicit value syntax @media (prefers-contrast: increase) rather than the boolean shorthand @media (prefers-contrast), their query may stop working on one or more browser variant in the future.

prefers-contrast: [ no-preference | increase ] /* remove `high` value */

Option 2: Keep high value and add new value increase.

Forego the the low contrast value (low) until any native platform implements a feature that makes the distinction necessary.

Con: Some authors may use the verbose version prefers-contrast: high and indavertently not match the Mac/iOS setting.
Pro: May allow authors to distinguish between the increase and high values.

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

Common Usage: Same.

In both proposals above, the 99.9% author usage case would be to use the boolean shorthand below, which would match all currently known increased or high contrast setting implementations.

@media (prefers-contrast)

[0xekez]

@cookiecrook

I don't know of any native OS implementations of reduced contrast, so it might be okay to forego that value until a similar feature is adopted by at least one major OS.

Unless someone has ideas about a system (or otherwise) setting that would indicate that the media query should be toggled to low this seems appropriate to me as well.

I'm looking into adding this to Firefox and despite some digging around am having trouble finding anything. If anyone has ideas though I'd love to hear them.

[frivoal]

A number of comments in #3856 also relate to this issue, so I encourage people to have a read (but please keep the discussion here).
In particular, See also @cookiecrook 's comment in #3856 (comment), which includes:

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

This is not really similar to the unfortunately named Windows High Contrast mode, since the Windows HC mode could result in that OR in a low contrast rendering, OR in an light-on-dark rendering, OR in a fuchsia-on-sepia rendering, or whatever the user wants. It is a forced color mode, and we have an MQ for that as well as more details in https://drafts.csswg.org/css-color-adjust-1/#forced. Great presentation from @melanierichards here: https://www.w3.org/2019/09/Meetup/speaker-melanie.html

---

I continue not to understand why you refuse to implement the value in the spec which is defined to match the mode you have in macOS and insist that we introduce an additional value which maps to the mode you have in macOS.

Sure, there might be in the future an OS which has a high contrast mode that is neither that of macOS, nor is forced colors as seen on Windows, and needs to be distinguished from both of those. We'll deal with it when it exists and when we know how it actually works and to what degree it needs distinguishing. In the mean time, I don't see why we should dedicate a value in the spec to this hypothetical and add a value to deal with what actually exists today, instead of implementing the spec as is.

If we just want to rename high to increased, why not. It's more letters, so I'd rather not, but I don't care strongly. But I continue to claim that the current definition adequately describes what macOS does:

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

[melanierichards]

Forgive my naivete here (and broadening the scope of the discussion), but is there a reason the group settled on keyword values instead of a numeric system?

I wonder if the numeric system should be explored again:

• Clear expectations for the author on what contrast level they should support (how does an author reason about high or increase values? What is "high" enough?), baked into the MQ itself
• Helps disambiguate from the Windows High Contrast feature
• I received feedback from a framework developer that they'd actually prefer to have numeric values for prefers-contrast, as they conceptualize contrast on a sliding scale; should open this up to the broader web dev community for input, of course.

I suppose the challenges may be 1) making sure numeric values don't explode in volume (maybe go off WCAG levels?) and 2) numeric values may not always align 1:1 with OS platform settings, but I think you'll get authors writing mis-aligned contrast ratios without clear guidance, anyway.

[alice]

how does an author reason about high or increase values? What is "high" enough?

This is a great question, and I think gets to a lot of the confusion here. In particular, WCAG doesn't really give us any guidance for the "true high contrast" case, perhaps assuming that users who need it will be using a forced colors mode?

I don't see why we should dedicate a value in the spec to this hypothetical and add a value to deal with what actually exists today, instead of implementing the spec as is.

It's true that it is a hypothetical for the time being, but it's also true that the Windows High Contrast mode and Mac Increased Contrast mode are quite different and are meeting distinct user needs.

A user who needs the level of contrast offered by Windows High Contrast default colours will not be able to use the Mac Increased Contrast mode, which is really more like a WCAG AAA mode in practice.

There are also variations in what websites which offer alternate colour themes are targeting.

Compare VS Code's high contrast theme (yes I know it's technically not a website):

with Gmail's "high" contrast theme, which is more like the Mac increased contrast mode:

It may well be the case that "true" high contrast only happens in practice (other than VS Code) when there is a forced colors mode applying. However, I do also feel that we should avoid conflating these two modes, just as we avoid conflating high contrast and dark mode even though forced colours high contrast modes often do use a dark background.

A website which meets WCAG AAA probably wouldn't need to do anything (assuming they include sufficiently contrasting border colours in their design) in response to prefers-contrast: increased, but might need to adapt to a high contrast forced colors mode differently.

A separate question is whether enough websites would respect either prefers-contrast: increased or a non-forced prefers-contrast: high to make the feature valuable to users, compared to adding more forced colors modes.

[frivoal]

Summary of where I think we're at.

Syntax 1 (spec today)

prefers-contrast: no-preference | low | high | forced

• MacOS's + iOS's “increase contrast” options map to high
• Microsoft's forced colors maps to forced (not high), and possibly, in addition, depending on the actual colors used, may map to low or high as well.

Authors should write @media (prefers-contrast: high) { } when writing high contrast styles.
@media (prefers-contrast) { } (without a specified value) only denotes that the author has some preference about contrast, but not which. An appropriate way to respond to this is to decrease visual complexity (replace background images with plain colors, turn off decorative gradients, or replace border images or box shadows with simple solid borders…)

Syntax 2

prefers-contrast: no-preference | low | increase | forced

Same as 1, just renaming high to increase, to avoid suggesting it is necessarily very high.
Downside: It's a tiny little bit longer.

Syntax 3 [interpretation A]

prefers-contrast: no-preference | low |  increase | high | forced

Distinguishes between high and increase.
MacOS/iOS would map to increase.
Microsoft Windows's forced colors still maps to forced, but now may map to low, high, or increase depending on the actual colors chosen?

Upside: This lets authors capture the difference between “somewhat high” and “very high”.
Downside: Writing @media (prefers-contrast: increase) or (prefers-contrast:high) { } is tedious.

Syntax 3 [interpretation B]

Same syntax as above, but inspired by how the color-gamut media feature works, any UA that matches high must also match increase, since high is higher than increase.
Authors can just write: @media (prefers-contrast: increase) when they don't want to distinguish.

Syntax 4

prefers-low-contrast: no-preference | low
prefers-high-contrast: no-preference | increase | high
[forced-colors remains a separate query]

These are defined so that only one of prefers-low-contrast and prefers-high-contrast can be truthy at the same time.

Upside: @media (prefers-high-contrast) {} is less verbose than @media (prefers-contrast: increase) or (prefers-contrast:high) { }.
Downside: It's not actually less verbose than syntaxes 1, 2, or 3[B].
Downside: There's no succint way to detect all the preferred contrast modes.

Key question

Syntaxes 3 and 4 allow distinguishing between increase and high, but syntaxes 3[B] and 4 provide shortcuts because usually you don't actually want to distinguish and it's annoying to make common case verbose. Do we actually really need to distinguish between “somewhat high” and “very high but not forced colors”? If not, I see no downside to syntax 1 or 2.

[alice]

Thanks for the comprehensive summary, @frivoal!

prefers-contrast: no-preference | low | high | forced

Sorry for not having followed this discussion, but why is there both prefers-contrast: forced and forced-colors? When would the former apply but not the latter?

Microsoft Windows's forced colors still maps to forced, but now may map to low, high, or increase depending on the actual colors chosen?

I definitely agree that we shouldn't match prefers-contrast: high if a user has selected low or moderate contrast colours.

I am curious to understand the usage modes of Windows High Contrast Mode (WHCM) in practice. I recognise that the colours are user-configurable, but to what extent are users modifying the colours chosen to enable a contrast preference other than "high" (along the lines of the extremely contrasting default values of black background and fully saturated yellow/cyan/green/white foreground colours)? I would like to better understand the user needs behind choices of low-contrast and increased-contrast colour options for WHCM.

Do we actually really need to distinguish between “somewhat high” and “very high but not forced colors”?

This captures the key question extremely well.

My feeling is that the answer is yes, we do need to distinguish between those two concepts, because the user needs and the resulting accommodations are quite distinct from one another. In particular, a site or theme which meets WCAG AAA would likely be suitable for "increased" but likely not for "high" contrast.

Even though it's not currently possible for a user on Mac to enable a "high" contrast preference (or "low" for that matter), or for a user on Windows to enable an "increased" contrast preference, I think leaving scope for those preferences to be added would be preferable to conflating these two modes.

Whether we are likely to ever have a "very high but not forced colours" preference is debatable, but even if we don't, I think it's still helpful to understand that the colours that have been chosen represent a high contrast preference (or low contrast, as the case may be) for things like icon images.

[tabatkins]

(Jumping back to just answer this one question.)

Forgive my naivete here (and broadening the scope of the discussion), but is there a reason the group settled on keyword values instead of a numeric system?

In general, MQs aren't well-suited for fine-grained distinctions between values. Responding to an MQ is a fairly "heavyweight" operation generally, and having a lot of potential breakpoints leads authors to either feel like they should be responding to a bunch of points along a gradient (making the author do a lot of likely-unnecessary work), or responding to just a few chosen in an arbitrary way that's not likely to be consistent across sites (bad for the user).

The rare exceptions, like the screen size queries, are reasonable because they correspond directly to things the designer already cares about, and are trivially testable by just dragging the window larger/smaller.

But for most things, we serve both the author and the user better by creating a small, opinionated set of values to respond to - it guides the author in how much effort they should put in (one unit of work per value, basically), and gives the user a more consistent treatment across sites, since everyone will be responding to the same single value near the user's actual preference.

[alice]

Apologies for being so slow to respond - I was on vacation without wifi all last week.

I think you can go ahead without me - I can sync up with James beforehand to make sure we're on the same page.

[cookiecrook]

@frivoal wrote:

When users set their preference for VSCode-like "max contrast", if a site doesn't have that theme, but does have the gmail-like "high contrast", getting at least that is better than nothing. so gmail queries for "high", and that matches both when the actual preference is "high" and when its "max". But VSCode specifically queries for "max", and so it only turns on that mode for people who prefer max.

It seems like the main disagreement is with the vocabulary. We're using the term "high" differently.

To me, "high" contrast means ~"max or nearly max contrast"… iOS and macOS do not have a system setting for that (it's "increased" a.k.a. "higher, but not high"), but both those platforms could have a true "high" or "max" setting, so I'm hoping we can avoid having the term "high" apply to the existing "non-high" contrast setting.

I wouldn't have thought "high" contrast would be a subjective term, but as it's clear several of us are interpreting it differently, it's likely that authors will too.

[cookiecrook]

The other main issue I've taken with the current syntax proposal is that IMO, too many tangentially related concepts are being squeezed into a single property: prefers-contrast.

The forced value has no direct relationship to contrast. Forced colors can be any value, resulting in higher, lower, or no change in contrast. Granted, Windows has a few "max" contrast themes that are also forced, but in my mind, the forced concept is closer to prefers-color-scheme than prefers-contrast. Why shoehorn it in here #3856 when it already has its own property: forced-colors?

[cookiecrook]

Likewise, the addition of low makes authoring less convenient since the boolean match is now ambiguous. I'm also unaware of any planned or existing system setting that would result in a match for low. The sepia theme Florian mentioned could be addressed in forced-colors or prefers-color-scheme.

[cookiecrook]

I'm available at 2020-08-12 T 16:00 GMT (this Wednesday at 9 AM Pacific) to discuss.

Ideally I'd like to see a useful boolean match (or otherwise very short authoring match) for prefers-contrast… I think this could be achieved a few different ways:

Updating my proposal list from above:

Option 1: Change the current value high to increase.

prefers-contrast: [ no-preference | increase ] /* the `increase` value can match both the iOS/macOS "increased" contrast and Windows "high" or "max" contrast settings. */

Option 2: Change high value to max and add new value increase.

Allows distinction between the different settings, but authors would still be able to use the boolean shorthand to match both.

prefers-contrast: [ no-preference | increase | max ] 

Forego low or decrease value until any native platform implements a feature that makes the distinction from forced-colors necessary.

Common Usage: Same.

In both proposals above, the 99.9% author usage case would be to use the boolean shorthand below, which would match all currently known "increased" or "max" contrast setting implementations.

@media (prefers-contrast)

[cookiecrook]

Another possibility that would allow the low or decreased value is to associate the named values with a linear numeric scale like Meredith mentioned, then using the greater-than/less-than syntax:

@media (prefers-contrast > increase) { } /* matches `increase` or `max` but not `low` or `no-preference` */
@media (prefers-contrast < max) { } /* matches `low`/`decrease`, `no-preference`, or `increase` but not `max` */

I wanted to mention the possibilities above, though these are less desirable to me because of:

• the added complexity in general, and
• the boolean would match the low value... therefore @media (prefers-contrast) could mean the opposite: "does NOT prefer contrast."

[tabatkins]

the boolean would match the low value...

Yeah, English is a little hard... It's accurate to say that the boolean matching means "has a contrast preference", just not which way the preference leans. In general, the "true" boolean match for the prefers-* MQs isn't a particularly useful value, only the "false" match is. (It's just that several of the prefers-* only have a single truthy value, so an author can pretend that the presence of a preference tells them exactly what the preference is.)

[cookiecrook]

In general, the "true" boolean match for the prefers-* MQs isn't a particularly useful value, only the "false" match is.

I don't agree that truthy boolean matches would never be useful.

There's a lot of opportunity to have the boolean match a minimum simple preference while leaving an opening for more specific values. I haven't pushed for the more specific values yet because MQ would need to address anti-fingerprinting security before the more specific values should be implemented.

For example, iOS is already shipping two variants of a native "reduce motion" setting that differentiates between pans (e.g. automatic side scrolls between screens) and other types of problematic vestibular motion like parallax and scale/zoom. The interface pans often convey a hierarchy. Other, more decorative animations are usually more extraneous, and often more problematic for those with vestibular disorders.

One could see a future expansion of prefers-* to one or more optional variants, making the boolean match most useful for authors.

prefers-reduced-motion: no-preference | [ reduce | [exclude-parallax &| exclude-scale &| … ]
prefers-reduced-opacity: no-preference | [ reduce | opaque ]
prefers-(increased)-contrast: no-preference | [ increase |  max ]
prefers-color-scheme: light | dark | forced

[cookiecrook]

Tab mentioned:

prefers-contrast: no-preference | less | more | forced

[css-meeting-bot]

The CSS Working Group just discussed mediaqueries-5] `prefers-contrast: high` media feature doesn't account for macOS and iOS, and agreed to the following:

• RESOLVED: Change high and low in the MQ to more and less

The full IRC log of that discussion

<dael> Topic: mediaqueries-5] `prefers-contrast: high` media feature doesn't account for macOS and iOS
<dael> github: https://github.com//issues/2943
<dael> [we can't hear jcraig]
<dael> jcraig: Thank you for delaying this until I was available
<dael> jcraig: Is everyone generally familiar and just wants my PoV or should I introduce issue?
<dael> astearns: Discussed recently so pretty up to speed
<dael> jcraig: Posted a few comments earlier in the week.
<dael> jcraig: Main issue I obj to is that the term high is typically interpreted as at the extreme end. I'm sure you've seen screenshots but what we have with iOS and macOS a11y it's up to min or a little past but far from high.
<dael> jcraig: Difference between MS high contrast and our increased contrast is very different and don't want to conflait.
<dael> jcraig: Multi solutions. florian prop high and max. I don't like high and max, but we could do increase and max to be more explicit.
<dael> jcraig: Second issue is we ideally shouldn't have authors write long MQ to match both. Ideally like to see it match the bool but another proposal was allow it to match the greater than query. @media prefer-contrast greater than increase
<dael> jcraig: florian had a prop that was close that said if there's a client that matches high it also matches increase. A little confused by that.
<tantek> s/patient policy/patent policy
<dael> jcraig: I feel like risk is some authors will use the max/high value and leave out the iOS
<astearns> ack fantasai
<Zakim> fantasai, you wanted to ask whether the problem is the name or that there is only one level
<dael> jcraig: Those are two main issues. Happy to answer questions or add detail
<dael> fantasai: There's a number of sub issues within this. Some depend on others. Like to focus on first question is the problem about naming or do we need 2 levels to express the somewhat high and very high? Need to figure that our first.
<tantek> this does sound perhaps similar to font-weights
<tantek> s/sound/sounds
<dael> jcraig: I think it's both. Right now iOS and macOS don't offer true high contrast. Underlying tech would allow a true high contrast in the future. If by expecting apple increased contrast matches high it limits us from shipping higher
<dael> fantasai: So we need 2 levels
<tantek> i.e. the same arguments for why we don't just have "normal | bold" for font-weight could be applied here
<dael> jcraig: Yes b/c [missed]. Most authors won't need but some will want
<dael> fantasai: If we need to express 2 levels in MQ...I want to go piece by piece...does anyone argue against 2 levels?
<florian> [still cannot rejoin webex: would like to hear why we need both, given that no OS ships non-forced max contrast]
<tantek> florian, see my analogy to font-weight
<jcraig> q+
<dael> TabAtkins: Yes, the fact that no OS exposes 2 levels and expresses at best slightly different levels makes me loathe to do this. If we don't do multi-match I'm really unhappy. Even then super high contrast on windows is forced. If OS has absolutely max you have to be careful and that maps to forced.
<Rossen_> +1 to TabAtkins
<Rossen_> q+
<tantek> back when we standardized font-weights 100...900, no OS exposed more than 2 levels of font-weights, and now most do
<dael> AmeliaBR: I think that's important distinction between windows and mac mode. It's not how much but if it's preference or forced override to extreme. Do we realistically expect any authors/users to have prefers extreme contrast w/o forced-color mode?
<dael> AmeliaBR: If that's not a combo we expect to see where authors have setting for max-contrast but don't force it then I'm not sure why we have to have that in MQ
<jcraig> ack me
<tantek> we should model the levels of contrast *across* the different features of different OS, not just per-OS
<tantek> and then give authors the ability to reason about it, like we did with font-weights (perhaps not quite as granular)
<astearns> ack jcraig
<tantek> q?
<dael> jcraig: I'm glad TabAtkins and AmeliaBR brought up that's it's only possible through forced. That's only way for user to change. Same with low-contrast, we only know it in forced colors. We have forced-colors media features. If we want to rely on forced colors as other way to differentiate it could drop to one increased value of prefers-contrast which matches windows and mac. If we do that we have vocubulary which needs to match. higher is in prose whic[CUT]
<astearns> ack Rossen_
<dael> jcraig: Even if it's higher it leaves it open for future poss
<dael> Rossen_: Couple of things making me uneasy. Mostly repeating. Clear distinction between forced-color and prefers-contrast. One is opt in one is opt-out. One authors proactive, the other could be reactive. in forced-colors it's opt-out for authors. Authors need to be proactive to opt out and supply style.
<dael> Rossen_: In macOS increased contrast it's more opt-in preferential styling
<dael> Rossen_: jcraig question as to how and why forced/high got into MQ. Couple of efforts to harmonize MQ starting to alsmot dup each other. They have to do with contrast, color, and there is clear user choice supplied through OS setting
<dael> Rossen_: Motivation behind hamonizing is good
<dael> Rossen_: If we contrast with color scheme where harmonizing dark, light, etc is easier
<tantek> I see jcraig's numerical range proposal too
<jcraig> not asking why "forced-colors" is in... I'm asking why we have both "forced-colors: active" and "prefers-contrast: forced" which are duplicates...
<dael> Rossen_: Harmonizing of dark and light in presense of forced-color is easier to achieve b/c we can detect if primary bg and fg are dark or light and match appropriate colors
<dael> Rossen_: In case of contrast we had discussion where prefers-contrast:forced maps well into this picture similar to how we map prefers color scheme.
<florian> q+ to comment on forced
<jcraig> q+
<dael> Rossen_: Forced we should revisit and figure out if it makes sense
<aja> q? from non-member
<aja> q+ from non-member
<jcraig> q+ to ask why "forced" was added to prefers-contrast instead of prefers-color-scheme
<dael> TabAtkins: As florian said in thread it is try prefers-contrast:forced and the MQ duplicate it's for histoic reasons. prefers-contrast:forced is the preferred way to do it, but shipped later. Knowing that the user prefers the forced colors is useful to do that. We wouldn't have produced forced-colors today
<dael> fantasai: And you can match high and forced at same time
<astearns> ack florian
<Zakim> florian, you wanted to comment on forced
<jcraig> q+ aja
<astearns> ack from
<jcraig> q- from
<jcraig> q- non
<aja> a mid value, as distinguished from no-preference would be good
<jcraig> florian citation of that?
<fantasai> aja, gray on gray is not readable ^_^
<dael> florian: Key intent to have it in same MQ is thinking of how people react. If it's high|low|forced you'll do a lot different but with all you'll do some simplification of the page. Not a given but a slight simplification is something you'd want to do for any contrast preference.
<aja> oops...sry
<dael> florian: This is the discussion leading to the resolution of that topic
<chris> q+
<dael> jcraig: I've heard that mentioned but the abstraction...certainly the detail is reduced in high but you mentioned low and I'm not aware of user need reducing complexity for low. That's where I was looking for information source.
<astearns> ack jcraig
<Zakim> jcraig, you wanted to ask why "forced" was added to prefers-contrast instead of prefers-color-scheme
<dael> jcraig: First, TabAtkins answered my previous question. not convinced we need it in both places. Not convinced prefers-contrast is ideal. Seems better match for prefers-color-scheme. Having some way for author to learn if this is higher or dark|light of forced-colors is useful, but I don't see change there.
<dael> jcraig: Esp b/c forced-colors doesn't have direct relationship to contrast. User can set it to whatever. Low, high, no difference. Not sure why it's in here. Seem to overcomplicate it.
<dael> florian: If there is a preference for dark or light it doesn't imply desire for visual simplification. That's why doesn't belong
<dael> jcraig: Not convinced forced-color mode provides desire for simple. If you have high, sure, but doesn't only have high
<dael> TabAtkins: forced-colors you only have 8 colors so you can't have high visual complexity. high contrast is complexity reducer b/c then you have less space to play in. low you have less space to play so less ability to do visual decoration
<dael> astearns: Not sure visual complexity is useful thing for this discussion
<dael> jcraig: Can set aside
<dael> fantasai: Factor into why we have these features all in one instead of low and high as sep MQ and forced-color different. We wanted this to be all one thing so you can select as use case to reduce visual complexity.
<jcraig> q+ to mention Alice's request
<dael> fantasai: That plays into overall feature design. Doesn't help with if we have 2 levels or only 1. THen we can decide what to name. Then if they're all in one property
<dael> Rossen_: One addition to what fantasai said. reason why we chose forced-color and moved away from high contrast is that there's 2 aims of this which windows has had. One is guar user preferred contrast and reduce cognitive load by reducing everything to small set of colors and drop visual feature which can overload
<dael> Rossen_: This is about simplification and reduction in visual complexity
<dael> [can't hear aja]
<astearns> ack chris
<dael> chris: Did I hear something say they didn't see a need for reduced contrast?
<aja> some authors would want a AAA / SAPC 100 by default, but want to honor a mid (AA / SAPC 85) or low (SAPC 70) preference...possibly scripted based on a radio, or from browser pref, and not necessarily from OS
<dael> jcraig: I said I don't believe any impl with a default value to allow low contrast other than through forced colors. Impl is forced-colors is enough and low contrast doesn't need to go into original prop.
<dael> chris: I do need low contrast on occasion so there is user need. If you weren't arguing that I don't need to rebut.
<florian> q?
<dael> jcraig: There's definitely a need for that
<astearns> ack jcraig
<Zakim> jcraig, you wanted to mention Alice's request
<aja> there's WCAG language for low contrast being preferred by dyslexics
<dael> jcraig: fantasai mentioned use cases. Alice's main reuqest was she hasn't seen use casesmentioned in spec. Would be nice to have list of use cases and what we're trying to solve. Where we started is what are system setting on platforms and how do we put it in these media features
<tantek> +1 to explicitly listing the use-cases, *and* linking to WCAG for details
<dael> jcraig: She's asking for what are use cases we're solving. Low vision is one that's difficult to solve b/c there's a lot of levels to it. A lot of variants. If we can put together a few or a list of problems, that's what she requested in discussion yesterday
<florian> q+
<dael> astearns: That's it for the queue. I'm assuming aja was on to mention low contrast is user need based on IRC chat
<astearns> ack florian
<AmeliaBR> q+
<dael> florian: I could imagine an OS wanting to ship a high contrast that's not forced. I can imagin low contrast not forced. We should go with design that's amenable to having both values. If we have them are they best combined or best sep.
<aja> yes....and a specified mid value vs no-preference
<jcraig> Florian's comment: https://github.com//issues/2943#issuecomment-665453076
<dael> florian: I think design I made in the spec, Syntax 1 is current spec and can evolve into 3b. With current we can now or later add keyword for non-forced very high contrast
<aja> mid in addition to no-preference, actually
<dael> florian: Current syntax and 3b are extension of same. BReaking apart isn't. Breaking low contrast out separate is a different design and not an extension
<dael> florian: I feel we should take current or 3b b/c compat and let you take all variants and let you not distinguish if you don't need to. It's more verbose to do simple things
<dael> florian: Syntax 4 is break everything apart and have low and high as separate. It can have multiple levels. Separate MQ for each level in high and low. Different design than current
<TabAtkins> q+
<dael> florian: Syntax 3b is compat with current. Same name or not can use that syntax and add a keyword for higher.
<dael> florian: I prefer 3b if we're having multiple levels. It's approx same number of characters and by combining we make it possible to target very high and increased and forced and low together as a non-verbose query if you want visual simplifications
<aja> TabAtkins, examples I've seen have just had to assume mid=no-preference. can find url for a switcher (bt google, IIRC)
<dael> jcraig: Coming around to that. If you leave high and max out it allows us to feature expand to a non-forced max contrast
<jcraig> @media (prefers-contrast > increase)
<dael> jcraig: Other with that pattern is > < syntax
<jcraig> @media (prefers-contrast: max)
<dael> florian: I think that's weird b/c allow a query that matches on increased and low but not extremely high. seems like...why?
<jcraig> @media (prefers-contrast < max)
<dael> jcraig: Why not like ^ or ^
<dael> florian: What's the 2nd? Prefer contrast less than max?
<dael> jcraig: SHould have been >
<dael> florian: But you can write what you did and I"m not sure what it means. If they're not all comparable and no preference isn't > or < then how can you sort?
<dael> jcraig: No preference is 0, n+ and n- values
<astearns> ack AmeliaBR
<dael> AmeliaBR: I think we have an important discussion about are we trying to represent options that are there or trying to create an ideal schema of user options we hope will one day be there?
<dael> AmeliaBR: Not sure that's ever going to happen when talking OS level user options
<jcraig> current syntax does not solve either of those ABR
<florian> q+
<dael> AmeliaBR: There is definitely an argument for creating a schema open to options that don't exist. Like please no extreme contrast. Use cas for prefers contrast < max I have a migraine. We don't have a browser or OS way to express that
<dael> AmeliaBR: OS options for that use case are reduce screen brightness and turn on night mode
<dael> AmeliaBR: That doesn't mean we shouldn't be open to someone adding a browser extension but it makes it a lot harder to get right when we don't have examples a spit balling what we think users want and might make sense.
<dael> AmeliaBR: Difficult to get it right. As aja said in comments why isn't there prefers medium contrast to express I don't like low contrast or higher contrast. We can't express that use case.
<dael> AmeliaBR: I don't have a clear solution. I think better to focus on a simple schema that represents options that exist and can be expanded as new options come in
<tantek> a medium preference would be kind of nice frankly, if web authors actually respected it, to provide for a more consistent contrast across reading different pages instead of having the contrast jump high / low all of over the place based on designer artistic preferences
<dael> AmeliaBR: How? One way is try and keep independent concept sindepended. Maybe keep preference around high contrast; hate, like, don't care- separate from low contrast. Preference on one side doesn't impl preference on other
<dael> AmeliaBR: Keep simple by keeping distinct concepts separate
<jcraig> q+ to answer ABR's historical background of "increase contrast" research from the Apple side... I can't speak to the Windows research.
<dael> AmeliaBR: Avoid assumption things always go together
<dael> TabAtkins: Pulling back to original topic of issue where jcraig found 'high' misleading can we rename 'high' and instead use more and less. Easier than decrease and increase. Would that resolve the issue?
<dael> AmeliaBR: We can agree but if we might take the whole thing out is it right time to bikeshed?
<jcraig> so "more" would match both the iOS/Mac style, and Windows?
<dael> TabAtkins: We didn't start with disagreement about purpose? We're talking about and thinking again but we've discussed before. If nothing ever happens on ripping it all out we can fix the original problem with the name
<astearns> q?
<astearns> ack tantek
<astearns> ack TabAtkins
<dael> florian: To answer jcraig irc more would match windows and macOS. If we add extremely high it would match...That's the b of 3b is where we make it like color-gamut. If preference is for extremely high on query you match extremely and somewhat high. You want at least high
<dael> jcraig: I like more/less better. I also like b/c leaves open max value or to adjust it to linear steps. Solves original question
<florian> q-
<dael> astearns: If people on queue are okay I prop we resolve change the current value from high to more
<dael> florian: And low to less
<florian> wfm
<dael> astearns: More discussion on changing high and low to more and less?
<dael> AmeliaBR: Anyone shipping?
<dael> jcraig: [missed] might be shipping
<dael> jcraig: MS was shipping prefixed values
<dael> AmeliaBR: Rossen_ have you shipped the prefers-contrast: high|low syntax?
<dael> Rossen_: Not more than Google chrome would have
<dael> florian: We're proposing rename
<dael> Rossen_: Don't believe will be issue. DOn't know if Alison is on. Do you recall?
<dael> alisonmaher: I didn't do anything for prefers-contrast. Nothing additional to Chromium
<aja> AmeliaBR, FF is "shipping" only on nightly....pref'ed on, IIRC
<dael> Rossen_: The change will be as fine for as as anyone else
<dael> astearns: Prop: Change high and low in the MQ to more and less
<dael> astearns: Obj?
<dael> RESOLVED: Change high and low in the MQ to more and less
<astearns> q?
<dael> AmeliaBR: Other part of issue was change how binary matches. Bool mode. Set that aside or discuss?
<dael> jcraig: Resolves my concern. It's short and authors will type most of time. prefers-contrast:more is only a few extra characters
<dael> florian: Since this thread is enormous and jcraig is satisfied I think we should close this and consider another issue if other concerns
<dael> astearns: If more to discuss on this good to open a separate issue
<dael> jcraig: Other possibilities in issue are covered. Will raise separate if I need
<dael> AmeliaBR: I think this improves the state but to the point from Alice it would help to look at use cases and figure out which user needs are not being met. Then we can move forward. That might be something to follow
<dael> astearns: THat's good to call out. AmeliaBR will you raise an issue on that where we need USs in spec?
<dael> florian: There are some in spec, may want more
<dael> AmeliaBR: I'll pull out relevant points from issue and spec
<dael> jcraig: TO channel Alice she's not particular if it's in spec or explainer. I think spec is better but alice didn't have a preference
<dael> astearns: This group prefers in spec.. We can raise an issue.
<jcraig> ack me
<Zakim> jcraig, you wanted to answer ABR's historical background of "increase contrast" research from the Apple side... I can't speak to the Windows research.
<dael> jcraig: My comment was about background, but AmeliaBR we can do a separate call

[cookiecrook]

I think this is a reasonable, simple solution because:

1. It keeps the common use case short (even if not the boolean match):

@media (prefers-contrast: more)

2. It keeps the syntax open to future values like max (non-forced, extremely high) if they are needed in later platform iterations.

The rest of the points I raised in this thread—such as the duplicated: "prefers-contrast: forced" and "forced-colors: active"— can be raised as separate issues.

[cookiecrook]

The working group also agreed to add more use cases via request from @alice.