Internet Explorer and Edge have a vendor-prefixed
-ms-high-contrast media feature which allows developers to detect if the user is currently in Windows High Contrast Mode, and to apply specific additional style rules in that situation.
The media feature supports three values that can be tested:
white-on-black. While on the face this feature seems pretty useful, it arguably provides authors with very little actionable information.
Windows High Contrast Mode provides users with a selection of different ready-made high-contrast themes. For instance, in Windows 10 the user can choose between “High Contrast #1”, “High Contrast #2”, “High Contrast Black” and “High Contrast White”. In addition, users can redefine any of the colours used and save their own custom high contrast theme.
Regardless of which specific colour scheme a user has chosen,
-ms-high-contrast:active will evaluate to true when any of these high contrast themes are enabled.
However, authors have no indication of what kind of colour scheme the user has actually enabled, so it’s not really appropriate for them to try and force a particular colour (possibly with the addition of
-ms-high-contrast-adjust:none) or to load alternative resources such as images with “pre-baked” colors. Most notably, authors can’t really infer that
-ms-high-contrast:active means the default “light colours on dark background” (and then perhaps try to force single-colour elements to use a white foreground colour), as the user may well have a colour scheme that favors “dark colours on light background” instead.
All authors can really do here is to ensure that their styles will “work well” in a high-contrast setting – and as so much of this will depend on all the (undocumented) changes that the operating system and the browser will make to the author’s CSS, there is really not a lot of mileage here beyond some of the more drastic changes such as avoiding the use of background images (which will not be rendered in high contrast modes in Internet Explorer) and instead making alternative visually hidden text for these images visible, if present.
The values of
black-on-white initially appear to overcome the shortcoming of active: not only does the author know that Windows High Contrast Mode is enabled, but they can also at least get an indication of the type of high contrast colour theme the user has chosen. So if
-ms-high-contrast:white-on-black is active, they could introduce additional style rules (and force particular colours using
-ms-high-contrast-adjust:none) that work well on a black background.
black-on-white are very specific values, and they depend entirely on whether or not the current high contrast theme uses pure white and pure black for the respective foreground/background colours. This is of course the case for the default “High Contrast Black” and “High Contrast White” themes. As users can customise the specific colours used by Windows High Contrast Mode themes, every time even a custom theme uses pure white for text and pure black for background, the related
-ms-high-contrast:white-on-black will evaluate to true (and vice-versa for
black-on-white). But as soon as a user/theme strays slightly from these very specific combinations, the queries return false. For instance, using pure white foreground text on a dark blue, rather than black, background results in
-ms-high-contrast:white-on-black quite logically evaluating to false. As such, these two values are of limited use, and will only evaluate to true in very specific conditions.
In summary, while on the face the
-ms-high-contrast media feature may look useful for authors, in practice the information that an author can get from querying this feature is limited (in the case of
-ms-high-contrast:active) and only applicable in some very specific situations (for