High contrast mode is not dark mode. They are two different modes and need different approaches.
High contrast mode is designed to improve readability and push aside all the fancy design ornaments and really allow the user to get to the content itself – or better said text.
It is about reducing the design noise and in practice only get borders and text to simplify it – everything should be readable is the main goal!
We can trace it back to WCAG success criterion Visual Presentation – 1.4.8. (level AAA) where it defines; Foreground and background colors can be selected by the user.
So colors could be set by user but at the same time all texts, buttons, and other important elements must be perceivable to the same extent as without users customized settings.
Why is high contrast mode important
According to WebAIM’s survey – a third of users with low vision is using high contrast mode very frequently (opens in new window). So – screen reader and zooming lead, but high contrast is also quite a popular choice.
It is not a design choice and should not be treated like that
Personally I can see the biggest difference comparing dark mode and high contrast mode in exactly this – dark mode should be designed while high contrast mode should only be supported. Designers should really define dark mode variation of the page or an app while it is not so crucial to do in the high contrast mode. The rules of coding the UI for high contrast mode are more on the developers, especially front-end developers.
The colors in high contrast mode are being forced on the design
Yes, there is actually a set of CSS standards that enable developers to check for high contrast mode or even properties that can control user agent forced color;
- Media query for forced color palette detection: “forced-colors” (opens in new window) – when active the user agent will provide the color palette through the CSS,
- User agent can and will override the author’s colors and author can prevent colors being overridden with “force-color-adjust” (opens in new window) property on a element level,
- Authors can even get the colors that user has chosen with “system-color” (opens in new window) keyword, so it is easier to really think about the users preferences when coding the elements.
Please be aware that support in the cross-browser world is still limited (opens in new window), but that does not mean it does not matter.
Best practices for high contrast mode
As always – use semantic markup is the first and most obvious rule. Another thing to understand is that outline matters much more than in normal mode – as high contrast mode all box-shadows can disappear it is important to set the outline to get it done properly in the high contrast mode.
Background images can be ignored, so if you are using them make sure the content has alternative text or alternative presentation.
SVG can even become invisible, so please be sure to think of all the icons for buttons and infographics that may be accessible in normal mode but could disappear in high contrast mode (think black SVG on a black background). This can be prevented when defining SVG fill colors but those are not always possible, so make sure to test.
As always – manual test is crucial
I have not been able to find an automatic tool that can do the analysis so please be sure to test it manually. It will maybe be possible in the future with the help of the new CSS force-color media query, when the support gets better, but as we know – manual testing is still best.
Additional resources for high contrast mode
Here are some additional resources I stumbled upon and may give you deeper overviews;
- Microsoft on high contrast mode (opens in new window),
- Microsoft post on cooperation with Chromium on the new CSS for high contrast mode (opens in new window),
- Accessabiliy.com on issues concerning high contrast mode on Windows (opens in new window),
- Accessible SVGs in high contrast mode (opens in new window).