Generate palettes where every color is guaranteed to hold white or black text at your chosen WCAG level. Hues spread evenly from your seed, then each one is nudged in lightness until it truly measures 3:1, 4.5:1 or 7:1 — the measured ratio is printed on every swatch.
Generated locally in your browser — your colors, settings and code never leave this page.
Contrast as a generation constraint, not an afterthought
The standard accessibility workflow is backwards: design a palette, audit it, discover failures, compromise the design. This generator inverts the order — the WCAG target is an input, and every emitted color already measures compliant against your chosen text color. Accessibility stops being a review gate and becomes a property of the material.
How hues are made to comply
Hues spread evenly from your seed for variety; then each is fitted individually: lightness walks in OKLCH steps — hue and chroma held as closely as the gamut allows — until the measured WCAG ratio against your text color clears the target. The fitting respects color identity as far as physics permits: a yellow asked to hold white text at 4.5:1 must become deep gold (no lighter yellow can comply), while a blue barely moves. The printed per-swatch ratios are the receipts.
| Target | Ratio | Covers |
|---|---|---|
| Large text / UI | 3:1 | 18pt+ text, icons, borders |
| AA normal text | 4.5:1 | body copy, labels, chips |
| AAA | 7:1 | long-form reading, low-vision support |
Design within the constraint
Compliant palettes have a look — darker and less neon than unconstrained ones when supporting white text — and fighting that look means fighting arithmetic. The productive move is choosing where the constraint applies: badges and buttons need it; decorative illustration does not. Generate constrained colors for the text-bearing roles and let free colors live where nothing is read.
The other axis of accessibility
Contrast compliance serves low vision; hue distinctness serves color vision deficiency — different failures, different tools. A palette can pass every ratio here while its members blur together under deuteranopia. When palette members must be told apart (chart series, status systems), run the output through the Color Vision Safe Palette Generator’s logic or the Simulator before shipping.
Reading the generated lightness pattern
Scan any generated palette and a pattern emerges worth internalizing: the hues did not comply equally. Against white text, the yellows and cyans landed far darker than they started while blues and violets barely moved — because each hue’s natural lightness differs, and the contrast target is a fixed luminance bar they clear from different starting points. That asymmetry is the honest shape of accessible color; palettes that look uniformly vivid AND uniformly compliant are advertising one of the two falsely. Designing with the asymmetry — letting compliant yellows be deep gold, compliant blues stay bright — reads as sophisticated precisely because it is truthful.
How to use the Accessible Color Palette Generator
- Pick a seed color, the palette size, the text color to support and the WCAG target.
- Every hue is lightness-fitted until it measures the target for real.
- The achieved ratio prints on each swatch.
- Export with confidence.
Frequently asked questions
What exactly does this generator guarantee?
That every generated color holds your chosen contrast ratio – 3:1, 4.5:1 or 7:1 – against the text color you selected (white or black), measured with the WCAG formula, not estimated. The per-swatch ratios are printed so the claim is checkable.
How does it make an arbitrary hue pass 4.5:1?
Lightness iteration in OKLCH: the hue and chroma stay as close to intent as possible while L walks toward the passing region until the measured ratio clears the bar. Yellows fighting white text end up deep gold; blues barely move – each hue pays its own price.
Why do the palette colors differ in vividness?
Because the sRGB gamut is uneven: at contrast-safe lightness, some hues support high chroma and others do not. Equal-vividness AND equal-contrast is often mathematically impossible – this tool prioritizes the contrast promise and lets chroma adapt.
Should I target AA or AAA?
AA (4.5:1) is the legal/de-facto floor for body text; AAA (7:1) is best-practice for long reading and low-vision audiences but constrains design heavily. The 3:1 target fits large headlines and UI components. Pick per element role, not one global answer.
Does passing with white text mean failing with black?
Generally yes for any mid-dark color – and vice versa. Generate one palette per text strategy, or reserve this tool for chart/badge/button fills where the overlaid text color is fixed and known.
Are these palettes also color-blind safe?
Contrast-safe and CVD-safe are different axes: this tool guarantees luminance contrast, which survives all color-vision types, but hue distinctions between palette members may not. If members must be told apart by hue, cross-check in the Color Vision Safe Palette Generator.
Where do these palettes shine?
Anywhere text sits on colored fills: category chips, calendar events, alert banners, chart labels, avatar backgrounds. The guarantee removes the per-color review that usually makes such features an accessibility whack-a-mole.
