[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".