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
No, at the this time. Currently, the High Contrast a11y feature is supported on Windows 7+ platforms only.
--
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.
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
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
--
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.
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
--
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/CAFz-FYxLXFQpfBgmzi_YKq8_W4N35CFjnDcUnG9dxjC3BzJ3SQ%40mail.gmail.com.
Link to entry on the feature dashboard
Don’t have one yet, happy to add it.