Color Blindness Simulator: Test App Colors

A color blindness simulator should show each iOS and Android screen under deuteranomaly, protanopia, and tritanopia before handoff. Check every success, error, selected, warning, chart, and required-field signal; red/green success-and-error states are the classic failure. Under WCAG 2.2 SC 1.4.1, colour cannot be the sole means of conveying information, so add a text label, icon, pattern, or distinct shape to every colour-coded state. Run the original and simulated screens side by side, then fix any state whose meaning disappears.

Key takeaways

• •Roughly 1 in 12 men and 1 in 200 women have a colour vision deficiency.
• •Deuteranomaly is the most common colour vision deficiency; protanopia and tritanopia are also essential test views.
• •WCAG 2.2 SC 1.4.1 prohibits using colour as the sole means of conveying information.
• •A red error border needs a label, icon, or shape change that remains visible without red perception.
• •Test success, error, warning, selected, and required states in every simulated view.

This guide is for mobile UI/UX designers, founders, and engineers who can inspect iOS and Android screen states and edit component variants.

Time: 25 minutes · You'll need: A complete iOS or Android screen export in PNG format, The component states for success, error, warning, selected, and disabled, A colour vision deficiency simulator, including floow.design’s free Colour Blindness Simulator, A device or emulator for checking the revised screen at its shipping size

What's on this page

1. •Inventory every colour-coded signal
2. •Run deuteranopia design checks first
3. •Replace colour-only cues in the accessible color palette
4. •Verify the revised states on both platforms
5. •Reference table

• •Common mistakes
• •FAQs

Testing app colours with a color blindness simulator

1. Inventory every colour-coded signal

Export one representative screen for each stateful flow: form validation, payment confirmation, destructive action, selection, charts, and system status. Mark every place where colour changes meaning. On a sign-up screen, that commonly includes a green “Email available” message, a red invalid-field outline, an orange password warning, a blue selected tab, and red asterisks for required fields.

Do not limit the review to text and buttons. Include chart series, map pins, calendar availability, progress indicators, notification dots, and focus or selection treatment. WCAG 2.2 Success Criterion 1.4.1, Use of Color, applies whenever colour communicates an action, response, or distinction. A required field marked only by a red asterisk fails the criterion because someone who cannot distinguish that red receives no required-field information.

Make a short audit list with the component name, state, current cue, and non-colour cue. The target result is one non-colour cue for every row before you start simulation.

Tip: Test component variants, not only polished happy-path screens; validation and selected states contain most colour-only failures.

2. Run deuteranopia design checks first

Load each exported screen into a simulator and compare the normal image with deuteranomaly, protanopia, and tritanopia views. Start with deuteranomaly because it is the most common colour vision deficiency, then inspect protanopia and tritanopia. Record whether a person can identify each state without knowing the original palette.

Use a manual workflow if you do not use a dedicated tool: open the same PNG in any simulator that offers those three named deficiencies, capture each output, and place the four images in a 2-by-2 comparison frame. Keep the screen at the same scale in every panel. For a faster single-screen comparison, use floow.design’s free Colour Blindness Simulator, which presents the deficiency views together and can download the comparison.

Flag two failure types: colours that become nearly identical, and colours that remain different but provide the only explanation of a state. The second type still fails SC 1.4.1.

Tip: Do not treat a simulation as a pass/fail contrast test; it reveals lost meaning, while text contrast needs its own WCAG check.

3. Replace colour-only cues in the accessible color palette

Change each flagged component so its state survives without colour. For an invalid text field, retain the error colour but add an error icon and an explicit message such as “Enter a valid email address.” For success, use a checkmark with “Payment complete,” not a green banner with no text. For a selected chip, add a checkmark, filled container, or border treatment that differs in shape or weight from the unselected chip.

For data visualisation, pair series colour with direct labels, distinct line patterns, marker shapes, or both. A solid line and a dashed line remain distinguishable where red and green converge. For required fields, write “Required” in the label or provide an instruction that identifies required fields by more than a red symbol.

Re-run all three simulations after each component change. The finished screen should let a person identify every success, error, warning, selection, and requirement from text, iconography, or shape even if every semantic colour is ignored. This is colorblind design that also reduces ambiguity in bright sunlight and low-quality displays.

Tip: Keep semantic colours after adding redundant cues; removing red or green is unnecessary when the state also has readable text or a recognisable icon.

4. Verify the revised states on both platforms

Check the revised components in their real iOS and Android contexts. On iOS, inspect inline validation, alerts, and selected controls against the system appearance you ship. On Android, check Material components and any custom fields in light and dark themes. A cue that is clear in a static export can disappear when an error message wraps, a button truncates, or a selected state is shown at compact width.

