Create a 'high-contrast' media feature within CSS media queries

[michael-n-cooper]

This issue was originally raised in the APA tracker as ISSUE-500. Migrating to CSS A11Y.

[michael-n-cooper]

See also APA ACTION-728.

[patrickhlauke]

Possibly of interest: https://www.paciellogroup.com/blog/2016/12/windows-high-contrast-mode-the-limited-utility-of-ms-high-contrast/ and http://www.gwhitworth.com/blog/2017/04/how-to-use-ms-high-contrast

[patrickhlauke]

Fundamentally, I'd welcome a simple standardised high-contrast media feature (that just lets you query whether it's active or not, without the extra white-on-black/black-on-white granularity offered currently with -ms-high-contrast.

My concern though is that on many platforms, high contrast, once enabled, acts on quite a low level and simply inverts all visible pixels on the display. In these cases, if there was a high-contrast feature that evaluated to true, it may lead to authors making assumptions about which color scheme they should use - and then that choice gets inverted anyway. But as a general way for authors to provide strongly-contrasting color choices when this is true, but possibly softer contrasts when false, could be useful.

[patrickhlauke]

for reference, some interesting discussion happening on w3c/csswg-drafts#1286 about the usefulness/complexity of having a simple true/false media feature.

[tabatkins]

Relevant: for knowing that the user wants high-contrast (but the UA hasnt' done anything forcibly), @frivoal and I are currently leaning toward just using the 'light-level' MQ (see issue 3 in that section). While superficially about light levels, "dim" doubles as a "prefer light on dark" setting, while "washed" doubles as a standard "prefer high-contrast dark on light" setting.

Merging these together has the distinct benefit that authors designing for one end up accidentally handling the other case as well (that is, anyone trying to handle light levels gets a11y benefits for free, and vice versa). As far as we can tell, this appears to be a close-enough correspondence to justify not adding a special-purpose 'prefers-*' MQ just for contrast preferences.

---

Separately, the 'inverted-colors' MQ tells you that the UA has inverted the colors, allowing you to react to that. The relationship of this with "UA has imposed some high-contrast light-on-dark or dark-on-light adjustments" is unclear.

[alice]

(Largely copying my comment on w3c/csswg-drafts#1286 over here):

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.

[patrickhlauke]

agree with @alice here

[tabatkins]

I'm not necessarily against defining an alias of 'light-level' named prefers-high-contrast: none | light-on-dark | dark-on-light, where light-on-dark is an alias for dim and dark-on-light is an alias for washed. That way authors can find what they want from both directions - if they're looking for a11y stuff, they've got it (and it happens to also work well for light-level adjustments), and vice versa.

[frivoal]

I think it would be good to ask accessibility experts who actually know about the various conditions that lead people to prefer high or low contrast, with light on dark or vice versa, to see how good the match is.

[tabatkins]

Yeah, def, but just pointing out that you and I have had this discussion before, and there's a significant benefit to making things "just work" rather than creating a11y things that are nearly the same as other features but very slightly different; most of the time that just means people will only use one or the other.

[frivoal]

Oh yes, absolutely. So I'm totally for light-level doubling up as an a11y, as that will increase its usage and its benefits. But if we're going to give it two names, it seems better to check if they actually mean the same, or only partly.

[patrickhlauke]

my concern would be authors using light level for whatever form of custom styling (e.g. really popping vibrant colours when light levels are low, because they look best when the display is cranked up super bright to compensate, and a completely different visual appearance when light levels are high; or adding moons and stars when it's low light and a bright smiling sun and cloud picture when it's light; ...or any other things that authors can and will do based on different values) ... and all those would have nothing to do with actually heeding to the user's desire/need for higher or lower contrast. you'd get the accessibility benefit mostly as a coincidence, and sometimes you won't.

[alice]

Argh, forked conversation. Copying w3c/csswg-drafts#1286 (comment) over here:

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 [1]:
  • 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.

[1] @frivoal added in w3c/csswg-drafts#1286 (comment):

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