[mediaqueries-5] prefers-contrast: infer contrast preference from forced colors

[0xekez]

As discussed in #2943 and #3856 at the moment there is limited OS level support for detecting when high or low contrast is preferred in the prefers-contrast media query. When colors are being forced, an additional way to detect these preferences might be to compare the contrast ratio of the forced background color and text color.

Threshold values could be taken from the Web Content Accessibility Guidelines. For example, a contrast ratio below 4.5:1 (the lowest allowed contrast for AA text) would toggle low for the media query and a contrast ratio at or above 7:1 (lowest for AAA text) would toggle high.

This would interpolate well with existing extensions and otherwise that try and make websites high/low contrast by forcing colors on webpages.

[frivoal]

As part of applying the resolution in https://github.com/w3c/csswg-drafts/issues/3856, I've included a mention that UAs should infer low or high based on the actual contrast of the forced color scheme.

See the Note in https://drafts.csswg.org/mediaqueries-5/#valdef-media-prefers-contrast-forced.

For now, I have not included a recommendation (or a requirement) such as the one suggested above to activate high above 7:1, and low below 4.5:1. Having interoperability is good, and using WCAG as a baseline seems like a good start, but at the same time, I'm unsure these are the right thresholds. WCAG AAA or better is good contrast. Is that the same as high contrast, or should the bar be higher, like maybe 10:1? Same for low: WCAG AA, even if it isn't as high as AAA, is still decently contrasty. is that low enough for "low contrast", or should we go a bit lower, like maybe 3:1?

Or, we could continue to leave that up to UA heuristics?

[0xekez]

Thanks for taking a look at this and adding to the spec. I agree that having some interoperability would be good especially given that we already have some baseline from the WCAG. Ideally, prefers-contrast should behave the same across browsers.

To add some context, I went through the Windows high contrast themes that are installed by default and calculated their contrast between text and background colors.

High Contrast 1

• Contrast ratio: 19.56:1.

  High Contrast 2

  

• Contrast ratio: 15.30:1

  High Contrast 3/4

  

• Contrast ratio: 21:1.

Those high contrasts would certainly suggest that a "high contrast" preference is one much higher than the WCAG values. If the inverse is true then perhaps a low contrast is also much lower? It would be nice to get some input from someone who knows why colors like that were chosen and then build a decision about contrast thresholds off of that.

[frivoal]

It would be nice to get some input from someone who knows why

One reason why low contrast gets chosen is that for some people with dyslexia, high (or even normal) contrast gives the impression that letters are shining / glimmering, which makes things hard to read. Low contrast (and / or light-on-dark) mitigate that effect. I don't know where the threshold in terms of contrast would be, though. @MurakamiShinyu, would you (or Yumi) have some information about that?

[css-meeting-bot]

The CSS Working Group just discussed Inferring contrast preference from forced colors, and agreed to the following:

• RESOLVED: no change: not defining contrast thresholds

The full IRC log of that discussion

<fantasai> Topic: Inferring contrast preference from forced colors
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/5224
<fantasai> florian: When you have forced colors
<fantasai> florian: when the user has said "I want this foreground color and that background color"
<fantasai> florian: There is guidance that if the UA knows if that combination is high contrast, should match (prefers-contrast: high)
<fantasai> florian: and if combo is low contrast, should match (prefers-contrast: low)
<fantasai> florian: Question is what's the thresholds
<fantasai> florian: We have a known set of colors here from the user, so we can calculate the ratio
<fantasai> florian: maybe we want interop among browsers?
<fantasai> florian: one possibility is to hook into WCAG levels
<fantasai> florian: but WCAG is AAA is about high contrast enough to be readable, not very high contrast
<fantasai> florian: and WCAG AA is reasonably high contrast
<Rossen_> q+
<fantasai> florian: If we want a number, I suspect these aren't the ones we want
<astearns> ack fantasai
<astearns> ack Rossen_
<fantasai> fantasai: I propose leaving this up to the UA, to allow experimentation and let browsers figure out the good answers
<fantasai> fantasai: Maybe revisit a few years in the future.
<fantasai> Rossen_: I say, yes, definitely the browser should do this
<fantasai> Rossen_: wrt what are the ratios
<fantasai> Rossen_: there are some guidelines, e.g. Microsoft has some guidelines for contrast ratios in all of our products
<fantasai> Rossen_: Fairly in line with WCAG
<florian> q?
<fantasai> Rossen_: However we decide on the precise values, I don't believe we're the group for deciding that
<fantasai> Rossen_: Not sure it's the browsers themselves, but some combination of a11y WG or WCAG as well as some of the companies who own a11y guidelines
<fantasai> Rossen_: Together should be able to figure it out
<fantasai> Rossen_: I also agree, let's not have specific numbers
<fantasai> fantasai: Propose closing no change, we will not define here. Maybe in 3-5 years we can revisit.
<fantasai> Rossen_: Maybe referencing ohter things like WCAG
<fantasai> florian: I don't think WCAG is appropriate reference, it's guideline for general contrast, not high contrast
<fantasai> RESOLVED: no change: not defining contrast thresholds

