A founder I spoke with had picked her site’s colors in Coolors in about ten minutes — a navy, a soft grey, and a coral accent that all sat together nicely on the palette export screen. Weeks later, a reader emailed to say the “Add to Cart” button was almost invisible against the hero background on his laptop. Nothing about the palette was wrong in the way palette-generator tools measure “wrong.” The colors were harmonious. They just failed a completely different test that Coolors’ default view never forced her to run: could someone actually read the text sitting on top of them.
That’s the gap this post is about. Choosing colors and fonts for a new WordPress site covers the broader decision — how many colors to pick, what each one is for, how fonts pair with them. This post goes narrower and stays there: which tools actually generate palette candidates well, which tools catch the contrast failures a color wheel can’t see, and what the WCAG numbers those tools are checking against actually require. If you haven’t picked a palette yet, start with the broader guide first. If you already have three or four hex codes and want to know whether they’ll hold up, this is the post that tells you.
The Whole Process: Generate a Palette, Then Check Every Pairing
Generate candidates with Coolors, Adobe Color, Khroma, or Paletton — which one to reach for depends on whether you want speed, deliberate control over a harmony rule, a trained personal aesthetic, or a live page preview, covered tool by tool below. Then check every real pairing you’re actually going to use — not the palette in the abstract — against WCAG’s actual thresholds using WebAIM, Chrome DevTools, or Stark: 4.5:1 for normal text, 3:1 for large text and UI components. Watch for the pairings people forget: hover states, dark mode, anything relying on color alone to convey meaning. A palette that’s never been run through this second step hasn’t actually been finished, no matter how good it looks in the generator.
Generating a Palette and Checking One Are Two Different Jobs
Palette generators — Coolors, Adobe Color, Khroma, Paletton — are built to answer “do these colors look good together.” They work from color theory: complementary pairs, analogous ranges, triads, or in Khroma’s case, a model trained on colors you personally like. None of that math has anything to do with whether white text on your new accent color is legible. Contrast is a separate calculation — the luminance difference between two specific colors placed directly on top of each other — and a palette can pass every harmony rule a generator applies while still failing it badly.
The practical fix is running two different tools in sequence, not expecting one to do both jobs. Generate candidates with a palette tool. Then take the actual foreground/background pairs you’re going to use — body text on your background, button text on your accent, link color on your background — and run each one through a contrast checker before you commit. Skipping the second step is the single most common reason a palette that looked fine in the generator fails in production.
Palette Generation Tools, Compared
Four tools cover most of what a WordPress site owner actually needs, and they work in genuinely different ways rather than being interchangeable skins on the same idea.
Coolors is the fastest way to get from nothing to a five-color palette. Hit the spacebar to reroll the whole set, lock the colors you want to keep, and reroll the rest — or extract a palette directly from a photo. The free tier covers palette generation, exploring millions of saved palettes by topic, and a built-in accessibility check on your current set. The paid Pro tier (around $3/month) adds a public profile page, richer PDF exports with color-blindness previews, and a palette visualizer that drops your colors onto real UI mockups. For a first pass at candidates, this is the tool most people should open first.
Adobe Color works from an interactive color wheel instead of random generation. Pick a base color, choose a harmony rule — complementary, analogous, triadic, split-complementary, monochromatic — and it builds a structured scheme around that rule, up to ten colors, adjustable by dragging points on the wheel. It also extracts palettes from an uploaded image and includes its own contrast checker for pairing text against background. It requires a free Adobe ID (not a paid Creative Cloud subscription) and is the better choice when you want deliberate control over the relationship between colors rather than a fast reroll.
Khroma takes a different approach entirely: you pick 50 colors you’re drawn to during setup, and it trains a small model in your browser on the hue, saturation, and value pattern in your choices. From there it generates endless combinations filtered to your taste, viewable as text, a poster mockup, a gradient, over an image, or as a raw palette — and every combination it shows already carries hex, RGB, CSS, and a WCAG accessibility rating. No signup, runs entirely client-side. It’s the slowest of the four to set up and the most useful once it’s trained, especially if “harmonious but generic” is a problem you keep running into with the faster tools.
Paletton is the oldest of the four and still the most transparent about the color theory behind what it’s doing. Five explicit scheme modes — monochromatic, adjacent, triad, tetrad, free style — on an interactive wheel, with a live preview of the palette applied to a mocked-up webpage layout so you can see it in context before exporting to CSS, SASS, LESS, or a plain text swatch list. It has no dedicated contrast checker built in, which is the one real gap in an otherwise complete free tool.
| Coolors | Adobe Color | Khroma | Paletton | |
|---|---|---|---|---|
| Method | Random reroll, lock & regenerate, or image extraction | Color-wheel harmony rules | AI model trained on 50 colors you pick | Color-wheel scheme modes |
| Account needed | No (free), yes for saving/Pro | Free Adobe ID | No | No |
| Built-in contrast check | Yes (accessibility panel) | Yes (contrast checker) | Yes (WCAG rating per combo) | No |
| Price | Free / Pro ~$3/mo | Free | Free | Free |
| Best fit | Fast first-pass candidates, image-based palettes | Deliberate control over a harmony rule | Matching a personal or brand aesthetic over time | Seeing the palette live on a page layout before exporting |
Three of the four now build a contrast check into the generator itself — worth using as a first filter, but not worth trusting as the final word. A generator’s built-in check usually tells you whether a color pair meets a threshold in the abstract. It doesn’t know your actual font size, weight, or whether that pairing is going into a 14px caption or a 48px hero heading — and that distinction changes which WCAG threshold even applies, which is exactly what the next section is about.
What WCAG Actually Requires, in Real Numbers
“Check the contrast” gets thrown around as a single instruction, but WCAG defines several different thresholds depending on what you’re looking at, and the tools above are checking against the specific numbers below — not a vague “readable” standard.
| What’s being checked | Level AA (the usual target) | Level AAA (stricter) |
|---|---|---|
| Normal body text | 4.5:1 | 7:1 |
| Large text (18pt/24px+, or 14pt/18.66px+ bold) | 3:1 | 4.5:1 |
| UI components & graphics (button borders, form field outlines, icons that convey meaning) | 3:1 | Not defined separately |
The row most palettes fail without anyone noticing is the third one. WCAG 2.1’s Success Criterion 1.4.11 (Non-text Contrast) requires a 3:1 ratio for interactive component boundaries and meaningful graphics — not just the text sitting inside them. A button with high-contrast white text on a colored fill can still fail this criterion if the button’s border, or the color itself against the page background, doesn’t clear 3:1. It’s a real, separate check most people never run because it isn’t about text at all. WCAG 2.2, the current version as of 2026, keeps these same numeric thresholds and adds new success criteria around focus indicators (2.4.11 Focus Not Obscured, 2.4.13 Focus Appearance) that matter for the same reason — if your accent color is also what a keyboard focus ring uses, it needs to clear contrast against the surrounding page too.
AA is the practical target for almost every content site, and the one the tools default to. AAA is a genuinely higher bar — 7:1 for body text rules out a lot of mid-tone color choices entirely — and is usually reserved for government, healthcare, or education sites where it’s a stated requirement, not a nice-to-have.
Contrast-Checking Tools, Compared
WebAIM’s Contrast Checker is the reference tool almost everyone eventually lands on. Paste in a foreground hex and a background hex, or pick colors visually, and it returns the exact ratio plus a pass/fail against AA and AAA for both normal and large text simultaneously. An alpha slider handles semi-transparent text or overlays, and a lightness slider lets you nudge a failing color until it passes without leaving the page. It also works as a bare API — append &api to any permalink and it returns the ratio as JSON, which is enough to script a batch check across an entire palette’s pairings without opening the tool by hand for each one.
Chrome DevTools is already installed on every machine that has Chrome, which makes it the lowest-friction option once you’re actually building the page rather than still picking colors. Open the inspector, hover any element, and the color picker shows the current contrast ratio along with the AA/AAA threshold lines directly on the lightness slider — drag until you cross the line and you have a passing color. The CSS Overview panel goes further and lists every low-contrast text element on the page at once, which is the closest thing to a one-click audit of an already-built page. A newer setting (Settings → Experiments → enable APCA) swaps the ratio display for the APCA algorithm covered below, useful for previewing where the standard is heading without waiting for it to become mandatory.
Stark is the tool worth knowing about if color decisions happen in a design file before they ever reach WordPress — it plugs into Figma, Sketch, and Chrome. Beyond the same pass/fail contrast check, its vision simulator shows a design as it would appear under four types of color blindness plus blurred vision, low contrast, and glare, which none of the other tools here do. The free tier covers the core contrast checker; Pro (roughly $99/year) adds automatic color suggestions and library-wide color auditing, which only pays off if you’re maintaining a shared design system across more than a solo project.
| WebAIM Contrast Checker | Chrome DevTools | Stark | |
|---|---|---|---|
| Where it runs | Browser, standalone page | Built into Chrome | Figma, Sketch, Chrome extension |
| Best for | Checking one pairing quickly, or scripting via its API | Auditing an already-built page in bulk | Catching issues before a design ever reaches code |
| Color-blindness simulation | No | No | Yes (4 types, plus other vision conditions) |
| Price | Free | Free | Free / Pro ~$99/yr |
Why the Ratio You Get Today Might Not Be the Ratio That Matters Tomorrow
The 4.5:1-style ratios above come from WCAG 2’s contrast formula, which has a known weakness: it’s a mathematical calculation of luminance difference, not a model of how humans actually perceive contrast. It treats a thin, light-weight font and a bold font as equally readable whenever the color values match, even though a thin stroke needs noticeably more contrast to stay legible at the same size. It also doesn’t care which color is on top — swap the text and background colors and WCAG 2’s ratio stays identical, even though the two versions don’t look equally readable to a real eye.
APCA (the Advanced Perceptual Contrast Algorithm) is the replacement candidate under development for WCAG 3. Instead of a 1:1–21:1 ratio, it outputs an Lc (lightness contrast) value roughly between 0 and ±106, and it factors in font weight and size directly rather than treating all text the same — and direction matters, so light-on-dark and dark-on-light aren’t automatically equivalent the way they are under WCAG 2. It’s genuinely more accurate to how contrast is actually perceived. It is not, as of 2026, a legal or regulatory requirement anywhere — WCAG 3 itself is still years from being finalized, and its exact contrast method hasn’t been locked in. There’s nothing to act on here yet beyond awareness: if you want a preview, Chrome DevTools’ APCA experiment (mentioned above) will show you the Lc value for your current colors, but keep designing to the WCAG 2.1/2.2 ratios in the table above until that changes.
Passing the Contrast Math Isn’t the Whole Accessibility Question
A palette can clear every ratio in the tables above and still fail a reader in a different way: roughly 1 in 12 men and 1 in 200 women have some form of color vision deficiency, most commonly red-green. Contrast checkers measure lightness difference, not hue difference — a bright red error message on white can pass 4.5:1 comfortably while still being genuinely hard for a color-blind reader to distinguish from a similarly bright green success message a few pixels away.
The fix isn’t a different contrast tool — it’s a design habit: never let color alone carry meaning. A form field that turns red on error needs an icon or text label alongside it, not just the color change. A “sold out” tag shouldn’t rely on being red versus a green “in stock” tag with no other distinguishing mark. Stark’s vision simulator (above) is the fastest way to actually see this rather than take it on faith — running a page through its color-blindness views for a minute usually surfaces the problem immediately.
A Worked Example: Checking One Real Palette
Say a palette candidate out of Coolors comes back with a burnt-orange accent, hex #E8590C, meant for a call-to-action button on a white page. Run it through WebAIM against white (#FFFFFF) and it comes back at roughly 3.2:1. That fails the 4.5:1 requirement for normal text — so white body copy or a small price label in that orange would be a real accessibility failure. But it clears the 3:1 threshold for large text and for UI components, which means a bold 20px+ button label in that same orange, or the button’s border against the page background, both pass.
The same hex code is simultaneously a pass and a fail on the same page, depending entirely on what it’s used for. This is the concrete reason “check the palette” isn’t a single yes/no action — it’s checking each actual pairing against the threshold that applies to that specific use, which is exactly what the tables further up this post are for. In this case, the fix isn’t abandoning the orange — it’s restricting it to large/bold text and UI elements, and using a darker shade (or the near-black body text color) anywhere the copy is small.
Where This Gets Skipped in Practice
Checking only the “obvious” text. Body copy on the main background gets checked; the same accent color used for a badge, a table header fill, or placeholder text in a form field doesn’t. Every place text sits on a non-default background needs its own check.
Testing against the wrong background. A color that passes against pure white can fail against the off-white or light-grey tint most themes actually use for cards and sections. Test against the real rendered background, not the palette’s swatch color.
Forgetting hover and focus states. A link that passes at rest often shifts to a lighter or more saturated version on hover — and that state needs the same 4.5:1/3:1 check as the resting state, not an assumption that “close enough” carries over.
Not re-checking after adding dark mode. Every pairing that passed in light mode gets inverted, not just recolored — text that was dark-on-light becomes light-on-dark, and that’s a completely new contrast calculation, not the same one in reverse. A palette isn’t “dark-mode-ready” until someone has run the dark variant of every pairing through a checker separately.
How Much of This a Small Site Actually Needs
For a single content site or small business build, the free tier of Coolors or Adobe Color to generate candidates, plus WebAIM or Chrome DevTools to check the two or three real pairings that matter (body text, link color, button text) is enough — that’s a fifteen-minute pass, not a project. Stark’s paid tier and a formal color-blindness audit start to earn their cost once there’s a shared design system multiple people are drawing from, or once the site is handling anything transactional where a missed error state has a real cost to a real user. Most WordPress sites in this second category never get there, and that’s fine — the free tools cover the actual requirement.
Once the palette itself is settled and checked, write the final hex codes down somewhere durable rather than trusting memory or a half-finished export file — see how to create a website style guide for turning this into a reusable reference. The same contrast discipline applies to icons and to a logo and favicon — anywhere a color sits against a background, the same check applies, not just body text. And for the wider accessibility picture beyond color — heading structure, alt text, keyboard navigation — making a WordPress site accessible covers the rest of what contrast is one part of.
Etienne Basson works with website systems, SEO-driven site architecture, and technical implementation. He writes practical guides on building, structuring, and optimizing websites for long-term growth.