Palette Generator: Correcting Accessible UI Color Flaws

Start With Luminance, Not Hue

Here is the single most useful shift you can make today: before you touch a hue slider, sort your potential palette colors by relative luminance. Most designers open a palette generator, pick a brand color, and immediately start spinning the hue wheel to find "harmonious" companions. That instinct is backwards. Accessibility is governed first by contrast, and contrast is governed by luminance. If your base colors share similar luminance values, no amount of hue rotation will save you.

The mistake is treating color harmony as a hue problem. It is a luminance problem wearing a hue costume. When you generate a split-complementary scheme, for example, you might land on #2D7DD2 (a strong blue at roughly 0.22 relative luminance) and #FF6B35 (an orange at roughly 0.36 relative luminance). Both feel "vibrant." Both feel "brand-ready." But if you place either as text on a white background, the blue passes WCAG AA at 4.6:1 contrast while the orange fails at 2.9:1. The harmony looked correct. The accessibility was broken from the first pixel.

The fix: use an in-browser palette generator that exposes luminance values alongside hex codes. Build your palette by selecting colors across distinct luminance bands—0.05, 0.20, 0.45, 0.75—then assign hues within those bands. This guarantees you always have colors that can serve as text, borders, surfaces, and accents without scrambling to fix contrast later.

Stop Generating Tints With Simple Opacity

Here is a mistake that quietly poisons design systems. A developer needs a "lighter version" of a primary button color, so they take #1A73E8 and apply 80% opacity, then 60%, then 40%. The result looks like a gradient. It feels organized. It fails in production.

The problem is that opacity-based tints blend with whatever sits behind them. On a white background, 40% opacity #1A73E8 becomes a pale blue. On a light gray card background, that same 40% becomes a different blue. On a dark mode surface, it becomes something else entirely. Your "color system" is actually three different systems depending on the background.

The Correct Approach: Mix Toward A Target

Instead of opacity, use a palette generator that mixes your base color toward a fixed target—typically white for light tints and a near-black like #0D1117 for dark shades. This produces absolute hex values that are stable regardless of background. #1A73E8 mixed 40% toward white yields #7BA9F0, a concrete color you can audit for contrast, assign a semantic name, and reuse with confidence.

A good in-browser tool will generate a full ramp—50, 100, 200, through 900—using this mixing method and show you the WCAG contrast ratio for each step against both white and black. If step 300 reads 3.2:1 against white, you immediately know it works as a large-text color but not as body text. No guessing. No retroactive fixes.

Test Harmonies Against Real UI Contexts, Not Swatches

Color harmonies look perfect in isolation. Complementary pairs sing on a blank canvas. Analogous triples feel sophisticated in a grid of swatches. Then you drop them into an actual interface—button on card, text on surface, border on input field—and the harmony collapses. The orange that looked stunning next to the blue now vibrates against a gray background. The teal accent that felt fresh on white becomes muddy on an off-white panel.

The mistake is evaluating color in a vacuum. UI color harmonies must be evaluated in the context where they will live.

Build Contextual Preview Tiles

Use a palette generator that renders your colors into simulated UI components: a button, a text block, a card with a border, a hover state. This is where browser-based tools have a genuine advantage over static design files. The browser renders colors through the same color management pipeline your production app uses. If your generator shows a button with #FFFFFF text on #5B21B6 background and reports 9.7:1 contrast, you can trust that number because the browser computed it from the same sRGB values your CSS will deliver.

Check each harmony against at least three contexts: a light surface, a dark surface, and a mid-tone surface. If your accent color works on all three, it is genuinely harmonious for UI use. If it only works on white, it is a marketing color, not a product color.

Generate Dark Mode Pairs Simultaneously

The classic workflow is: design the light theme, finish it, ship it, then "adapt" for dark mode. This almost always produces a dark theme that feels like a photographic negative of the light theme—washed out, contrast-depleted, and visually exhausting.

The mistake is sequential thinking. Accessible color harmonies should be generated as pairs from the start. Every color you choose for light mode needs a partner that serves the same semantic role in dark mode, and that partner needs its own contrast verification.

Use Inverted Luminance With Hue Preservation

Take your light-mode primary #1A73E8 (luminance 0.22, hue 217°). For dark mode, preserve the hue but invert the luminance toward the lighter end of the scale—something like #8AB4F8 (luminance 0.58, same hue family). On a dark surface like #1E1E1E, this lighter variant achieves 6.1:1 contrast, passing WCAG AA comfortably. The brand identity stays recognizable because the hue is preserved, but the luminance shift ensures readability on the inverted background.

An in-browser palette generator that supports dual-theme output lets you see both palettes side by side, with contrast ratios computed for each. You catch problems immediately—like a light-mode warning yellow that becomes invisible on a dark background—before they reach a pull request.

Verify Color-Blind Safety Before Freezing The Palette

You have a green success state and a red error state. They contrast beautifully against your white background. Your ratio checks pass. Then a user with deuteranopia—roughly 6% of men—opens your app and cannot distinguish success from failure. The colors that looked distinct are, to their visual system, nearly identical.

This is the most common accessibility failure in UI color systems, and it happens because contrast tools measure luminance difference, not perceptual hue difference across vision types.

Simulate Three Vision Types Minimum

Your palette generator should include simulation for deuteranopia, protanopia, and tritanopia. When you generate a harmony, run it through all three simulations. If your success and error colors collapse to the same perceived shade under deuteranopia simulation, you need a secondary differentiator—shape, icon, or position—or you need to shift one color's hue significantly.

A practical test: if your palette generator can export a simulated screenshot of your UI under each vision type, save those screenshots. They become documentation. When someone questions why your error red is #DC2626 instead of the brand team's preferred #E11D48, you show them the simulation where the brand red disappears against your warning amber under deuteranopia. The conversation ends.

Export In Formats That Preserve Semantic Meaning

The final mistake happens at the handoff. You have built a thoughtful, accessible, contrast-verified palette. Then you export it as a flat list of hex values. The next person to touch the codebase sees #1A73E8 and #1557B0 with no indication that one is a primary color and the other is its accessible dark variant for hover states. They use them interchangeably. The system degrades.

Export with semantic naming. A quality in-browser palette generator will produce CSS custom properties, Tailwind config entries, or JSON tokens that carry meaning: --color-primary-default, --color-primary-hover, --color-primary-disabled. Each token should include its contrast ratio against its intended background in a comment. This turns your palette from a list of colors into a contract—one that says --color-primary-default on --color-surface-base will always meet 4.5:1 contrast, and any change to either value requires re-verification.

That contract is the real output of an accessible palette generator. Not the hex values. The verified relationships between them.