[mediaqueries] Media Feature: "increase contrast" and/or "reduce transparency" user settings

[cookiecrook]

Tracking issue for Media Feature "prefers-reduced-transparency"

Discussed in thread:
https://lists.w3.org/Archives/Public/www-style/2016Feb/0037.html

For spec:
https://drafts.csswg.org/mediaqueries/

[cookiecrook]

Allows web developers to know they should switch certain translucent views to an opaque or significantly less translucent rendering. Platform preference is shipping on iOS, macOS, watchOS, and tvOS. This can greatly increase readability for individuals with certain vision impairments.

[cookiecrook]

Changing these user settings don't change the rendering of anything. It just conveys a user preference that allows the frameworks, native apps, or web apps to adjust for this user preference/desire/need.

I should also note these proposed names don't fit well within the "none or truthy" pattern of some existing media features. It'd be awkward to specify that prefers-reduced-transparency: none means "user is okay with translucent UI." The none value here may be open to misinterpretation, so considering a default or no-preference value that behaves like none for boolean comparisons.

prefers-reduced-transparency: [ default | reduce ];
prefers-reduced-transparency: [ no-preference | reduce ];

[cookiecrook]

Based on suggestion by @astearns in #442

reduce-transparency-preference: [ none | reduce ]
increase-opacity-preference: [ none | increase ]

[cookiecrook]

The core reason this needs to expose a user preference rather than change something about the view is because UI varies greatly. There's no way a UA can reliably reduce transparency on behalf of the user and still guarantee a readable, usable interface. Exposing the pref gives authors a way to do this appropriately within the context of their own interfaces.

[frivoal]

