Test a website palette beyond contrast: color-vision simulation

A readable label and a distinguishable category are different questions. Check both, and give important information a second visible cue.

Reviewed 7 October 2026 · 3 min read

Start with the information, not the filter

Imagine a dashboard where purple means “in progress” and green means “complete.” If the labels disappear, the colors alone carry the decision. A simulation can expose a fragile distinction, but adding visible status text solves a problem that a new hue may only move elsewhere. Our dashboard preview keeps numbers and day labels alongside its colored bars for this reason.

W3C’s use-of-color guidance asks for another visible way to understand information conveyed by color. Use direct labels, icons with explained meaning, patterns or different line styles. An accessible name for a screen reader does not replace a visible cue for someone looking at the page.

Inspect the actual light and dark interfaces

Open the studio and choose a mode under “Inspect color vision.” It applies to the colors used in both HTML previews, including text, fills, links, borders and focus rings. Switch between Website, Dashboard and Editorial to see different uses of those roles. A saved comparison uses the same simulation, so the comparison remains consistent.

The editable hex values, saved project, exports and WCAG audit stay original. A simulated appearance is a way to inspect your project; it is not a replacement palette to ship. The badges explicitly refer to the original contrast checks while a simulation is active.

A reproducible example

These values are calculated by this site’s implementation from opaque sRGB red, green and blue. They are useful numerical fixtures, not recommended website colors or measured human responses.

What the model calculates

For the three named simulations, the engine decodes sRGB channels into linear light, applies the full-severity matrix from Machado, Oliveira and Fernandes (2009), clips the display result to the sRGB range, then encodes it back into an 8-bit hex color. Applying the matrix directly to encoded hex channels would produce a different result, especially for darker colors.

The matrix coefficients were checked against the Colorspacious reference implementation. Its tutorial explains the model and severity. The authors’ supplementary resource is the original source. Our grayscale option instead uses linear-light sRGB luminance. It is a color-removal check, not a complete model of achromatopsia.

Read distance as evidence, not a verdict

The studio compares the button and accent colors before and after the chosen simulation. It reports Euclidean Oklab distance on the native Oklab scale. A lower number means those modeled colors are closer in that space. We deliberately do not assign a “color-blind safe” score or a universal pass threshold: size, spacing, surrounding colors, display conditions and the person viewing the page all matter.

A pair can be different enough for decoration while being a weak way to label two data series. Conversely, two intentionally similar surfaces do not need to become different semantic categories. Inspect colors where their differences actually carry meaning.

Complete the review

1. Run the original-token contrast checks for text and meaningful boundaries.
2. View the interface under each simulation and in grayscale.
3. Read its status labels and chart legends without relying on the swatches.
4. Test keyboard focus and interactive states in the implemented site.
5. Include people with relevant lived experience in usability testing when you can.

A passing contrast audit and a convincing simulation are useful evidence, but neither establishes whole-site accessibility or describes every individual’s vision.

Our examples use original palette values and the WCAG 2.2 calculation. Full methodology and primary sources.