AddThisFeature

Color-Blindness Simulation

See the interface the way users with common colour-vision differences see it.

moderate Accessibility & Internationalization

What it adds

A development-time filter that renders the live interface under the common forms of colour-vision deficiency.

What your agent is told to do

5
  1. 1

    Find every place in the app where meaning is carried by colour alone — chart series, status badges, validation states, diff highlighting, calendar categories, heat maps — and put those screens through the simulation before anything else.

  2. 2

    Apply the simulation to the rendered page, including canvas and image content, rather than to a page of palette swatches. A swatch grid stays legible under filters that make a real stacked chart unreadable.

  3. 3

    When two elements collapse into the same colour, fix the design rather than the simulator: add a label, a shape, a pattern, a dash style, or a difference in position. Nudging the hue until the filter stops complaining moves the problem to the next viewer.

  4. 4

    Offer the common deficiency types separately — red-weak, green-weak, blue-weak, and full monochrome — because a pairing that survives one fails another, and a single combined mode hides which one broke.

  5. 5

    Do not treat a clean simulation pass as accessibility testing. Simulation approximates one axis and says nothing about contrast sensitivity, low vision, glare, or a document printed in greyscale.

Edge cases it handles

7
  • Charts, badges, error states, and status indicators are where colour does the most unaided work, so the simulation must cover them explicitly rather than only the marketing surfaces.
  • Where two colours collide under a filter, the fix is a persistent label, pattern, or icon that is present for everyone — not a variant shown only while simulation is active.
  • The filter must run over rendered output, including images, video posters, and uploaded avatars, because a token audit cannot see colour that arrived from user content.
  • A passing simulation is not a completed accessibility review, and the tooling must not report it as one or the team will stop looking further.
  • Chart libraries drawing to canvas or WebGL may ignore CSS-level filters entirely, leaving the exact surface that most needs checking untouched — verify the filter reaches them.
  • The simulation code must be excluded from production bundles and from any authenticated end-user route, not merely hidden behind a flag.
  • Screenshots taken while simulation is active must be identifiable as simulated, or they end up in a bug report as evidence of a colour bug that does not exist.

Definition of done

8
  • Every screen carrying colour-coded meaning can be viewed under each simulated deficiency type.
  • The filter applies to rendered output, including canvas charts, images, and user-supplied content.
  • No status, chart series, or validation state is distinguishable by hue alone in any simulated mode.
  • Simulation modes are unreachable in production builds.
  • The tooling states plainly that simulation is a screening step and not a full accessibility assessment.
  • Fixes made in response to the simulation are present for all users, not conditional on the filter.
  • The feature matches the existing design system.
  • No existing functionality is broken.

Related features

How it works

  1. 1

    Copy the link

    Grab the Markdown instruction URL for this feature.

  2. 2

    Give it to your AI

    Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.

  3. 3

    It inspects, then implements

    Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.