(this comment is equally valid for this issue and for #442)

This seems very reasonable and useful to me.

1. I am a little worried about adding this in isolation though. I believe this is an OS X / iOS specific preference. If we list all (or even just many) such settings from all (or even just many) OSes one by one, I worry that we will end up with a very long list, from which each UA vendor will only pick a few, and authors will themselves also only respond to the few they know/care about. The intersection of both meaning that for end users, the odds of this actually working might be pretty low. Maybe we can spec anything we run into, wait a few years to see what sticks, and deprecate the rest, but I am not sure this is a great approach.

I think It would be very useful to see a broad survey of all such accessibility/preference settings across major OSes to determine:

• If we want to expose these one by one, or if that's too fine grained and we need to find some higher level grouping
• If several OSes deal with the same concern in somewhat different ways, to see whether and how we can design the MQ to have useful cross-OS semantics

2. I believe this is one of the topics, together for example with color inversion and contrast boosting or reduction where OS/UA vendors may either decide to request the content to adapt itself to the preference or to forcibly do the adjustment and (possibly) let the content know the adjustment has been done so that it can avoid doing things that conflict with this adjustment.

reduced-transparency: none | preferred | forced;
reduced-motion: none | preferred | forced;
color-invert: none | preferred | forced;
save-ink: none | preferred | forced;

Not all OSes will use all modes, but it would be helpful to authors to know what's happening to them.

How do handle the preferred variant should be fairly obvious, but for the rest:

• in forced color invert, authors should double invert the photographs and get rid of shadows (assuming it is done at the pixel level as on OS X, if there is "smart" forced color invert, we probably need a value to distinguish).
• in forced save-ink, authors should know not to rely on backgrounds to keep things readable, as they may not be displayed.
• in forced reduced animation, authors should expect that the UA may not run animations or transitions, and should make sure the page is readable/usable without them
• in forced reduced transparency, authors should expect that the UA may always set the alpha channel to 1, and should not rely on transparency actually happening to keep the page readable/usable

I think this design is likely to be sound, but I would like second opinions, and to evaluate it against a few more media queries and a few more OSes to see if it holds up.

[cookiecrook]

Windows has a "high contrast" mode that forces colors to black/white binaries and removes background images. That may be equivalent to a increase-contrast: force; where Apple's would be equivalent to increase-contrast: prefer;as it more subtly increases the contrast of the artwork for each UI control.

PS. Let's avoid "preferred" given the commonality of spelling errors associated with double characters (referrer/referer) and variant localized spellings (labelled/labeled).

[cookiecrook]

For that matter, we could possibly roll the "increase foreground/background contrast" and "reduce transparency" into one media feature if the granularity of each isn't essential.

FWIW, we tried something like this in the Indie UI User Context draft. See the following example demonstrating how Microsoft's high-contrast media feature proposal fit into an MF we called "user contrast"
https://www.w3.org/TR/indie-ui-context/#media-feature-user-contrast

[frivoal]

Windows has a "high contrast" mode that forces colors to black/white binaries and removes background images. That may be equivalent to a increase-contrast: force; where Apple's would be equivalent to increase-contrast: prefer;as it more subtly increases the contrast of the artwork for each UI control.

Yes, this is exactly the kind of thing I'm talking about.

Let's avoid "preferred" given the commonality of spelling errors associated with double characters

I make the mistake too, so sure.

For that matter, we could possibly roll the "increase foreground/background contrast" and "reduce transparency" into one media feature if the granularity of each isn't essential.

Possibly. I'd like to get feedback about this from somebody who knows about the various disabilities that lead various people to seek one or the other of these settings. If they are the same, or at least if there is no conflict, this kind of merging could be a good thing.

[cookiecrook]

I'd like to get feedback about this from somebody who knows about the various disabilities that lead various people to seek one or the other of these settings. If they are the same, or at least if there is no conflict, this kind of merging could be a good thing.

In our experience, they are used for the same purpose, but both are not necessarily used by the same people (some use both, others don't). Low vision disabilities are too diverse to make sweeping generalizations like, "People who what higher contrast text also want zero transparency" but it might be okay to generalize an interface change such as: "If the only relevant CSS media feature is prefers-increased-contrast then as the web page author, maybe I should make both the color contrast change and the opacity change."

It's also possible that people just don't use both simultaneously to avoid existing implementation bugs, and that they'd enable both once the remaining bugs are fixed in first-, second-, and third-party app. For example, a popular app that rhymes with Zulu can look bad when you enable 'reduce transparency' on tvOS.

[frivoal]

So long as we don't have a case of "some people who need no transparency also need low contrast", then merging it is OK. That's kind of the question I'd like to put to accessibility experts (if you are one, let me know, so that I can stop addressing you as an abstract group of people).

If that's cleared, merging is an option. Whether it is better is a bit of a separate question. I'd be tempted to say yes, but that's just a highly subjective opinion about the best way to design the API to maximize its chances of being used often and across platforms.

[cookiecrook]

So long as we don't have a case of "some people who need no transparency also need low contrast", then merging it is OK. That's kind of the question I'd like to put to accessibility experts (if you are one, let me know, so that I can stop addressing you as an abstract group of people).

I am, though anyone would be foolish to claim they had a definitive answer to that question. I'm certain we can find people who prefer both low contrast colors and an opaque UI. I will ask around. However, determining whether that combination is necessary as a CSS media feature is a more difficult question.

For the time being, I'm comfortable stating that, "most people who use any of the related settings on any platform do so as a way to increase the contrast of the UI." Therefore, I think adding a general "increase contrast" media feature won't preclude us from adding more granular sub-level features (reduce transparency, avoid certain colors, etc.) later if we determine them to be necessary.

[cookiecrook]

Listing related potential media features for contrast and inversion, since "inverted-colors" was also deferred again from CSS MQ Level 4 earlier this year.

• inverted-colors: [none | invert]; (I think a prefer-vs-forced variant is unlikely. People usually prefer dark color schemes rather than complete inversion whenever possible, so inversion is always a 'forced' last result for the user.)

Mutually exclusive user prefs ideas for color

• `prefers-color-scheme: [none | dark-on-light | light-on-dark]; Note: Microsoft calls these black-on-white and white-on-black. IIRC, they used to have a yellow-on-blue; @cyns would know more. See the MSDN page for -ms-high-contrast
• user-color/user-background-color: See the now-defunct IndieUI User Context section on HSLA user-defined foreground/background colors

Example usage of user color MQs and user-pref() variables

@media (user-color) and (user-background-color) {
    html, body {
        /* Syntax for the user-pref variables was to be specified in one of the CSS MQ modules. */
        color: user-pref(color);
        background-color: user-pref(background-color);
    }
}

Example usage of the "-luminosity" suffix for HSLA-based MQs

/* Use default logo that looks good on lighter background colors. */
.logo { background-image: url(./img/logo_light.png);}

/* Note: this example uses the greater-than/less-than syntax likely to be adopted by CSS MQ4. */
@media (user-background-color-luminosity < 40) {
    /* User background color is dark; use logo variant that looks better on dark colors. */
    .logo { background-image: url(./img/logo_dark.png); }
}

[cookiecrook]

My action from TPAC for @frivoal was to list the other known platform-specific contrast-related settings.

1. Google has an "increase contrast" setting on Android that is similar to iOS "darken colors" or macOS "increase contrast" settings. Controls and text colors throughout the system increase the foreground/background contrast ratio, but to my knowledge, Android does not expose this to the Web. Neither does iOS or macOS yet.
2. Microsoft implemented their own vendor-prefixed -ms-high-contrast and -ms-high-contrast-adjust media feature that is very specific to the Windows platform feature. See the MSDN doc links above for more info.

[cookiecrook]

Since transparency was addressed in #1709 and the contrast syntax is being discussed in #2943, I'm going to close my original thread here (#443).