Intent to Implement: High Contrast support

[Rossen Atanassov]

Contact emails

Rossen.A...@microsoft.com, Alison...@microsoft.com

Explainer
High Contrast Explainer

Design doc/Spec
Apart from this explainer, the Windows docs detail how High Contrast functions on the Windows platform. The web platform-facing features have been an ongoing discussion in the CSSWG over the years. As this is the most-used Ease of Access feature across Windows, we intend to discuss it with the group again shortly to arrive at a solution that works for all implementations.

Summary

High Contrast was first introduced as a Windows accessibility feature intended to increase the readability of text through color contrast. Individuals with low vision may find it more comfortable to read content when there is a strong contrast between foreground and background colors. High Contrast is a useful feature in increasing the readability of screen-based text for such users.

 

Applications such as the browser can make use of such color themes by propagating them into their web content model. In such implementation the High Contrast colors are propagated to the website content as a set of user agent style overrides, thus increasing and guaranteeing the readability of the web content text.

 

Motivation

The goal of High Contrast is to ensure a certain level of contrast between foreground and background colors. One common problem arises with background images. If text lies atop an image, altering the color of the text in High Contrast will not guarantee its readability. One option would be to override images to allow text readability. This solution, however, is not an ideal one, as it can alter the context of a webpage for users under High Contrast.

 

For extended background on motivations, please refer to the explainer.

Risks

Interoperability Risks
High Contrast theming is currently available only on the Windows platform and supported by Internet Explorer and Edge browsers behind vendor prefixed properties. The popularity of this feature has attracted top properties such as Facebook, YouTube, Microsoft Office etc. to take dependencies on the vendor prefixed behavior.

·       Edge: Shipped

·       Chrome: No signal, extension available

·       Firefox: No signal, extension available

·       Safari: N/A?

·       Web / Framework developers: Positive

             The topic has some public discussions already here https://github.com/w3c/csswg-drafts/issues/1286 and will be discussed on the upcoming CSSWG f2f.

Compatibility Risks
Not anticipated for the non-prefixed CSS media query and property. We intend to arrive at a working solution that will likewise satisfy no compat risks for implementations which choose to support the prefixed versions.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No, at the this time. Currently, the High Contrast a11y feature is supported on Windows 7+ platforms only.

Is this feature fully tested by web-platform-tests?

Part of the implementations will be to add the relevant media query and property override tests.

Link to entry on the feature dashboard

Don’t have one yet, happy to add it.

Requesting approval to ship?

Yes. The functionality will be guarded by experimental flag and won't be enabled by default.

 

Thanks,

Rossen Atanassov

 

 

[Stephen Mcgruer]

Hi Rossen; a quick comment about multi-platform support, with an apology if I've misunderstood the feature.

 

No, at the this time. Currently, the High Contrast a11y feature is supported on Windows 7+ platforms only.

Does the Mac accessibilityDisplayShouldIncreaseContrast property not map to this on that platform?

In addition, there is an accessibility setting for this on Android too (it seems); I can't find any documentation on detecting it, but hopefully it is detectable somehow.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MWHPR21MB0127CF0D5C850E2DD16323689B910%40MWHPR21MB0127.namprd21.prod.outlook.com.

[block.rxc...@gmail.com]

Hi

Is this intents related with `prefers-contrust` in media queries lv5 ?

https://drafts.csswg.org/mediaqueries-5/#prefers-contrast

Explainer saids

```

@media (high-contrast: active) {}

```

but in mq5

```

@media (prefers-contrast: high/low) {}

```

Thanks

Jxck

2019年1月31日木曜日 10時49分17秒 UTC+9 Rossen Atanassov:

[Rossen Atanassov]

Hi Stephen, thanks for the quick response.

 

The Mac setting is quite a bit different as it only applies to UI elements in the Mac shell (not sure on the lingo for these). In terms of guaranteeing readability it doesn’t provide much to users.

 

As for the Adroid one, this is the first I’m reading about it and if that’s similar to what we have on Windows, awesome! I’ll discuss with more folks on the Chrome a11y team to find out.

 

Again, thank you!

Rossen

[Rossen Atanassov]

Hi Jxck,

 

This is somewhat related to prefers-contrast but not exactly as specified there. The major difference of behavior is as currently specified is whether or not the media query specifies a block of rules that are opt-in or opt-out behavior. In other words, does the underlying web platform implementation provide better experience when the user requests high contrast by default (without any web author intervention) or not.

 

