Accessible Color Palette Generator

By Bogdan Sandu · Published 22 December 2025 · Last updated 14 September 2026

This Accessible Color Palette Generator turns one base color into a five-color palette. For each color it tells you whether white or black text on it clears the WCAG contrast thresholds. Pick a color, pick a palette type, and read the badges.

What you can set:

• Base color from the picker, a typed hex code, or the Random button
• Palette type: Vibrant, Monochromatic, Contrasting 1, Contrasting 2, Pastel, Pastel Contrasting 1, Pastel Contrasting 2, or Dark to Light
• Lock on any card, so that color survives the next regeneration

Each card shows the color's HEX, RGB, and HSL values, each with its own copy button. Below them sit the contrast ratio and two badges: WCAG AA (4.5:1) and WCAG AAA (7:1).

How to Use This Accessible Color Palette Generator

1. Enter your brand color in the hex field, or click Random for a starting point.
2. Choose a palette type. The palette regenerates on every change, and the Vibrant, Contrasting, and Pastel modes add a little randomness, so pick the same mode twice to see variations.
3. Lock the colors you want to keep, then change the mode or the base color to regenerate the rest.
4. Read the badges. A green AA means text in white or black, whichever is stronger, reaches at least 4.5:1 on that color.
5. Copy the values into your stylesheet or design tokens.

A card for #2C5F8A reads like this:

HEX   #2C5F8A
RGB   44, 95, 138
HSL   207°, 52%, 36%
WCAG AA ✓   WCAG AAA ✗
Contrast: 6.75:1

The ratio is the WCAG formula the tool runs in the browser: relative luminance of the lighter color plus 0.05, divided by relative luminance of the darker color plus 0.05, after linearizing each RGB channel.

function luminance(r, g, b) {
  const lin = c => {
    c /= 255;
    return c <= 0.03928 ? c / 12.92 : ((c + 0.055) / 1.055) ** 2.4;
  };
  return 0.2126 * lin(r) + 0.7152 * lin(g) + 0.0722 * lin(b);
}

function contrast(a, b) {
  const [l1, l2] = [luminance(...a), luminance(...b)].sort((x, y) => y - x);
  return (l1 + 0.05) / (l2 + 0.05);
}

What the tool does not do

• It does not constrain generation by contrast. Palettes come from hue, saturation, and lightness offsets around your base color. The badges are a check on the result, not an input to it. If a card fails, regenerate, lock the passes, and try again, or nudge the base color darker or lighter.
• It checks each color against white and black text only. It does not test palette colors against each other. For a text-on-color pairing between two palette colors, run the two hex codes through the formula above or a dedicated contrast checker.
• It uses WCAG 2 ratios. There is no APCA score.
• It does not simulate color blindness. View the palette in Coblis or Color Oracle before shipping.
• There is no export. Copy the values you need, or name them with the Color Name Finder.

The rest of this page covers the standards, the math, and the wider workflow that the tool fits into.

What Is an Accessible Color Palette Generator?

An accessible color palette generator is a design tool that builds color combinations to meet a measurable contrast standard, not just a pleasing look.

That's the core difference from a regular palette tool. A regular generator optimizes for hue harmony. An accessible one either optimizes for readability first, or, like the tool above, generates for harmony and then measures readability on every result.

Typical users include:

• Product designers building a color system for a live interface
• Front-end developers who need contrast-safe hex codes before they touch CSS
• Accessibility leads auditing an existing brand palette

Low contrast text is the single most common accessibility failure found on the web, present on 83.9% of home pages tested in the WebAIM Million 2026 report, up from 79.1% the year before.

That single statistic is the reason this category of tool exists. Most color problems on the web are not exotic. They're simple contrast failures that a generator catches before launch.

The practice sits inside the larger discipline of web accessibility, but it's narrower in scope.

An accessible palette generator doesn't check screen reader labels or keyboard traps. It checks one thing: whether a foreground and background color combination is legible for people with low vision or color vision deficiency. That makes it a small but load-bearing piece of user interface design.

WCAG Versus APCA: Which Contrast Standard Should You Use?

WCAG measures contrast through a relative luminance ratio. APCA measures it through a perceptual lightness score called Lc.