Review one complete task per platform: submit an invalid form, resolve the error, select an option, complete a successful action, and read a chart or status summary. At each point, cover or ignore the semantic colour mentally and ask whether the visible icon, label, pattern, or shape still states what happened.

Save the comparison image and the component decisions with the design file. That gives engineering a concrete acceptance check: no functional state may depend on colour alone, consistent with WCAG 2.2 SC 1.4.1.

Tip: A green checkmark without the word “Complete” is usually sufficient only when the adjacent object and action make the result unambiguous.

Reference table

Colour vision checks for app state signals

Do it with the free Colour Blindness Simulator

See your screens through every type of colour vision deficiency at once, and download the whole comparison.

Open the Colour Blindness Simulator → — free, no sign-up.

Common mistakes

Checking only whether the screen still looks attractive in a simulated view.

Test whether each state can be interpreted without its semantic colour. A muted but labelled error state can pass; a vivid red outline with no text cannot.

Replacing red and green with blue and orange, then stopping.

A different pair of colours does not satisfy WCAG 2.2 SC 1.4.1 when colour remains the only signal. Add an icon, label, pattern, or shape difference.

Adding an error icon but leaving it unexplained.

Pair the icon with a specific message such as “Password must contain 8 characters.” The message must identify the problem and the correction.

Testing charts as if labels and form states were the only accessibility risk.

Give chart series direct labels, marker shapes, or line patterns. A legend that differs only by colour is still a colour-only signal.

Frequently asked questions

What is the best color blindness simulator for mobile app screens?

The best color blindness simulator for mobile screens shows the original alongside deuteranomaly, protanopia, and tritanopia versions of the same screen. Use it on exported iOS and Android states, then confirm that errors, success states, selected controls, and chart series still communicate meaning without their colours. floow.design’s free Colour Blindness Simulator supports a side-by-side comparison and download.

How do I test a deuteranopia design?

Test a deuteranopia design by viewing the same screen in a deuteranomaly simulation and checking whether every state remains identifiable without red-green distinction. Deuteranomaly is the most common type of colour vision deficiency, so inspect it first. Then test protanopia and tritanopia because a palette that works in one simulated view can still fail in another.

Do I need to remove red and green from an accessible color palette?

No, an accessible color palette may use red and green when each state also has a non-colour cue. A red error state should include an error icon and explanatory text; a green success state should include a checkmark or a completion label. WCAG 2.2 SC 1.4.1 prohibits colour as the sole means of conveying information, not the use of particular hues.

Does WCAG require icons with every coloured status?

WCAG does not require an icon specifically, but WCAG 2.2 SC 1.4.1 requires another perceivable cue whenever colour conveys information. Use a text label, icon, shape, pattern, or a combination. For a mobile form, “Invalid email address” is more useful than a red border alone because it identifies both the state and the problem.

How should I make a mobile chart work for colour blindness?

Make a mobile chart work for colour blindness by pairing each series colour with direct labels, marker shapes, line patterns, or clearly separated data regions. Do not rely on a colour-only legend to distinguish two lines or bars. Test the chart in deuteranomaly, protanopia, and tritanopia views at the same compact width used in the app.

Where this leaves you

A colour simulation does not tell you to abandon semantic colour. It tells you where colour is carrying information alone. Keep the red error, green confirmation, or selected tint when it supports fast scanning, but make the component understandable through a label, icon, pattern, or shape as well. This matters for the roughly 1 in 12 men and 1 in 200 women with a colour vision deficiency, and it is required by WCAG 2.2 SC 1.4.1 when colour communicates meaning. Your next action is simple: export one high-risk mobile screen and compare its normal, deuteranomaly, protanopia, and tritanopia states before approving it for build.

---

Design the screens first

Describe the screen you need in plain English and floow.design generates production-ready iOS and Android layouts you can iterate on by chat, then export to Figma or code. Design your mobile app screens in floow.design first, then build.

Start designing free →

---

Related

• •Color Picker from Image — Pull a palette out of any image, assign it to screen roles, and export it as tokens or native code.
• •Contrast Checker — Test any pair against WCAG 2 and the newer APCA method, with a colour-blind check and the nearest passing colours.
• •Color Picker From Image: Build an App Palette — Use a color picker from image workflow to turn a reference screenshot into accessible app
• •Dark Mode Color Generator: Mobile App Guide — Use a dark mode color generator workflow to derive mobile app tokens, tonal elevation, mut
• •Gemini 3.1 for Mobile App UI Design: 4 Real Prompts Tested Hands-On (2026) — I tested Gemini 3.1 Pro with 4 real mobile app UI prompts — fitness tracker, food delivery

Sources

• •W3C WAI — Understanding Success Criterion 1.4.1: Use of Color
• •W3C WAI — Stories of Web Users: Color Blindness
• •Apple Human Interface Guidelines — Color
• •Android Developers — Build more accessible apps
• •Material Design 3 — Accessible color system