[frivoal]

@ZekeMedley The CSSWG has confirmed that a contrast preference should be inferred from forced colors, but decided not to include specific thresholds at this point. Please see the minutes in https://github.com/w3c/csswg-drafts/issues/5224#issuecomment-666526051 for rationale. I hope this is acceptable to you

[0xekez]

Hi @frivoal. This sounds good to me :) I appreciate you taking the time to add some information about this to the spec and discussing it with the WG.

[Myndex]

It would be nice to get some input from someone who knows why

Hi @ZekeMedley and HI @frivoal

One reason why low contrast gets chosen is that for some people with dyslexia, high (or even normal) contrast gives the impression that letters are shining / glimmering, which makes things hard to read. Low contrast (and / or light-on-dark) mitigate that effect.

"Reduced" contrast for user needs due to ocular glare, or even neurological, or cognitive, are often related first to excessive total luminance relative to the eye's light adaptation level. The easy example is facing headlights at night. But on displays the "excessive" contrast is more related to displays set too bright for the environment, and in particular large bold stimuli at a very high contrast.

BUT: not necessarily body text, as very small thin fonts need very high luminance contrast to offset the low perceived contrast caused by the high spatial frequency of the small thin font. That is, YES use caution with excessive contrast with very bright displays and big bold headlines or elements, but don't cheat the readability of a column of body text.

