Re: [csswg-drafts] [mediaqueries-5] `prefers-contrast: high` media feature doesn't account for macOS and iOS (#2943)

> why is there both prefers-contrast: forced and forced-colors? When would the former apply but not the latter?

They are expected/specified to both match at the same time.

The idea to have `prefers-contrast: forced` was because in addition to actually adjusting contrast or changing colors, a common (and generally desirable) response to either contrast preferences and to forced colors is to reduce visual clutter and to tone down decorative things (e.g. replacing background images with plain colors, turning off decorative gradients, or replacing border images or box shadows with simple solid borders…), and so being able to target all these with a common and simple query (`@media (prefers-contrast)`) was seen as desirable.

The reason for having that in addition to, rather than instead of, `forced-colors` is that `forced-colors` has already shipped (in Edge).

Overall, whether one likes that aspect or or not, I think it is mostly orthogonal to the rest of the discussion here.

> to what extent are users modifying the colours chosen to enable a contrast preference other than "high"

I don't have statistics, but I know of at least one case: some people with dyslexia find contrasty things hard to read, as they feel that the letters shine / sparkle as if backlit by too bright a light, and find low contrast to be more comfortable.

As for not necessarily accessibility centric uses for `low`, I'd say the popularity usage of sepia tones in ebook-reader (or reader mode) is an interesting indicator.

> >  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 […]

I agree that a very high contrast design, like that of VS Code, isn't the same as an enhanced contrast design, like the one of gmail. But also, I think it the number of sites that intent to have an enhanced contrast design in the manner of macOS/gmail, and to respond to forced colors, and to have on top of that a very high contrast mode separate from the forced color mode, is likely very small. Note for instance that VS Code and gmail only have one of each, not both. It is not a theoretical impossibility, but it is not a common case, and no OS I know of today offers users a setting to express that.

This is also part of the tension that I see in some earlier proposals: they suggest we need to distinguish between the two and therefore have two keywords, but also, since most of the time authors would want to query about both of them together and not distinguish, we need to have a syntax that's not too verbose for doing that.

So, if we want a syntax that's not too verbose for the common cases, as well the ability for authors (but not the obligation) to distinguish between high and very high contrast, I'd say something along the lines of 3B from https://github.com/w3c/csswg-drafts/issues/2943#issuecomment-665453076 is likely to be a good compromise. Right now, no OS ships the very-high-but-not-forced setting, so I'd be tempted to put it off until someone does ship it, but to solidify the design, we could also include it as an at-risk feature. And for the sake of brevity, I'd probably go with `high | boost` or `high | max` rather than `increase | high`

So, in summary, that means we'd have something like this:
> ```
> prefers-contrast: no-preference | forced | low | high | max
> ```
> <dl>
>  […]
> <dt>high
> <dd>Indicates that user has notified the system that they prefer an interface that has a higher level of contrast.
> <dt>max
> <dd>Indicates that the user has notified the system that they prefer an extremely high contrast, such as a black background with fully saturated yellow/cyan/green/white foreground colors (or vice versa, see `prefers-color-scheme` for information on which is prefered). User Agents that match this value must also simultaneously match `high`.
> </dl>

-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2943#issuecomment-666166940 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 30 July 2020 06:55:36 UTC