The current i2i and explainer are in support of the opt-out behavior where the web platform does what’t right for the user by default and if a web author wants to opt-out (override it) they can.

 

We’ll be discussing all of this during the upcoming CSSWG f2f meeting in February.

 

Thanks,

Rossen

[Yoav Weiss]

Drive-by comment: If the functionality is intended to be behind the experimental flag for the time being, the right answer here is that you're not requesting approval to ship.

  

 

Thanks,

Rossen Atanassov

 

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Rossen Atanassov]

Thanks for the feedback Yoav. Now that you pointed out it makes perfect sense. I must’ve been looking at the wrong examples :) … but I’ll know for future i2i’s.

 

Thanks,

Rossen

 

 

From: Yoav Weiss
Sent: Thursday, January 31, 2019 6:19 AM
To: Rossen Atanassov
Cc: blin...@chromium.org

Subject: Re: [blink-dev] Intent to Implement: High Contrast support

[Dominic Mazzoni]

Thanks very much for proposing this!

It's important to have public spec proposals before implementing a new media query or CSS property. The explainer does a good job of tying those together and explaining the big picture, but I'd like to see some discussion in the appropriate CSS spec communities.

I think it'd be worth considering if this should be merged with the color schemes CSS proposals (e.g. for dark mode). Ideally a web author who customizes their style for dark mode would also want to think about high contrast mode together.

Another consideration is that while this is typically called high contrast mode on Windows for historical reasons, some users may use it to pick a different color scheme, which may actually be low contrast. Since this isn't part of the web standard yet it might make sense to give it an appropriate generic name that reflects its actual behavior (overriding the author's colors with a user-preferred color scheme).

That suggests to me that what we really want is to amend prefers-color-scheme to take no-preference | light | dark | custom, where "custom" implies that the user's foreground and background color will override.

That said, I would definitely like to see an experimental implementation of the "backplate" idea in Blink, that'd be a great option to have.

- Dominic

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

[Martin Šrámek]

Hi Rossen,

Can you please clarify what exactly is entailed in this Intent?

Would we be prompting users to install an extension (like mentioned in the explainer)? Or is that already implemented and this proposal aims to add more native functionality to the browser?

Best regards,

Martin

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFz-FYxLXFQpfBgmzi_YKq8_W4N35CFjnDcUnG9dxjC3BzJ3SQ%40mail.gmail.com.

[Jeffrey Yasskin]

On Wed, Jan 30, 2019 at 5:49 PM 'Rossen Atanassov' via blink-dev <blin...@chromium.org> wrote:

Contact emails

Rossen.A...@microsoft.com, Alison...@microsoft.com

Explainer
High Contrast Explainer

This link to https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/HighContrast/explainer.md is now at https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/Accessibility/HighContrast/explainer.md.

...

Link to entry on the feature dashboard

Don’t have one yet, happy to add it.

Please do add an entry, so it can get updated as the most recent links move around.

Thanks!

Jeffrey

[fantasai]

On 2/5/19 7:24 PM, Dominic Mazzoni wrote:
> Thanks very much for proposing this!
>
> It's important to have public spec proposals before implementing a new media query or CSS property.
> The explainer does a good job of tying those together and explaining the big picture, but I'd like
> to see some discussion in the appropriate CSS spec communities.

I agree with this 100%, and the CSSWG discussed this proposal
and some related proposals from Apple at the February F2F,
minutes here:
https://lists.w3.org/Archives/Public/www-style/2019Apr/0004.html

This required some follow-up discussion and design work, which
resulted in the discussions here:
https://github.com/w3c/csswg-drafts/issues/3807

The feature is now drafted into several CSSWG modules:
https://drafts.csswg.org/mediaqueries-5/#forced-colors [not yet FPWD]
https://drafts.csswg.org/css-color-adjust-1/#forced [recently cleared for FPWD]
lastly https://github.com/w3c/csswg-drafts/issues/3804 pending edits to css-color-4

These specifications have not yet received wide review. (FPWD only
indicates the CSSWG agrees to work on it and, having reviewed it
internally, agrees on the general direction of the draft.)

In terms of open issues that would significantly impact compat,
there's this one which is open:
https://github.com/w3c/csswg-drafts/issues/3880

~fantasai