Quick Note on ARIA and Windows High Contrast Mode
When testing websites and apps in Windows High Contrast Mode (WHCM), there are two issues I’ve come across over again and again.
WHCM cares not for your ARIA attributes
While ARIA attributes (representing roles, states and properties) coupled with CSS can be used to alter the semantics and visual appearance of an element (for example, creating custom buttons or links), WHCM can pierce through these shenanigans. The OS-level user styles will ignore the semantic modifications to these elements, and will provide high contrast coloring based on the element’s base semantics.
Consider the following:

But when Windows High Contrast Mode is enabled, many of these “links” are not colored as one might expect:

With WHCM turned on the true links receive the high contrast link coloring. The other elements that lacked an href
attribute or were modified by ARIA to become links, do not match the high contrast coloring of links.
Note the faux link within the paragraph, where color alone was used to designate it as a link, as it is now indistinguishable from the static text around it.
For another example, similar issues can occur if using aria-disabled="true"
and JavaScript to disable a button
element, rather than using HTML’s disabled
attribute.

button
element and button
with aria-disabled="true"
are similarly styled when WHCM is enabled. The button
with the disabled
attribute is the only element that receives the disabled coloring in WHCM.
You can review the button
demo out on CodePen, and if you do, you may notice I have the following CSS commented out:
[aria-disabled] {
border: 4px solid HighlightText;
}
If you enable that styling you’ll notice that the border width of the aria-disabled
button is increased, but the color does not change, even though the color value is respected in WHCM.
Natively disabled controls (buttons in this example) receive specific WHCM coloring when disabled. Until ARIA attributes are respected by WHCM, there won’t be a good way to mimic disabled styling on a button using aria-disabled
.
For now, the best way to mitigate these, and other potentially incorrectly colored elements is to rely on the native HTML elements instead.
Background images are (mostly) ignored
While the coloring of elements not matching expectations can be a bit annoying and/or confusing, the complete disappearance of important imagery can be problematic. Especially if the imagery is the primary indicator of an actionable element (e.g. icon buttons).
With the exception of Microsoft Edge (pre-Chromium), IE11 and Firefox do not support CSS background images when High Contrast Mode is enabled. To mitigate issues with this, I often have to advise developers to ensure any imagery that is visually important should be coded as an inline img
or svg
element.
The following background image demo shows two implementations for a background image. One as a CSS background image and the other as an absolutely positioned img
element, with content overlaid on top of it.
See the Pen a test for background images in HCM by Scott (@scottohara) on CodePen.
The following image shows what the CodePen demo looks like with WHCM turned on:
Another example using an SVG background image for a button. Try it out with WHCM enabled:
See the Pen icon button by Scott (@scottohara) on CodePen.
Read more about Windows High Contrast Mode
Off-colored elements and disappearing background images just graze the surface of things one should be aware of when designing for designing for high contrast mode.
For more information, check out the following links:
- Microsoft Is Working on a High Contrast Mode and Caret Browsing for Chromium by Ryan Maskell, 2019
- Microsoft Support: Use high contrast mode
- How to use
-ms-high-contrast
by Greg Whitworth, 2017 - How users change colours on websites by Anika Henke, 2017
- OS: High Contrast versus Inverted Colors by Adrian Roselli, 2017
- Accessible SVGs in High Contrast Mode by Eric Bailey , 2016
- Windows High Contrast and Background Images by Terrill Thompson, 2011