A color-vision simulation can help you spot interface states that become difficult to distinguish when colors shift, but it cannot certify a website as accessible. Use it as one review lens, then check text contrast, labels, icons, focus indicators, and the page in its actual layout. The strongest interfaces do not require users to identify a color correctly to understand what happened.
What a color-vision preview is for
A simulator applies a visual transformation to an image or color sample to approximate how a scene may appear under a selected color-vision difference. This can reveal design weaknesses: two status colors may converge, a red marker may disappear into a dark background, or chart series may become hard to separate.
It is best used as a prompt for investigation. It is not a medical test, a substitute for feedback from people with varied vision, or proof that every user will see the interface in the same way. Individual perception varies, and a static screenshot cannot cover every display, lighting condition, browser, or contrast setting.
The Toolsnix Color Blindness Simulator can give you a transformed preview to inspect. Run it on a representative screenshot, but keep testing the live interface. A screenshot has no keyboard focus, hover behavior, responsive reflow, or screen-reader output to evaluate.
Find places where color carries meaning
Before checking colors, inventory where the interface uses them. Common examples include error and success states, chart series, required fields, selected tabs, links, badges, and heat maps. Ask whether a person could understand the same information if the colors were removed or appeared similar.
Consider a form with a red border on invalid fields and a green border on valid fields. Color alone may not convey which field needs attention. Add a clear message such as “Enter a valid email address,” associate it with the field, and make the state visible through text or a meaningful icon. Likewise, a chart should identify series through direct labels, line patterns, markers, or a legend that remains understandable.
Do not make status distinctions depend only on red versus green. Use words such as “Failed” and “Passed,” recognizable symbols with accessible names, or patterns alongside color. The exact choice depends on context, but redundant cues make meaning more robust for everyone, including users viewing a low-quality display or grayscale printout.
Check contrast separately
Color-vision simulation and contrast checking answer different questions. A simulation helps identify colors that may become visually similar. A contrast check compares foreground and background luminance for text or meaningful graphical elements. Passing one check does not automatically pass the other.
The W3C’s WCAG guidance explains the use-of-color criterion and contrast requirements. Check the current standard and apply the relevant criterion to your text size, weight, and interface components. For example, normal-size text has a different minimum contrast threshold than large text under WCAG 2.2 Success Criterion 1.4.3; verify the official definition rather than relying on a guessed ratio. Non-text controls and graphical information have their own considerations. W3C: Use of Color and W3C: Contrast Minimum.
Measure the actual foreground and background pair in its real state. A text color may pass on a flat page background but fail over an image, gradient, translucent panel, or hover state. Check disabled, focused, selected, error, and visited appearances where relevant. Do not assume that a brand palette is automatically suitable for every component.
Review a useful sample, not only the homepage
Choose pages that expose the palette’s different jobs: a form with validation, a chart, a table with statuses, navigation links, and a page with dark or image backgrounds. Include both light and dark themes if the product supports them. Test normal, hover, focus, pressed, selected, and error states where those states use color.
A practical review sequence:
- Capture or open the representative page at a common desktop and mobile width.
- Run the color-vision preview on the relevant screenshot or region.
- Record any pairs that become hard to distinguish, including where and why they matter.
- Inspect the live component for text labels, icons, patterns, and focus cues.
- Check contrast for text and meaningful graphical controls using the applicable standard.
- Revise the palette or add a redundant cue, then repeat the preview and normal-view check.
- Test keyboard operation and a screen reader where the component’s behavior requires it.
Keep a short defect record: page, state, colors or tokens involved, user consequence, proposed change, and retest result. That makes the review actionable instead of a vague “colors look okay” approval.
Improve the design without flattening the palette
If two colors become difficult to distinguish, you do not always need to change the entire brand system. First ask whether those colors need to be distinguishable in that context. If yes, adjust the relevant pair, change one state’s lightness, add a border or shape, or include text labels. Check contrast and the overall visual hierarchy after each adjustment.
For charts, avoid assigning critical categories solely to adjacent hues. Direct labels, varied line styles, different marker shapes, or small multiples may clarify the data. Avoid relying on a legend alone when labels can sit near their data series, especially when readers may need to compare values quickly.
For controls, state should remain visible when color is unavailable. A selected tab can use an underline and semantic selected state; an invalid field can have an error message and programmatic association; a link can be underlined or otherwise distinguished from surrounding text. These cues also help in low-contrast environments and when users customize browser colors.
Do not “fix” every simulation difference by making all colors maximally saturated. That can make the interface noisy and may create new contrast or hierarchy problems. Adjust only the combinations that carry distinct information, then evaluate the full interface rather than isolated swatches.
Include human review and assistive technology
Automated checks and simulators are useful for finding issues, but they cannot determine whether labels make sense, whether a chart’s legend is usable, or whether a complex state is understandable. Ask people with different access needs to review important workflows when possible. Do not ask one person to represent every person with a particular diagnosis; feedback is specific to that person and context.
Use semantic HTML and accessible names for controls. Ensure status changes are announced when appropriate, and keep keyboard focus visible. A visually distinct color does not help someone who cannot perceive it, and a screen-reader announcement does not excuse an interface that is visually unclear. The goal is equivalent access through more than one channel.
Common mistakes
Treating a simulator as a pass/fail gate. A simulation is approximate and limited to its input. Use it to discover possible collisions, then verify the real interface and seek human feedback for important flows.
Checking only brand swatches. Components add context: text size, surface color, borders, and state changes affect usability. Test the rendered interface.
Changing colors without checking contrast. A palette edit may solve one distinction and make text harder to read. Re-run contrast checks for every affected state.
Using color and an icon with no label. An unfamiliar icon may be just as ambiguous as color. Add concise visible or accessible text when users need to act on the information.
Assuming a chart is accessible because it has a legend. Verify that the legend is clear, series are distinguishable, values are available in another form, and the chart’s purpose is explained.
Frequently asked questions
Does a color-vision simulator prove my site is accessible?
No. It can reveal possible color collisions in the content you preview, but it does not check contrast comprehensively, keyboard behavior, screen-reader output, or every user’s perception. Use it as one part of a broader review.
Should I avoid red and green completely?
No. Red and green can be used, but do not make them the only way to identify meaning. Add labels, shapes, patterns, or other visual cues and check the relevant foreground and background contrast.
What should I test besides the color palette?
Review actual controls and content: links, form errors, selected states, charts, badges, focus rings, and messages. Include real text sizes, backgrounds, and responsive layouts.
Can contrast checking replace simulation?
No. Contrast checks evaluate a different property from whether two categories remain distinguishable under a simulated color-vision transformation. Both can reveal useful but different problems.
Should I test with real users?
For important journeys, feedback from people with varied access needs can reveal issues that tools miss. Treat feedback as contextual evidence, and combine it with standards-based checks and iterative design.
Next step
Choose a page with meaningful status colors, preview it through a simulator, and then inspect each affected component for labels, contrast, and non-color cues. Fix the user-facing ambiguity and retest the live state, not only the screenshot.
Document decisions so they can be maintained
When a palette issue is fixed, record which token or component changed and why. For example, a chart series may have been difficult to separate in the simulated view, so the team changed the line pattern and added direct labels while keeping the brand colors. This record helps prevent a later redesign from removing the redundant cue because someone assumes it is decorative.
Include representative screenshots in the design system or issue tracker when practical, but pair them with the live component and the criteria that matter. A static image cannot document keyboard focus, semantic status, or responsive behavior on its own. Note theme, viewport, state, and text size so another reviewer can reproduce the same conditions.
For a shared color token, inspect all its uses before changing it globally. A token used for both muted backgrounds and link text may need different variants instead of one compromise value. Rename or split tokens when their roles differ; role-based tokens are easier to evaluate than a palette of unexplained hex values.
Review data visualizations with their task in mind
A chart’s purpose is often comparison, ranking, or locating a particular value. The review should test that task, not just whether the colors look different in a legend. Ask someone to find a series, compare two values, or identify an outlier using the chart as presented. If the answer depends on distinguishing two similar hues, add another cue such as direct labels, line styles, markers, or a table with equivalent values.
Consider overlapping data. A set of categories may appear distinguishable when shown as isolated swatches but merge when lines cross or small marks sit on a textured background. Preview the busiest realistic chart, not only the design-system sample. If the number of categories makes the graph difficult to read, a different chart form or filtering interaction may be more useful than inventing an ever-larger color palette.
For maps, use labels, outlines, or patterns for boundaries and status where feasible. Provide a legend with plain-language descriptions and ensure the map’s important conclusion is summarized in text. Color can reinforce the message, but the map should not be the only way to access key data.
Recheck after design changes
Palette reviews are not permanent approvals. New components, theme changes, a refreshed brand palette, and chart additions can create new combinations. Include color and non-color cues in component review, and revisit representative pages after a substantial redesign. Small changes can affect many states when shared tokens are involved, so check related screens rather than only the component that prompted the edit.