Eight percent of men have some form of color vision deficiency. Add low vision, aging eyes, and situational impairments like screen glare, and a large portion of your audience sees your site differently than you do.
Color alone fails as information carrier. What’s obvious in red versus green becomes invisible when red and green look the same.
Designing for color blindness isn’t charity. It’s making your site work for real users who want to use it.
Color Vision Deficiency Types
Red-green color blindness is most common. Protanopia and deuteranopia, the two main types, affect how red and green wavelengths are perceived.
For someone with deuteranopia, the most common type, red and green may appear similar. That red error message against a form? Not obviously red. That green success indicator? Not obviously green.
Tritanopia affects blue-yellow perception. Less common but still affects real users. Blue and yellow distinctions that seem obvious can blur together.
Complete color blindness, seeing only grayscale, is rare but exists. Any information carried only by color is completely lost.
Simulation tools show what your design looks like with different deficiencies. Figma, Sketch, and browser extensions offer color blindness previews. Use them during design, not just review.
Never Use Color Alone
The principle is simple. Any information conveyed by color should also be conveyed by something else.
Error states use red. Good. Also add an icon, a text label, or a border style change. Now the error is visible regardless of color perception.
Links within text use color to differentiate from body text. Good. Also add underline or other visual distinction. Now links are visible regardless of color perception.
Charts use different colors for different data series. Good. Also add patterns, shapes, or direct labels. Now series are distinguishable regardless of color perception.
This redundancy helps everyone. Users in bright sunlight lose color perception situationally. Users on poorly calibrated monitors see colors differently. Redundant signals reach more users in more conditions.
Contrast Ratios Matter
Color contrast affects legibility for everyone but especially for users with low vision.
WCAG AA requires 4.5:1 contrast for normal text and 3:1 for large text (18pt or 14pt bold). WCAG AAA requires 7:1 and 4.5:1 respectively.
Low contrast is endemic in modern design. Trendy light gray text on white backgrounds looks subtle. It’s also hard to read. The aesthetic choice creates accessibility barriers.
Tools measure contrast instantly. Browser developer tools show contrast ratios. Design tool plugins flag insufficient contrast during creation. There’s no excuse for shipping illegible text.
Check contrast in context, not just in isolation. Text over images needs sufficient contrast against all parts of the image. Text over gradients needs sufficient contrast at every point.
Dark Mode Accessibility
Dark mode doesn’t automatically solve contrast problems. It creates different ones.
Light text on dark backgrounds needs appropriate contrast just like dark text on light backgrounds. The numbers still apply.
Colors that worked on light backgrounds may need adjustment for dark backgrounds. A blue that had good contrast against white may not against black.
Dark mode should be a complete design system, not just inverted colors. Thoughtful dark mode tests and adjusts each color relationship.
System settings for dark mode should be respected. prefers-color-scheme in CSS lets sites follow user preference automatically.
Low Vision Beyond Color
Color blindness is one category of visual impairment. Low vision encompasses broader challenges.
Font size minimum of 16 pixels for body text is generally recommended. Smaller text strains eyes and excludes users with vision limitations.
Line height of 1.4 to 1.6 aids readability for everyone and particularly helps those who struggle to track lines.
Zoom support to 200% without breaking layout is a WCAG requirement. Text that becomes unreadable or layouts that break when zoomed fail this standard.
Clear, high-contrast focus indicators help keyboard users who are sighted but can’t use mice. The default browser focus indicator is often insufficient.
Motion and Animation Sensitivity
Some users experience discomfort, dizziness, or seizures from motion.
prefers-reduced-motion respects user system settings. When users indicate motion sensitivity, reduce or eliminate animations.
Necessary motion versus decorative motion: status updates might need subtle motion for attention. Decorative parallax effects serve no function that can’t be served without motion.
Autoplay video with motion should be avoidable. Let users control when motion happens.
Flashing content at certain frequencies can trigger seizures. More than three flashes per second is specifically dangerous. This is a serious safety issue, not just preference.
Testing with Simulation
Simulation tools don’t replicate exact experience but provide useful approximation.
Grayscale conversion is a quick check. If your design is illegible in grayscale, color dependence is too high.
Color blindness simulation in design tools shows how major user groups perceive your work. Run designs through filters before finalizing.
Low vision simulation blurs content to approximate reduced acuity. Key information should remain comprehensible.
Screen magnification testing zooms to 200-400% to see how your layout behaves under magnification.
Beyond Compliance
Accessibility standards are floors, not ceilings.
Meeting WCAG AA means avoiding the worst problems. It doesn’t mean creating great experiences for users with disabilities.
User testing with people who have actual disabilities reveals problems that compliance checking misses. How someone with low vision actually uses your site differs from how you imagine they use it.
Inclusive design benefits everyone. High contrast helps users in bright sunlight. Clear navigation helps users in a hurry. Readable text helps users on small screens. Designing for edge cases often improves mainstream experience.
Testing Across Conditions
Real-world use varies wildly.
Screens in bright sunlight lose contrast. The carefully considered color palette becomes hard to distinguish when light washes out the display.
Battery saver modes reduce screen brightness. Colors that worked at full brightness may fail at reduced levels.
Blue light filters shift color perception. Evening users with warm screen settings see your colors differently than you intended.
Dirty screens reduce clarity. Fingerprints and smudges on mobile screens affect visibility in ways clean test devices don’t reveal.
Testing in controlled conditions misses these variables. Test in actual use conditions when possible.
Working with Brand Constraints
Brand colors often predate accessibility awareness.
Some brand palettes simply don’t meet contrast requirements against certain backgrounds. The signature brand blue might fail against white.
Solutions exist without abandoning brand. Darker variants of brand colors for text. Adjusted backgrounds that provide contrast. Reserved brand colors for decorative rather than functional use.
Documentation helps navigate constraints. Which colors can be used for text? Which are accent only? What combinations are approved? Clear guidelines prevent repeated conflicts.
Sometimes brand guidelines need updating. If the brand prevents accessible design, the brand should change. Accessibility isn’t optional; brand flexibility is.
FAQ
Our brand colors don’t meet contrast requirements. Do we have to change the brand?
Not necessarily. Brand colors can remain for decorative and brand elements. Functional elements like text and interactive components need sufficient contrast. Many brands maintain their colors in logos and accents while using appropriately contrasting colors for interface elements.
We use red and green for error and success states. Is that wrong?
Using red and green isn’t wrong if you also use other indicators. Icon shapes, text labels, or position changes can convey the same information. The combination of color plus another indicator works for everyone.
Testing for color blindness issues. Methods issues?
Use simulation tools built into design software or browser extensions. Run your designs through deuteranopia and protanopia filters at minimum. Also test in grayscale as a quick check. If information disappears in simulation, add non-color indicators.
Our design team doesn’t include anyone with visual impairments. How do we know what they need?
Research and testing. WebAIM’s surveys provide data on how users with disabilities interact with the web. User testing with participants who have visual impairments provides direct feedback. Accessibility consultants can audit and advise. Don’t guess when information exists.
Sources
WebAIM. Color Blind Accessibility. webaim.org/articles/visual/colorblind
W3C. WCAG Contrast Guidelines. w3.org/WAI/WCAG21/Understanding/contrast-minimum
Colour Blind Awareness. colourblindawareness.org
A11Y Project. Color and Contrast. a11yproject.com/posts/what-is-color-contrast
MDN Web Docs. prefers-reduced-motion. developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion