Some low-vision users rely on color, not zoom — both paths must work

What it is

Some people set the OS to yellow-on-black, invert, or forced colours, and barely change type size. Photophobia, lost contrast sensitivity, some field defects: magnification only enlarges the glare. Colour is the path they actually use. Low vision is not “always zoom the UI.” Magnification and colour adaptation both have to work; shipping only one shuts the other group out.

Why it happens

Adaptation strategies inside low vision split. Magnification treats acuity and tiny detail; it does not treat low contrast, glare, or inseparable colour pairs. The second group leans on forced colours, inversion, user stylesheets, or a darker theme with a larger luminance gap. If the page hard-codes colour, paints text on a background image, uses shadow instead of a border, or lets icons and text collapse to one colour under forced colours, that path is cut.

The two paths also step on each other. A large tinted region that helps magnification can become a glare slab after inversion; a thick high-contrast border can crowd content at 16×. “Support both” is not stacking both patches on the same pixels. It is letting system and user colours replace page colours, while the layout remains readable when magnified.

Studying it

Stratify recruitment by adaptation strategy, not by acuity chart: mainly magnifier; mainly high contrast / invert / custom colours with little zoom; both. Run the same tasks in three OS setups: default colours + 8× magnification; forced colours, no zoom; inverted or night colours, no zoom. Dependent: completion, reports of glare or “type melted into the ground,” whether custom colours were overridden by the page.

Usability tests that only include magnifier users will miss colour-path failures. The cheapest screen: turn on forced colours / increase contrast and see how much of the page’s own colour remains.

Where it stops holding

Colour vision deficiency (red–green and the rest) is a hue-separation issue; it need not come with low vision, magnification, or forced colours — that is a different criterion. Blind screen-reader users take neither visual path. Some eye conditions need both magnification and colour, so the two paths are not two exclusive populations. What is exclusive is a product that only verifies one. Passing 200% browser zoom does not stand in for a forced-colour pass.

Applying it

• Do not make colour a frozen, unoverridable presentation: text, borders, and icons should use properties forced colours can replace, not type painted into images or state that lives only in a background graphic.
• Under OS high contrast / forced colours, check that type still separates from the ground, the focus ring remains, and icons do not vanish into the same colour as the background.
• Sign off magnification layout and colour themes as separate acceptances. “We support 200% zoom” does not replace a high-contrast check; “contrast passed” does not replace a magnification check.
• How to check: walk the same primary path twice — default colour + 8× system zoom, then forced colours with no zoom. Both completions are required. If state, focus, or text disappears on either pass, record which path broke.

Related

• Same group: J2.07.1 Magnification shrinks the visible field to a tiny viewport · J2.07.2 Scattered related elements force pan-and-search · J2.07.3 A cue must sit next to the element it belongs to · J2.07.4 Screen magnifiers make the pointer easy to lose · J2.07.5 Hover menus can open outside the magnified window · J2.07.7 Dynamic content is missed unless the magnified view is cued
• Nearby: J2.15 Dark Mode and High Contrast Compatibility · J5.13 System Accessibility Settings · J2.01 Text Contrast
• Search terms: forced colors · high contrast low vision · color-based adaptation