Make core themes more robust in Windows High-Contrast mode

I explained some of the problems in my talk at DrupalCon Dublin. It's high time I got this stuff down in the issue queue. I'll flesh this out with examples and techniques, and open some child issues for specific components. I already have a folder full of screenshots and some messy patch attempts.

Some screenshots to start with, these show a number of issues. I'll work them into the main issue summary later.

It's had a fair amount of testing already, but the results are still living in my head ( and hard-drive). I need to brain-dump a large, vague plan into small concrete issues.

There is a vendor-specific media query for ms-high-contrast too, which comes on when MS High Contrast themes are enabled. The interesting thing is that while it is specific to one OS, it is recognized by several browsers: MSIE, Edge, and Firefox.

I think we can make a lot of improvements without a media query though.

This plan likely qualifies as addressing ATAG 2.0 A.3.6.3 Apply Platform Settings, yay!

@bojhan that's exactly what this issue is about - responding to the platform settings. I'm not proposing a separate drupal theme, just making the existing ones play nicer with Windows.

Example improvements using the Windows High Contrast media query:

• The primary-button-blue vs secondary-button-grey styling in Seven is lost in Windows High-Contrast mode, because it's a colour-only distinction. We could provide an alternate primary button style in the Windows High-Contrast media query, e.g. a shape difference using thicker border and/or bigger padding. Normal colour space style would be unaffected, which makes design sign-off simpler.

Example improvements which would NOT use the windows high-contrast media query:

• Alternatively, we could enhance the primary/secondary button distinction by for ALL users, by making it slightly bigger in the default style, without employing the Windows High Contrast media query.

As a design change in normal colour space, I expect this would require sign-off from design/usability/product-manager roles.

• Currently our icons disappear from the toolbar etc in Windows High-Contrast mode. Fixable by change our icons from CSS background-image: url() to CSS content: url(). No need to employ the media query for this fix.

I don't think we should shove all improvements inside this media query though, because:

• It would mean those improvements were only passed to people using Windows High Contrast specifically. Some of these improvements could also be passed to users who employ other personalization techniques. With careful use of CSS, users employing a userstyles.css approach to change colours could also benefit. This is hard to evaluate however, so it's just a secondary benefit.
• It would be more styles to maintain and test.
• UPDATE: It's an alternative accommodations solution, versus an inclusive design approach.

I have lots more concrete examples in my head. I need to find time to write them up as child issues with patches and screenshots.

The reason this issue addresses Windows High Contrast mode specifically, is that we can actually affect it with good/bad CSS techniques. Right now some things are broken and it's up to us to improve it.

Other platforms have accessibility features for changing colour spaces, but AFAIK these are outside of our control:

• Colour inversion: Android, macOS, iOS, ...
• Colour adaptation: Android has a setting to tweak colours for users with particular forms of colour blindnesss
• Contrast enhancement: Android has a setting to automatically tweak fg/bg colours slightly
• White point adjustment: iOS
• Others?

Updating the issue summary, adding a section on the known effects of Windows High-Contrast browsers on web content.

Hmm, I've been referring to the "normal" colour space a lot, but this probably counts as able-ist language. I think calling it the "full-colour space" would be better.

Closing #2852700: 508 Compliance Issue - User Selected High Contrast as a duplicate of this. Updating issue summary to include the specific missing icons mentioned there.

We briefly discussed doing this for Umami, but didn't have time. It wasn't pursuing in Umami when the Bartik/Seven plan hasn't gone far yet.

I did keep Windows High Contrast in mind while reviewing the Umami CSS code a few weeks before it was committed to core. My idea was to look though the CSS for keywords like transparent, opacity, box-shadow. This would be a first pass at looking for things that I'd already seen go wrong in Windows High Contrast mode, like using transparent borders for spacing. My impression was that there were very few of these in Umami, but the main menu was indicating active menu trail by changing a transparent border to a coloured one (in WinHC, it would look like all were underlined...)

See: https://github.com/lauriii/umami/issues/137

Firefox on Windows responds when a Windows High Contrast theme is active, but DOESN'T support the -ms-high-contrast CSS media query. There was some discussion in the Mozilla bugtracker about whether to implement this media query, but they seem to have decided against it.

I made a test page for the MS HC media query.

MS High Contrast Media Query Test Page

High contrast support is being actively pursued in the new Claro theme, which is good news. That has to go through an experimental alpha/beta/stable period before it can be used as the default theme in core.

It's still worth pursuing high-contrast support in Seven and Bartik. The likelihood is that Seven will be supported in D9, and removed in D10. See #3066007-19: Roadmap to stabilize Claro.

FWIW, the Umami theme does pretty well, but has a few issues with icons and the active menu trail.