Both exist to answer the same question in different ways: is this text readable against this background.

Key figures, sourced:

• WCAG 2.2 Level AA: minimum 4.5:1 contrast ratio for normal text and 3:1 for large-scale text, per Success Criterion 1.4.3
• WCAG 2.2 Level AAA: minimum 7:1 for normal text, per Success Criterion 1.4.6
• APCA: Lc 90 preferred and Lc 75 minimum for body text, per the APCA documentation

APCA was built by researcher Andrew Somers and is the candidate contrast method for WCAG 3, still under development.

It reports color contrast on a scale from Lc 0 to roughly Lc 106, where Lc 15 is the absolute minimum for a non-text boundary to be discernible at all.

Section 508, the Americans with Disabilities Act, and Europe's EN 301 549 all reference WCAG's ratio thresholds as the legal backbone for digital accessibility.

None of them currently cite APCA directly. That is why most generators, including this one, still default to WCAG math even as APCA gains traction among designers.

A pair of colors can pass the WCAG ratio test on paper and still feel weak in practice. Relative luminance math doesn't fully account for how the human eye perceives lightness at different sizes and weights.

How Does an Accessible Color Palette Generator Calculate Contrast?

Contrast calculation starts with relative luminance, a value derived from the red, green, and blue channels of each color after gamma correction. The code block near the top of this page is the whole formula.

The generator takes the luminance of the foreground, the luminance of the background, and combines them into a single ratio between 1:1 and 21:1.

Two sentences summarize the whole method: darker luminance plus lighter luminance produces a bigger gap, and a bigger gap produces a higher ratio.

Sliding a hue value in HSL vs RGB color pickers is where most accidental failures happen. Adjusting saturation can quietly shift luminance without the designer noticing.

Color Space and Why It Changes the Result

Not every color space represents lightness the same way, and that matters when a generator adjusts a shade to hit a target ratio. The tool above works in HSL, which is why its badges matter: HSL lightness alone does not predict contrast.

Color space	Lightness accuracy	Common use
HSL	Approximate, not perceptually uniform	Quick manual adjustments
CIELAB	Perceptually uniform	Print and cross-device color matching
OKLCH	Perceptually uniform, built for screens	Modern CSS color generation

HSL treats lightness as a simple average of a color's highest and lowest RGB channels. That is why two colors with the same HSL lightness value can look noticeably different in brightness.

OKLCH and CIELAB both model lightness closer to how the eye perceives it. Nudging a value up or down keeps the intended contrast intact.

Designers who need to move between formats quickly often reach for an RGB to HSL converter or a HEX to RGB converter when checking how a base brand color translates.

How Do These Tools Simulate Color Blindness?

Color blindness simulation renders a palette the way it would appear to someone with a specific type of color vision deficiency. The generator on this page does not include one, so treat this as the step that follows it.

Three types get simulated most often:

• Deuteranopia, reduced sensitivity to green
• Protanopia, reduced sensitivity to red
• Tritanopia, reduced sensitivity to blue, far rarer than the other two

Coblis, Color Oracle, and Sim Daltonism are the reference simulators the accessibility field points to most. Several palette tools license or replicate their filtering logic.

This is a separate check from contrast math. A pairing can hit 4.5:1 and still collapse into nearly the same shade once deuteranopia is simulated. The ratio formula doesn't know which hues a viewer can distinguish.

Color vision deficiency affects roughly 1 in 12 men (8%) and 1 in 200 women (0.5%), according to Colour Blind Awareness.

That's a meaningful share of any general audience. It is why inclusive design treats simulation as a mandatory step, not an optional extra.

Red-green confusion accounts for the overwhelming majority of cases, so a generator that only checks tritanopia is solving the smaller problem.

How Does the Palette Generation Logic Work?

Palette generation follows one of two logics: harmony-based or contrast-first. This generator is harmony-based, with the contrast check applied afterwards.

Harmony-based tools start from color theory rules.

• Complementary: two hues opposite each other on the wheel
• Analogous: hues sitting next to each other
• Triadic: three hues spaced evenly apart

