High-contrast mode serves low vision; it is not dark mode
Aliases: high-contrast theme · dark vs high contrast
What it is
Someone labels the dark-theme switch “high contrast”, or answers a high-contrast need with a fashionable dark-grey skin. A low-vision user turns it on and the washes are still there, the pale grey type is still there — only the ground went dark. High-contrast mode pulls figure off ground for people who cannot see fine grey differences. Dark mode changes the lighting — less glare, night comfort, sometimes power. They can be on together. They cannot stand in for each other.
Why it happens
Low vision, some cataracts, and reduced contrast sensitivity lose the midtones. Cards divided by pale grey, buttons divided by hairlines, are simply not there. High contrast collapses the world into as few light/dark classes as possible so shape comes back. Dark mode does not promise that: it can sit, stylishly, in a low-contrast dark register, even harder to parse than the light theme.
Different purposes, different success tests. Dark mode succeeds when “it is still that product, just less harsh at night”. High contrast succeeds when “control edges and type can still be pointed at once mid-greys are almost gone”. Using dark to fill the high-contrast slot leaves the midtones that should have been cut.
Studying it
Make light, dark and high-contrast versions of one UI. Recruit observers with reduced contrast sensitivity (or simulate with blur / contrast reduction, and say it is only an approximation). Tasks: point to button edges, separate adjacent cards, read secondary type. Independent variable: theme. Dependent variables: pointing accuracy, whether dark is mistaken for “contrast enough”.
Simulated low vision is not a substitute; a blur kernel is not a contrast-sensitivity loss. Report the method.
Where it stops holding
- Some people only prefer dark and do not need high contrast; forcing high contrast on them looks crude and loud.
- Some people need high contrast as dark type on a light ground, not light type on dark. High contrast is not a subset of dark.
- OS-level high contrast will recolour system controls. A product’s own high-contrast theme, if it shares the purpose, is still a visual-design decision — not the same problem as custom widgets distorting under a system toggle.
Applying it
- Split dark and high contrast into two switches or two themes, and say who each is for.
- Accept a high-contrast theme with low-vision users or a contrast-sensitivity task, not with “does it look good at night”.
- Do not use dark-theme screenshots as proof that high contrast is done.
- How to check: ask “who is this for?”. If the answer is “people who like dark”, it is not high contrast yet. Then ask a target user to point at every tappable edge; anything they miss is still living in the midtones.
Related
- Same group: F5.12.2 High-contrast mode usually wants a more extreme figure/ground split and stronger borders · F5.12.3 Hierarchy that depends on shadow or gradient needs a substitute in high-contrast mode
- Nearby: F5.07 Dark-mode remapping · J2.07 Low vision and screen magnification
- Search terms:
high contrast mode·low vision·dark mode