[mediaqueries-5] high-contrast media feature

[patrickhlauke]

Wondering if there's still potential for standardising a very simple implementation of a high-contrast media feature, as an indicator that the user has enabled high contrast in their OS/UA.

xref w3c/css-a11y#1

[frivoal]

Yes, I believe there is potential on this topic, and that we should address it.

However, I do not believe it to be very simple. Primarily because high-contrast means different things in different OSes and UAs, to which authors should react differently:

• First axis
  • Contrast-boost via image processing at the pixel level (possibly done by the OS with no understanding of the content)
  • Content-aware contrast-boost, which may pick different (contrasty) colors for different types of content, treats images differently from text, could affect which font or font-weight is used (necessarily done by the UA)
• Second axis: Is the contrast boost coupled with a color inversion (which can be done at the pixel level, or content aware to avoid inverting images), or with enforcing dark-on-light or light-on-dark (which assumes an understanding of what's content and what's background).

So, do we need 2 (or 12) completely separate queries to express all the various things that exist? 1 query with a bunch of values? Expose some higher level semantics? How?

I've heard ideas on this topic, and have a few of my own, but I don't think we have firm conclusions yet.

[patrickhlauke]

Absolutely. Having very detailed indication of what kind of high-contrast the OS/UA are actually using will be tricky. Was only thinking as a first stage having at least an on/off indicator, but agree that it's possibly of little practical use to devs beyond a basic "pick strong contrasting foreground/background color combinations" (which would still be strongly contrasted in situations where the color inversion is done at pixel/OS level, and would be replaced by OS' enforced colors in situations like Windows High Contrast).

[frivoal]

Not sure even that would help. For instance, OS X (at the system level) has two settings that work on boosting contrast: one that works at the pixel level, and one that is more content aware. The one that's content aware also adds (in the native UI at least) borders around things. If the high contrast pair of foreground/background colors that a web author picks accidentally makes the background match the border, you may accidentally be making things worse. Also, I don't think it is useful for an author to react to content having been put in high contrast mode by putting content in high contrast mode, since it's already been done. Either the author needs to do it because there's a request to do so but the UA hasn't done anything itself, or because the author knows that a particular way to boost contrast gives undesirable side effects with their content, and want to remedy that problem, in which case they need to know what adjustment has been made.

Here are a few things we may want:

1. have colors been forcibly inverted at the pixel level (if yes, authors should do things like double-inverting images and removing shadows) (see https://drafts.csswg.org/mediaqueries-5/#inverted)
2. has contrast been forcibly boosted at the pixel level without inversion (if yes, authors should do what???)
3. Is the UA enforcing a content-aware color scheme (light-on-dark, dark-on-light...), or content-aware contrast-boosting measures other than the color scheme (think solid borders, sans-serif fonts, different styles of native components or focus hightlights)
4. Is the UA doing nothing particular, but suggesting (based on a user preference) that the author does the sort of things described in 3
5. Do we want to give authors a property that lets them disable UA-provided content-aware contrast boosts on a particular element, so that they can provide it themselves in a way that is more appropriate for their content? (like https://msdn.microsoft.com/en-us/library/windows/apps/hh441137.aspx)
6. Does this interact with https://drafts.csswg.org/mediaqueries-5/#light-level, and if yes, how?

[frivoal]

@grorg I'm curious to have your/Apple's thoughts on this.

[patrickhlauke]

If the high contrast pair of foreground/background colors that a web author picks accidentally makes the background match the border, you may accidentally be making things worse.

not necessarily worse, provided that the foreground/background the author picked is high-contrast. the forced border would not show, but as that border is only there to ensure contrast (and not to make things fatter/bolder), the end result would still be a strong contrast, arguably.

but yes i can see how all this is far more nuanced than a simple true/false statement would allow for (which is likely why this hasn't been standardised until now).

[alice]

I understand that this is supposed to be subsumed by https://drafts.csswg.org/mediaqueries-5/#light-level

However, I wonder if "high contrast" would be better as the primary concept, with light levels mapped onto the various high contrast preferences (dim -> light-on-dark, washed -> dark-on-light)?

I think that would better match the way people would tend to think about these options.

[frivoal]

I understand that this is supposed to be subsumed by https://drafts.csswg.org/mediaqueries-5/#light-level

Maybe, maybe not. These things overlap for sure, but exactly how to sort that out is still unclear.

[alice]

@frivoal

Maybe, maybe not. These things overlap for sure, but exactly how to sort that out is still unclear.

Good point. I chatted offline with @minorninth about this.

Some slightly scattered thoughts:

• light-level defines more of a "why" than a "what", and I think page authors would be more interested in "what".
• @minorninth pointed out that there are at least three axes as to "what":
  • Inverted colors: on/off
  • Grayscale: on/off
    • Plus more subtle colour modifications like "warm light" or "daltonized", maybe?
  • Increased contrast: none vs maximum (slider)
• And further, each of these may be:
  • controlled by the OS: the page needs to react to the "pixel level" change, or
  • expressed as a user preference: the page needs to apply the preference (e.g. "I am a hacker and I want light on dark theme for everything all the time so I can pretend to be in the matrix")
• User preferences may ideally be browser-wide or (like text zoom) site specific and frequently changed.
• It would also be nice to be able to configure the relationship between light level and the above factors, with some good defaults.

[frivoal]

@alice: Thanks, a bunch of good points.

And further, each of these may be:

• controlled by the OS (pixel level)
• expressed as a user preference

I think there's one more:

• Controlled by the UA, taking the markup/semantics into account

[fvsch]

I would like to suggest a prefers-high-contrast query, set by the UA either with a dedicated preference or by inheriting the OS accessibility settings (when relevant).

My main use case would be site designs that are expected to use a brand color which has bad contrast (when contrasted with a white background or white text). Switching the brand color with a more accessible one would be more acceptable to site owners if done for users who specifically requested it.

Currently, websites with this use case either don’t address the issue, or offer in-site controls like on sncf.com:

Options in this example are:

Contrast: default | stronger | inverted
Animations: enabled | disabled

[frivoal]

@fvsch This issue is indeed about creating something like this, but I am not quite sure how your proposal answers the questions/concerns raised above it. The other prefers-* media queries are dealing with simpler topics, where there's just one axis, but this has multiple concepts overlapping, at it still isn't clean to me how to expose all the relevant parts in a way that is both sufficiently detail to be able to do the right thing, and sufficiently well designed that it is easy to do the right thing.