Contrast-first tools work backward. Lock a base color, set a target ratio, and let the algorithm generate tints and shades that hit that number automatically.

Adobe built a hybrid version of this called Leonardo, an open source tool from its Spectrum design system team.

Leonardo takes a brand color as input and outputs a full scale calibrated against specific contrast ratios. It defaults to 3:1 and 4.5:1, the two thresholds WCAG sets for large and normal text.

The trade-off is worth stating plainly. A harmony-first palette usually looks better on the first try, but it needs a contrast pass afterward, which is what the badges above do.

A contrast-first palette passes the accessibility check immediately. It sometimes needs a second look to make sure the hues still feel like a coherent brand.

Best Accessible Color Palette Generators Compared

Coolors, Adobe Color, Khroma, Stark, and ColorBox cover most of the ways teams generate accessible palettes today.

Tool	Standard checked	Integration	Price
Coolors	WCAG AA/AAA	Web app, browser extension	Free, paid tier available
Adobe Color / Leonardo	WCAG contrast ratios	Web app, npm module	Free, open source
Stark	WCAG, some APCA support	Figma, Sketch, Adobe XD plugin	Freemium subscription
Khroma	None built in	Standalone web app	Free
This generator	WCAG AA/AAA against white or black	Web app	Free

Teams already working inside a Figma-based design workflow tend to reach for Stark. It checks contrast without leaving the file.

Where each tool tends to fit best:

• Coolors for fast, general-purpose palette exploration with a contrast check layered on top
• Leonardo for teams building a full design token scale from one brand color
• Khroma for early-stage inspiration, contrast still needs a separate checker afterward

Open source options like Leonardo give engineering teams direct access to the underlying algorithm. That matters when a palette needs to regenerate automatically as a brand color changes.

Subscription tools like Stark trade that flexibility for a smoother, plugin-based workflow that non-technical designers can run without touching code.

Pros and Cons of Automated Accessible Palette Generation

Automation removes the slowest, most error-prone part of accessible color work: testing every foreground and background pairing by hand.

Pros:

• Speed, a full color scale generates in seconds instead of hours
• Consistency, every shade in a system gets checked against the same target ratio
• Fewer human errors, no one forgets to test a hover state

Cons:

• Brand nuance can get flattened when an algorithm prioritizes ratio over feel
• Non-text elements like icons and input borders often go unchecked, since most generators focus on text
• Gradients and photographic backgrounds aren't handled at all

That second gap matters more than it looks. Form fields, in particular, rely on border contrast that a text-only generator won't flag. It is one reason accessible forms still need a dedicated review pass.

Manual review doesn't disappear once a tool approves a palette. It shrinks to the parts automation can't reach: non-text contrast, gradients, and anything using color alone to carry meaning.

The honest way to frame it: automation handles the arithmetic, a human still owns the judgment calls.

How to Generate and Implement an Accessible Color Palette

Generating an accessible color palette follows a fixed order: base color first, target standard second, contrast checking third, export last. The tool above covers the first and third steps.

Skipping the order is where most palettes go wrong, usually because someone exports before the colorblind pass.

1. Pick a base brand color and record its hex code
2. Choose a target standard: WCAG AA, WCAG AAA, or a specific APCA Lc value
3. Generate the tint and shade scale, checking each pairing against that target
4. Run the full scale through a colorblind simulation pass
5. Export the approved palette in the format your build actually uses

Export format matters more than teams expect.

A palette locked into flat hex values has to be edited by hand every time a brand color shifts. One exported as CSS custom properties updates everywhere it's referenced the moment the root variable changes.

Design teams working across Figma and code increasingly export straight to design tokens. Figma's own variables feature, covered in this Figma variables guide, maps cleanly onto that CSS custom property structure.

JSON design tokens sit in between: portable enough for a design system, structured enough for a build pipeline to consume without manual translation.

When Accessible Color Palette Generators Do Not Apply

An accessible color palette generator stops being useful the moment the surface it's checking isn't a flat, known color.

Four situations sit outside what these tools can check:

