colorca.org No paid content found

HSLuv lets you build a palette where "same lightness" actually looks like the same lightness, which makes it far easier to hit WCAG contrast targets than with HSL or RGB. Use it when you need a systematic palette for a design system — a set of shades and tints that stay perceptually even, plus semantic tokens you can test in both light and dark themes. The workflow below assumes you can pick a base hue and have a way to generate and check colors (a color tool or a small script); the contrast checks themselves are the standard WCAG ratios, not something HSLuv changes.

Why HSLuv instead of HSL or RGB

HSL is not perceptually uniform. In HSL, hsl(60, 100%, 50%) (yellow) and hsl(240, 100%, 50%) (blue) share the same lightness value but look wildly different in brightness. That means a "50% lightness" scale built in HSL produces shades that don't read as evenly spaced, and contrast against text becomes unpredictable.

HSLuv fixes this by defining lightness (L) to match human perception, while keeping the familiar hue/saturation model. Its key properties for palette work:

• L is perceptually consistent — two colors with the same L look equally light/dark, regardless of hue.
• Hue stays stable — you can shift saturation or lightness without the hue drifting.
• Gamut-aware — HSLuv maps to sRGB, so colors you define are displayable (unlike raw CIELUV/LCH, which can fall outside sRGB).

The trade-off: HSLuv's saturation is not the same as HSL's, and very high saturation at extreme lightness may clip. For UI palettes this is rarely a problem.

Step 1: Choose a base hue

Pick one hue (0–360) as your brand/primary anchor. In HSLuv, hue is the same angle convention as HSL, so you can reason about it the same way:

Set your base at a saturation you can sustain across the scale — starting around S 60–100 for a vivid primary is typical. Keep the hue fixed for the whole ramp.

Step 2: Generate shades and tints at consistent lightness

Build your ramp by varying L only, holding H and S constant. A practical scale uses roughly even L steps, for example:

L: 95, 88, 78, 66, 54, 44, 34, 26, 18

Each step is a token (primary-100 … primary-900). Because L is perceptual, the visual jump between steps stays even — something HSL can't guarantee.

Two adjustments worth knowing:

