Problem/Motivation

Lots of visual design components in Seven, Bartik, and Umami themes break when Windows High-Contrast mode is used.
Many useful design affordances are lost:

  • Missing borders
  • Missing icons...
  • ... hence some buttons have no visual labels at all. (e.g. Bartik search block button, Toolbar orientation button).
  • ... and some links have no visual labels at all. (e.g. Bartik RSS feed icon, front page of Standard installation profile.
  • Missing primary/secondary emphasis for buttons.

Effects of Windows High Contrast mode

It's a user setting at the platform level - a Windows user chooses a High Contrast theme, and it applies to all desktop applications. Internet Explorer, Edge and Firefox respect this platform setting, and force similar changes upon web browser content. (Conversely, Chrome and Opera browsers do not change web content in response to this platform setting.)

The main effects of Windows High Contrast mode on browser content are as follows:

  • Text colours are overridden. If the user chose the yellow-on-black HC theme, then browser content becomes yellow-on-black.
  • Link text colour is overridden. This is a different colour to the plain text, and differs between IE/Edge and Firefox. E.g. when the user chooses Yellow-on-black HC theme, link colour is magenta.
  • CSS background images are removed. The assumption is that they will interfere with clarity of any text which is on top.
  • Likewise, CSS gradients are removed.
  • CSS border-color is overridden, and matches the plain text or link colour, however:
    • border-width, border-style, and border-radius are unchanged.
    • Note that border-color: transparent; is overridden too. These borders become visible.
  • CSS outline-color is overridden, and matches the plain text or link colour, however:
    • outline-width, and outline-style are unchanged.
    • Note that outline-color: transparent; is overridden too. These outlines become visible.
  • CSS box-shadows are removed.
  • Text-decoration: none; is respected.
  • Most font properties are respected, with the obvious exception of colour.
  • CSS currentColor is changed to match the text colour of the high-contrast Windows theme.
  • A vendor-specific media query is available, which becomes active in Internet Explorer and Edge when a user has selected a Windows High Contrast theme. (Note, Firefox doesn't respond to this media query.) MS High Contrast Media Query Test Page.

Proposed resolution

Use individual issues to fix different components. Some will be easier than others. Commit small improvements one at a time, so Drupal gets gradually better in Windows high-contrast mode over time.
For the most part we expect to achieve this with CSS tweaks, using knowledge of the above HC effects to deliver something which works:

  • Prefer to achieve design affordances which are a close equivalence to the full-colour space.
  • Resort to alternative affordances using the HC media query, if we have to.

Remaining tasks

Screen-shot reconnaissance! Find as many differences as we can between full-colour designs and how they are rendered in windows high contrast mode.

User interface changes

No Changes to current visual designs, in the full-colour space.
This is about the existing designs remaining intact when using MS Windows High-Contrast mode (an assistive tech).

API changes

None.

Data model changes

None.

Members fund testing for the Drupal project. Drupal Association Learn more

Comments

andrewmacpherson created an issue. See original summary.

andrewmacpherson’s picture

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.

andrewmacpherson’s picture

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

mgifford’s picture

Thanks for doing this Andrew! There are a lot of users who use Windows High Contrast mode and it is an area where Drupal hasn't gotten enough testing.

andrewmacpherson’s picture

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.

mgifford’s picture

Might be able to make use of new (now draft) Media Queries https://drafts.csswg.org/mediaqueries-5/#inverted

andrewmacpherson’s picture

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.

mgifford’s picture

Agreed about making improvements without the media query. Just nice to know that they are there and that there is reasonable support already.

andrewmacpherson’s picture

Issue tags: +atag

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

Bojhan’s picture

Why would we not just optimize for high-contrast mode of a platform if we can target it as media query? (it should mostly be defaulting to standard styling). I am not a big fan of the custom "high contrast" themes/modes that override platform defaults.

andrewmacpherson’s picture

@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.

andrewmacpherson’s picture

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?
andrewmacpherson’s picture

Issue summary: View changes

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

andrewmacpherson’s picture

Issue summary: View changes
andrewmacpherson’s picture

Issue summary: View changes
andrewmacpherson’s picture

Issue summary: View changes
andrewmacpherson’s picture

Issue summary: View changes

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.

yoroy’s picture

Could this “simply” be one actionable part of the overall plan in #2864791: Implement new Success Criteria from WCAG 2.1? Just checking to see if this needs to be its own idea. If it's part of the plan, then by all means go for it. This issue could then be moved to the regular core queue.

mgifford’s picture

I don't think that we need WCAG 2.1 to deal with these issues with Windows High-Contrast mode. Just a oversight in previous reviews that Andrew caught.

andrewmacpherson’s picture

Issue summary: View changes

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.

andrewmacpherson’s picture

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

andrewmacpherson’s picture

Issue summary: View changes
andrewmacpherson’s picture

Issue tags: +high contrast
andrewmacpherson’s picture

Issue summary: View changes

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.

andrewmacpherson’s picture

Issue summary: View changes

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

MS High Contrast Media Query Test Page