• Non-text elements: icons, input borders, and toggle states fall under a separate rule, WCAG 1.4.11, not the text contrast ratio most generators default to
• Gradients and photographic backgrounds: there's no single background color to measure a ratio against
• Dynamic or user-generated backgrounds: a profile banner or uploaded image can't be checked ahead of time
• Trademarked or legally fixed brand colors: a color that can't be shifted has no room for a contrast fix

WCAG 1.4.11 sets its own threshold of 3:1 for the visual boundaries of interface components and meaningful graphics. It is a separate criterion from the text ratios covered earlier.

IBM’s Carbon Design System documentation names this gap directly. It warns teams to check text contrast at every point it crosses a gradient or image, since a single fixed hex value won't hold up across a moving background.

Carbon also points designers toward the Stark plugin for colorblind review, an acknowledgment that no single generator step covers every attribute a real interface needs. That is part of why accessible UI components get audited as their own category rather than folded into a palette check.

Common Mistakes That Break Accessibility After Generation

A palette can pass every check a generator runs and still fail in production.

Four mistakes account for most of that gap:

• Checking the wrong layer: a semi-transparent overlay changes the effective background color, and a generator tested against the base color alone will miss it
• Ignoring hover and focus states: WCAG 2.2's Focus Appearance criterion, published in October 2023, requires at least 3:1 contrast between a component's focused and unfocused states
• Using hue alone to carry meaning: a red versus green status indicator disappears for the roughly 8% of men with red-green color vision deficiency covered earlier
• Skipping non-text contrast on icons and borders: a light gray border color, the kind many design systems default to, commonly lands close to 1.6:1 against white, well under the 3:1 minimum

Each of these passes a text-only contrast checker without any warning. None of them touch the text ratio the checker is built to catch.

The fix isn't a better generator. It's treating the generator's output as a starting palette, then running a second pass on states, overlays, and non-text elements before anything ships.

FAQ on Accessible Color Palette Generators

Which legal standards do accessible color palette generators reference?

Most accessible color palette generators check contrast against WCAG's ratio thresholds, since Section 508, the ADA, and Europe's EN 301 549 all cite that standard directly. APCA isn't referenced in current law, even though it's the candidate method for WCAG 3.

Can a color pairing pass WCAG and still be hard to read for a colorblind user?

Yes. WCAG's ratio formula measures luminance difference, not hue difference, so two colors can hit 4.5:1 and still look nearly identical under deuteranopia. A colorblind simulation pass catches that gap; the ratio check alone does not.

Is a free accessible color palette generator good enough, or is a paid tool worth it?

Free tools like this one, Coolors, and Khroma handle single-palette contrast checks well. Paid tools like Stark add non-text contrast checks, team libraries, and design system exports. Those matter once a palette needs to scale across a full product.

What does non-compliant contrast cost a business in legal or usability terms?

Plaintiffs filed 2,452 website accessibility lawsuits in federal court in 2024, according to Seyfarth Shaw's tracking of court filings. Contrast failures are among the most commonly cited defects, alongside missing alt text and unlabeled form fields.

Is APCA more reliable than WCAG for real design work?

APCA models perceived lightness more accurately, according to its developer Andrew Somers, which makes it better at predicting real readability. WCAG remains the legally cited standard. Most teams check both until WCAG 3 formally adopts a perceptual method.

How do you double check a palette that already passed a generator before shipping it?

Test every hover, focus, and disabled state separately, since a generator usually checks only the default pairing. Then verify non-text elements like borders and icons. Finally, view the full palette through a colorblind simulator one last time.

What Should You Check First When an Accessible Color Palette Generator Approves a Palette?

An accessible color palette generator earns its place in production only once its approval is treated as a starting point. A passed contrast ratio confirms text legibility alone.

Three checks decide whether that approval holds up after launch.

• Text pairings first
• Non-text borders and icons second
• Interactive states last

That order follows exposure. Broken text fails immediately, broken borders slow recognition, and broken states surface only once someone interacts.

The trade-off is speed. Checking three thresholds instead of one adds a review step that pure color harmony work never required.

The W3C's WCAG 3.0 working draft, updated September 10, 2026, is still a Working Draft that cannot be cited as a standard. Today's thresholds hold until a future recommendation replaces them.

Teams moving beyond color can work through a full web accessibility checklist next.