• Lower saturation as you approach the extremes. At L 95 or L 18, high saturation looks neon or muddy. Dropping S by 10–30 points at the ends keeps the ramp usable.
• Keep hue constant unless you deliberately want a hue shift (some systems rotate hue slightly across a ramp for warmth/coolness; that's a stylistic choice, not a requirement).

Step 3: Check contrast before assigning roles

Generate the ramp first, then test — don't design roles and hope contrast passes.

WCAG contrast requirements you'll be checking against:

For each text/background pair you intend to use, compute the contrast ratio. If a pair fails, adjust L first (it moves contrast most predictably), then S. Because HSLuv's L is perceptual, a fixed L difference between text and background tends to produce a more consistent contrast ratio across hues than the same L difference in HSL.

Step 4: Assign semantic tokens

Map ramp steps to roles rather than using raw color names. A minimal token set:

• background — page background (usually a very light or very dark neutral)
• surface — cards, panels (slightly offset from background)
• text-primary / text-secondary — body and muted text
• primary / primary-hover — brand actions
• border — dividers and outlines
• success / warning / error — status colors

Define each token by its HSLuv value so the relationship is explicit, e.g. text-primary = L 20, background = L 98 → a large L gap that reliably clears 4.5:1.

Step 5: Test light and dark themes

A palette that passes in light mode often fails in dark mode if you just invert it. Instead, rebuild the ramp for dark mode with its own L targets:

• Dark backgrounds sit around L 12–20; light-mode backgrounds around L 95–98.
• Text in dark mode needs L high enough to clear 4.5:1 against the dark surface — often L 85+.
• Saturated colors (primary, error) usually need lower saturation in dark mode to avoid glare, and sometimes a slight L bump.

Check every semantic pair in both themes. Common failures: secondary text too close to background, borders below 3:1, and status colors that pass on white but not on a dark surface.

Common pitfalls

• Assuming HSLuv guarantees accessibility. It makes consistent lightness easy; it does not enforce contrast. You still measure ratios.
• Reusing one ramp for both themes. Light and dark need separate L targets.
• Ignoring non-text contrast. Borders, icons, and focus rings need 3:1 too.
• Over-saturating extremes. High S at L 95 or L 15 looks wrong; pull saturation down at the ends.
• Skipping the check step. Always verify final token pairs, not just the ramp.

The result is a palette where lightness is predictable across hues, contrast is verified against WCAG, and roles are defined as tokens — so the system holds up when you add themes or new components.

A color palette is the defined set of colors a digital product uses across its interface, and it is broader than a single brand color: it assigns each color a role (primary, secondary, neutral, semantic) so screens, components, and states stay consistent. It matters most when you are building a design system or shipping UI at scale, because accessibility — especially text and control contrast — depends on how those roles are chosen and paired. Colorca, a tool for designing accessible palettes in HSLuv color space, frames the problem this way: the goal is not a pretty set of swatches but a palette that stays readable and perceptually even across a product.

Palette vs. brand color vs. single color

A single color is just a value. A brand color is one color chosen to represent identity. A palette is a system: multiple colors, each with a job, plus rules for when to use them.

The practical difference: a brand color answers "what color are we?" A palette answers "what color is a primary button, a disabled button, an error message, and body text — and do they still work together?"

Common palette roles

Most product palettes are organized by function, not by hue. A typical structure:

• Primary — the main action color (buttons, links, active states).
• Secondary / accent — supporting emphasis, often for less frequent actions.
• Neutral / gray scale — backgrounds, borders, surfaces, and text. This is usually the largest part of a palette.
• Semantic colors — meaning-carrying colors: success (green), warning (amber/yellow), error (red), info (blue). These are named by meaning, not by hue, so they can be themed.
• State variants — hover, active, focus, disabled, and selected versions of the above.

Naming colors by role rather than appearance (color-action-primary instead of blue-500) is what lets a palette survive a rebrand or a dark-mode theme without rewriting every component.

How palettes hold a design system together

In a design system, the palette is usually the lowest layer of tokens. Components reference tokens, not raw hex values.

For example, a button does not hard-code #2563EB. It references color-action-primary, which resolves to a palette entry. Change the palette, and every button updates at once. This is why palette decisions are high-leverage: one change propagates everywhere, for better or worse.

It also keeps UI components consistent. If every team picks its own grays, you get five slightly different borders. A shared neutral scale prevents that.

Accessibility is a palette property, not an afterthought

Contrast is a relationship between two colors, so it can only be evaluated in the context of a palette — a color that looks fine alone may fail as text on your background.

Two things to check:

• Contrast ratios for text and meaningful UI elements against their backgrounds. WCAG defines minimum ratios (commonly 4.5:1 for normal text, 3:1 for large text and UI components); verify the specific requirement that applies to your product.
• Color-blind friendliness. Never rely on color alone to convey meaning. Pair color with an icon, label, or pattern, and check that semantic colors remain distinguishable under common types of color vision deficiency.

A palette can pass contrast checks and still fail accessibility if, say, success and error are the only signal and look similar to some users.

Why color space matters: HSLuv as one approach

Palettes built by eye in RGB or HSL often have uneven perceived lightness — two colors with the same "lightness" value can look very different in brightness. That makes it hard to build consistent scales and to predict contrast.

HSLuv is a perceptually uniform color space: equal changes in its lightness coordinate correspond more closely to equal changes in perceived lightness. Building a palette in HSLuv lets you generate a neutral ramp or a set of hues that stay visually even, which in turn makes contrast more predictable. Colorca is built specifically around designing accessible palettes in HSLuv for digital products.

This is one method, not the only one. Other perceptually uniform spaces (such as OKLCH) serve a similar purpose. The point is that the color space you build in affects how even and accessible the result is.

A quick way to think about it

If you are starting a palette, decide roles first, then colors:

1. Define the roles you need (primary, neutral scale, semantic set, states).
2. Build the neutral scale first — it carries most of the UI.
3. Choose primary and secondary, then derive state variants.
4. Check contrast for every text/background and control/background pairing.
5. Verify meaning is never color-only.

A palette is working when a new screen can be assembled from it without inventing new colors — and when every combination a user actually sees still passes contrast.

A design system is the shared set of decisions, rules, and building blocks a team uses to design and build a product consistently. Color palettes fit into it as one of its most reused foundations: a palette becomes part of the system when its colors are named, stored as tokens, and given rules for where and how they may be used. If you only have a color swatch file that designers pick from by eye, you have a style reference, not a system.

The core parts of a design system

Most design systems are built from three layers that depend on each other:

• Tokens — named values for the smallest decisions: color, spacing, type size, radius, shadow, duration. A token is the single source of truth for a value, so changing it updates everything that references it.
• Components — reusable interface pieces (buttons, inputs, cards, navigation) assembled from tokens rather than hard-coded values.
• Guidelines — the written rules for when to use what: which color signals an error, how much contrast text needs, when a component variant is appropriate.

Color sits mostly in the token layer, but it reaches into both of the others. A button component consumes color tokens, and the guidelines decide which token a given state should use.

How a color palette becomes part of the system

A palette stops being decoration and starts being infrastructure when you do three things to it.

1. Name colors by role, not by appearance

blue-500 describes what a color looks like. color-action-primary describes what it does. Role-based names survive redesigns: if the brand blue shifts, color-action-primary still points at the right decision, while blue-500 becomes a lie. Keep a raw scale underneath (blue-100 … blue-900) and map roles onto it.

2. Separate primitives from semantic tokens

A two-tier structure keeps the system flexible:

When dark mode or a new brand theme arrives, you remap semantic tokens to different primitives and every component follows without being touched.

3. Define states and contexts, not just base colors

Interactive elements need more than one color. A complete palette entry usually covers default, hover, active, focus, and disabled, plus how the color behaves on light and dark surfaces. Writing these down is what turns a palette into a rule set a team can follow.

Why accessibility belongs in the palette, not after it

Contrast is a property of color pairs, so it has to be decided at the palette level — retrofitting it later means re-auditing every component. Two practical consequences:

• Pair text and background tokens explicitly. Instead of leaving contrast to whoever builds the screen, define approved combinations (for example, which text tokens are allowed on color-surface-raised).
• Check contrast in a perceptually uniform space. Working in a space like HSLuv lets you adjust lightness while keeping perceived hue and saturation stable, which makes it far easier to hit a contrast target without the color shifting character. This is the approach behind HSLuv-based palette builders such as colorca, which is aimed at designing accessible color palettes for digital products in HSLuv color space.

The payoff is consistency: if every team pulls from the same accessible pairs, contrast stops being a per-screen gamble.

Design system vs. style guide

These get conflated, but they answer different questions.

A style guide can be a part of a design system, but on its own it doesn't give engineers anything to import. The test is simple: can a developer build a new screen using only system assets, without asking a designer for a hex value? If yes, you have a system.

A practical starting sequence

1. Build a primitive color scale in a perceptually uniform space so lightness steps are even.
2. Check candidate text/background pairs for contrast before committing them.
3. Assign semantic roles (surface, text, border, action, feedback) on top of the scale.
4. Document which roles may be combined, and which states each interactive role needs.
5. Ship the tokens in a form both design and code can consume, so the palette has one source of truth.

Get the palette and its tokens right first — components and guidelines are much easier to keep consistent once color is no longer a per-screen decision.

A color wheel is a circular arrangement of hues that shows how colors relate, and you use it to pick combinations that look intentional rather than random. The core method: choose a harmony rule (complementary, analogous, triadic, or split-complementary), pick a base hue, then adjust saturation and value so one color dominates and the others support it. This works for any design task — a website, a poster, a brand palette — and the only real requirement is that you can see your colors side by side and test them against real content.

What the color wheel actually shows

The wheel is built in layers:

• Primary colors — red, yellow, and blue in the traditional (painter's) wheel. In digital design you'll also meet the RGB primaries (red, green, blue) and CMYK primaries (cyan, magenta, yellow), which behave differently because they mix light or ink rather than pigment.
• Secondary colors — mixed from two primaries: green, orange, and violet.
• Tertiary colors — mixed from a primary and an adjacent secondary: yellow-green, blue-green, blue-violet, red-violet, red-orange, yellow-orange.

The practical point is distance. Colors near each other on the wheel share undertones and feel calm together; colors opposite each other share nothing and create tension. Every harmony rule is just a rule about which distances to use.

The four variables you're actually adjusting

Most palette problems come from changing hue when the real issue is one of the other three.

A useful habit: pick your hues first, then fix the palette almost entirely with value and saturation. Two colors that clash at full saturation often sit together fine once one is desaturated and darkened.

The harmony rules and when each one fits

Complementary (opposite on the wheel)

Maximum contrast and energy. Good for a call-to-action against a calm background. Risk: at full saturation on both sides it vibrates uncomfortably. Fix by letting one color dominate and using the other only in small areas.

Analogous (neighbors on the wheel)

Low contrast, cohesive, calm. Good for backgrounds, gradients, and mood-driven work. Risk: not enough separation for interactive elements — you'll need value contrast to make a button readable.

Triadic (three evenly spaced hues)

Balanced and lively, with one color usually leading and two accenting. Good when you need several distinct categories (charts, tags, sections). Risk: can feel childish if all three are fully saturated.

Split-complementary (a base plus the two colors adjacent to its complement)

Nearly as much contrast as complementary but easier to balance. A safe default when you want punch without vibration.

Tetradic / square (four hues)

Rich but hard to control. Treat one color as dominant, one as secondary, and the remaining two as small accents.

Applying a rule to a real project

1. Name the job of each color. Typically: background, surface, primary text, secondary text, primary action, and one accent/state color. Decide this before choosing hues.
2. Pick a base hue that matches the subject or brand, not your personal favorite.
3. Choose a rule based on how much energy the design needs — analogous for calm, complementary or split-complementary for emphasis.
4. Assign roles by area. The dominant color should cover the most space; the accent should cover the least. A palette fails most often because the loudest color got the largest area.
5. Tune value and saturation until text is readable and the hierarchy is obvious at a glance.
6. Test in context. Put the palette behind real headings, body text, buttons, and disabled states — not just swatches.

Tools like Paletton (formerly Color Scheme Designer) exist specifically for step 3: you set a base color on a wheel, choose a harmony mode, and it generates the related hues so you can preview combinations instead of calculating angles yourself.

Checking contrast and accessibility

Harmony and readability are separate problems. A palette can be perfectly harmonious and still unusable.

• Body text needs substantially more contrast against its background than large headings or decorative elements do.
• Never rely on color alone to convey meaning — pair it with an icon, label, or shape, since color-blind users may not distinguish your red/green states.
• Check every text/background pair you actually ship, including hover, focus, disabled, and error states.
• Test the palette in grayscale. If the hierarchy collapses, your value contrast is too weak.

Common mistakes and how to fix them

Muddy palettes. Usually caused by mixing too many hues at mid saturation and mid value. Fix: reduce to two or three hues and push them apart in value.

Clashing colors. Often two fully saturated complements fighting for attention. Fix: desaturate one, shrink its area, or shift to split-complementary.

Everything looks the same. Too many analogous colors at similar values. Fix: keep the hues, widen the value range.

The accent doesn't pop. The accent is too close in value to the background, or it's used in too many places. Fix: increase its contrast and restrict it to one job.

Palette looks fine as swatches, wrong in the layout. Colors interact with surrounding colors and with area size. Fix: always preview in the actual composition.

Quick reference

• Calm, cohesive design → analogous
• Strong emphasis on one element → complementary, used sparingly
• Multiple equal categories → triadic
• Contrast with less risk → split-complementary
• Fixing a bad palette → adjust value and saturation before changing hue