When AI Color Palettes Fail Accessibility Checks — and How to Fix Them

Ask any capable model in 2026 for "a modern color palette for a dashboard" and you will get six tasteful hex codes that look great pasted into a mockup. Then you run them through an accessibility check and half of them fail. This is not a bug you can prompt your way out of entirely, because it stems from what the model actually learned. It was trained on images and design examples that looked good to sighted people under good conditions. It was not trained on the perceptual math that determines whether two swatches are distinguishable to someone with deuteranopia, or whether text sits at a readable contrast ratio. Aesthetics and accessibility are correlated but not the same, and the model optimized for the first.

Here is a short, practical note before the specifics: accessibility conformance is something you verify with tools and, where it matters legally, with people who own that responsibility in your organization. Nothing here is legal advice about WCAG obligations. It is a working method for catching and fixing the failures I see most.

The failures that show up again and again

Red and green as a category pair

The most common failure by far. A model will happily hand you a categorical palette with a red series and a green series sitting next to each other. To the roughly one in twelve men and one in two hundred women with red-green color vision deficiency, those two can collapse into the same muddy tone. If your chart relies on that distinction — and a categorical palette does exactly that — the information is gone.

Sequential ramps with uneven lightness steps

Ask for a sequential blue scale and you often get colors chosen for how nice they look side by side, not for even lightness progression. Two adjacent steps that differ mainly in hue or saturation but not lightness become nearly impossible to order in grayscale or for a colorblind viewer. A good sequential ramp is monotonic in lightness; AI-generated ones frequently are not.

Passing contrast on paper, failing in a chart

A subtler one. The model may pick colors that individually pass WCAG contrast against a white background — but WCAG's text-contrast ratios were designed for text on a background, not for telling two adjacent data marks apart. Two colors can each clear 4.5:1 against white and still be nearly indistinguishable from each other. Swatch-to-swatch discriminability is a different problem than text contrast, and most quick checks only test the latter.

The tools that catch it

Do not eyeball this. Run the palette through checkers built for the job.

• Viz Palette (Elijah Meeks and Susie Lu's tool) is the one I reach for first for categorical chart colors. Paste your hexes and it simulates deuteranopia, protanopia, and tritanopia, and shows you a name-collision matrix of which pairs are too close. It is built specifically for data viz, not general UI.
• Coblis or Sim Daltonism to view an actual rendered chart through a color-vision-deficiency simulation. Simulating the palette swatches is good; simulating the real chart, with its thin lines and small marks, is better.
• A contrast checker for any text or UI element — the WebAIM checker, or a tool that reports the newer APCA values that WCAG 3 is moving toward. For the chart marks themselves, use Viz Palette's difference view rather than a text-contrast ratio.
• Chroma.js (the color-picker/palette-helper) when I need to programmatically correct lightness steps, because it lets you interpolate in a perceptual color space.

How to fix each failure

Reach for a tested palette first

The fastest fix is to not start from a hallucinated palette at all. For categorical data, the Okabe-Ito palette is eight colors designed to stay distinct across the common types of color vision deficiency; it is my default and I will tell the model to use it outright: "use the Okabe-Ito colorblind-safe palette." For sequential and diverging data, ColorBrewer's scales were built and tested for exactly this and let you filter to colorblind-safe options. You can still ask a model to assign those colors to your series sensibly; you just do not let it invent the colors.

Fix the red-green pair

Swap to a blue-orange contrast, which survives the common deficiencies. If your brand truly requires red and green — say, up/down semantics in finance — do not rely on hue alone. Add a redundant encoding: an up or down arrow, a plus or minus sign, direct labels, or position. The rule to internalize is that color should be a reinforcement of meaning, never the sole carrier of it.

Fix the sequential ramp

Rebuild it so lightness moves monotonically. In practice I take the model's hue choices, drop them into a perceptual space (CIELAB or LCH via Chroma.js), and force the lightness values to step evenly while keeping the hue. The result looks nearly as nice and reads correctly in grayscale — the acid test. If the printed-in-black-and-white version is orderable, a colorblind viewer can order it too.

Reduce the category count

Many failed palettes fail because there are simply too many categories. Beyond roughly seven or eight, no palette stays reliably distinguishable for everyone. If your chart needs a tenth color, the honest fix is usually not a tenth color — it is grouping the long tail into "other," using small multiples, or direct-labeling instead of relying on a legend and a color match.

A prompt that fails less often

You can shift the odds at generation time by naming the constraint instead of hoping for it:

Suggest a categorical palette for a dashboard with 5 data series.
Requirements:
- Must be distinguishable under deuteranopia and protanopia
- Do not use a red/green pair as adjacent categories
- Prefer the Okabe-Ito palette or ColorBrewer qualitative sets
- Return hex codes and note which CVD-safe set they come from
I will verify in Viz Palette, so choose accordingly.

Telling it you will verify, and naming the tested sources, meaningfully improves what comes back. But it does not remove the verification step. I have had models cite Okabe-Ito and then hand over colors that are not actually the Okabe-Ito values. Trust the checker, not the claim.

The workflow, compressed

1. Generate a palette, or better, ask for a named tested one.
2. Paste the hexes into Viz Palette; read the CVD simulations and the pair-collision matrix.
3. Render a real chart and view it through Coblis or Sim Daltonism.
4. Fix by swapping to blue-orange, evening out lightness, adding redundant encodings, or cutting categories.
5. Confirm the grayscale version is still readable — the cheapest proxy for "will this survive real-world viewing conditions."

The point is not that AI color suggestions are useless. They are a fine starting palette and a genuine time-saver for the aesthetic layer. The point is that accessibility is a property you measure, not a property you prompt for, and the model has no way to measure it. Keep the generation step, add the verification step, and the failures become routine to catch instead of something a user discovers for you after the dashboard ships.