In short: Headlines larger than 48px, restrain contrast to APCA 120 L^c. If also bold, under 100 L^c is a good idea. But 16px body text? 120-125 L^c is ideal. (That's about WCAG 11:1.)

Another aspect of this is how much detail is there in the BLUE channel?

Here on "terrible-for-accessibility-GitHub™", the bright white BG and dark text is an APCA value of 131 L^c which is equivalent to WCAG 14:1 — but it's not the "contrast" that makes it difficult, it's the high luminance of the BG (96 Y) relative to adaptation if your monitor is set bright and the room is too dark. When I'm at sites like this I either turn down the monitor's peak luminance level, or use the dark mode extension and invert the colors.

The Blue Trick

When designing for readable columns of body text, here's a trick to make it a less glarry: If the BG uses a lot of blue (and a white background uses maximum blue), then add BLUE to the TEXT color as this reduces the detail in the blue channel, reducing glare & chromatic aberration.

Examples of Blue Detail Reduction:

Using the APCA Contrast Calculator let's consider two color pairs.

Depending on the condition of your eyes, you may find the top version font sample squares to have a "scintillating" effect. The background has zero blue, and the text is only blue. There is good contrast at 105 L^c but this is a bad color combo for text due to glare and chromatic aberration, and the very bright BG.

In the second example the BG is lower luminance (81Y vs 92Y) and more importantly, the blue text has the exact same amount of blue as the BG, #008 and #ee8. This means there is literally no detail in blue, just a flat dark blue field. And yet the contrast here is higher at 120. In the first example, the blue detail level is #00F against a #FF0 BG.

Here are larger examples, and the kind of very large elements where excessive contrast should be cautioned against:

But notice again that it's not the contrast amount so much as the higher luminance, and the interfering saturation and side effects of glare/CA that makes the first example problematic. if you have young eyes, you may not notice the glare or scintillation effects in the first example, but I can tell you that the first example is difficult for me to look at.

Side Note: If you're wondering why the first blue/yellow is reporting a lower contrast but seems "more vibrant" it is in part because APCA is interested in critical contrast for best readability, and so this implementation discounts chroma/saturation/hue contrasts and reports only calculated luminance contrast. It is ample luminance contrast that is needed for best readability, with hopefully minimal interference from opponent colors, saturation, CA, glare, etc.

Cheers,

Andy

[frivoal]

@Myndex, sorry I failed to notice your comment earlier. This is a fantastically informative comment, thank you.

At the same time, I am not entirely sure what we should do to the spec, if anything, based on this information. Do you think this should influence the mediaqueries spec in anyway? I'm wondering if this might actually be better input to something like WCAG instead.

[Myndex]

@Myndex, sorry I failed to notice your comment earlier. This is a fantastically informative comment, thank you.

At the same time, I am not entirely sure what we should do to the spec, if anything, based on this information. Do you think this should influence the mediaqueries spec in anyway? I'm wondering if this might actually be better input to something like WCAG instead.

Hey @frivoal Thank you for the kind words.

One of the reasons I mentioned this is the APCA is part of WCAG 3.0 (aka Silver) and indicates future contrast prediction methods.

But as far as what to do with the spec "today" — probably can't do too much until WCAG 3.0 is "officially adopted" but the method and math behind APCA is so different that I've attempted to be proactive in raising awareness regarding the future WCAG specs, and particularly here as "prefers contrast" is directly an accessibility thing.

One thing I've notices is the W3 is sufficiently large that there is not always complete information about what is going on in the various working groups (something we are working to change in the low vision task force of the AGWG).

Andy

[frivoal]

For now, we're leaving it up to the individual UA to figure out what is high or low contrast. I think we should continue doing that for quite some time, but possibly we could have an informative link to the kind of contrast logic you've mentioned, to help engineers working on this look up the right references. What would be a good resource to point to?

[Myndex]

For now, we're leaving it up to the individual UA to figure out what is high or low contrast. I think we should continue doing that for quite some time, but possibly we could have an informative link to the kind of contrast logic you've mentioned, to help engineers working on this look up the right references. What would be a good resource to point to?

Hi @frivoal

There is a technology demonstrator which includes a "Research Mode" with interactive experiments. This demonstrates the APCA (Advanced Perceptual Contrast Algorithm) which predicts perceived suprathreshold contrast of text against a solid background for self-illuminated displays:
https://www.myndex.com/SAPC/

There is also a simplified version of the tool, which only indicates the "ideal minimum" contrast, intended for guidance for web designers:
https://www.myndex.com/APCA/

And the GitHub repository which has additional information and links to resources:
https://github.com/Myndex/SAPC-APCA

And I am happy to answer any questions regarding the method or implementation.

But wait there's more

One of the things that became very apparent over the last two years of research is that contrast is not as simple as the difference between two colors. There are any other important aspects to consider especially spacial frequency, which for our purposes means the weight and size of the font, and the spacing of letters and lines. But also padding, overall page luminance, ambient, etc etc all play a roll.

Luminance contrast is most important for readability, not chroma/hue contrast, except that some hue/saturation combinations can interfere with readability.

Importantly, some people need a lower contrast just as some people need a higher contrast. Those that need a lower contrast is most associated with low spatial frequencies (i.e. large bold letters or lines) those that need a higher contrast is especially noticeable in high spatial frequencies (small and thin fonts).

The APCA uses lookup tables to assist in taking factors like this into account, so small thin fonts need a substantially higher contrast than large bold fonts.

Implication

I mention this because the implication is that someone that wants a lower contrast more than likely wants the contrast of big/bold lowered more than the contrast of small/thin (and may not want small/thin lowered at all). Meanwhile someone that wants higher contrast probably wants small.thin raised more than that for big/bold.

RELATED

Similarly, someone that needs text increased in size to read does not want all text increased by a single percentage, but wants the smallest text increased to their minimum critical size, and the larger text on the page only increased enough to be larger, but not increased by the same percentage. I.e. if you have a 16px font and a 28px font, and someone with poor acuity needs a minimum of 32px, then increase the 16px to 200% (to 32px), but don't increase the 28px font to 200%, (56px) instead only increase it to 150%, or 42px.

TL;DR

I.e. neither contrast changes nor zoom factors apply equally to all the content on a page, but have significant and non-trivial requirements for relative and context sensitive adjustments to accommodate the needs of each individual user.

Andy