DEV Community: James Miller

A Practical Workflow for Building Accessible Color Systems in CSS

James Miller — Sun, 26 Jul 2026 09:01:47 +0000

A dependable color system is more than a set of attractive swatches. It is UI infrastructure: the system has to communicate hierarchy, preserve readability, support interactive states, and remain understandable across themes and different types of color vision.

This is the workflow I use to move from an early palette idea to production-ready CSS tokens.

1. Start with semantic roles, not color names

Naming a token blue-500 tells you what it looks like, but not what it does. A semantic name such as action-primary or text-muted expresses intent and makes future redesigns much easier.

A small interface usually needs these roles:

Canvas and elevated surfaces
Primary, secondary, and muted text
Primary and secondary actions
Borders and focus indicators
Success, warning, error, and informational feedback

Keep the first version intentionally small. It is easier to add a role after observing a real need than to maintain dozens of almost-identical tokens.

2. Generate candidates, then edit with constraints

A harmony rule can give you a useful starting point, but generated colors are not automatically usable UI colors. Saturation, lightness, and contrast still need deliberate adjustment.

For every candidate, ask three questions:

Does it have a clear job in the interface?
Is it distinguishable from neighboring roles?
Can it meet contrast requirements in the context where it will be used?

If you want to prototype and compare the system before turning it into tokens, this free color palette generator lets you lock useful swatches, try harmony modes, check contrast, simulate common color-vision differences, and export the result. I built it to keep those checks in one workflow instead of moving between several disconnected tools.

3. Test combinations, not isolated swatches

Accessibility belongs to a color pair. A hex value cannot be called accessible by itself because its result depends on the foreground or background used with it.

Create a simple contrast matrix for the combinations your product actually renders:

Body text on the main canvas
Muted text on elevated surfaces
Button labels on default and hover backgrounds
Error text on error-tinted surfaces
Focus rings beside nearby borders

As a practical baseline, normal text should reach a 4.5:1 contrast ratio, while large text should reach 3:1. Also remember that contrast is not the whole experience: avoid using color as the only signal for errors, status, or selection.

4. Separate primitives from semantic tokens

Primitives are the available color values. Semantic tokens map those values to jobs. Keeping these layers separate makes a theme easier to maintain.

:root {
  /* Primitives */
  --indigo-50: #eef2ff;
  --indigo-600: #4f46e5;
  --indigo-700: #4338ca;
  --slate-50: #f8fafc;
  --slate-700: #334155;
  --slate-950: #020617;

  /* Semantic roles */
  --color-canvas: var(--slate-50);
  --color-surface: #ffffff;
  --color-text: var(--slate-950);
  --color-text-muted: var(--slate-700);
  --color-action: var(--indigo-600);
  --color-action-hover: var(--indigo-700);
  --color-focus: var(--indigo-600);
}

Components should consume the semantic layer. If the brand color changes later, component code does not need a search-and-replace operation.

5. Design every interactive state

A button is not one color. It has default, hover, active, focus-visible, disabled, and sometimes loading states. Links and form controls have a similar state model.

Do not create a hover state by making the color slightly different and hoping users notice. Check that it remains readable and pair it with another cue when appropriate. Underlines, border changes, icons, and motion can reinforce meaning without relying only on hue.

For keyboard navigation, a focus indicator should be obvious against both the control and its surroundings. A two-layer ring is often more resilient than a single color when controls appear on varied surfaces.

6. Treat dark mode as a mapping, not an inversion

Dark mode needs its own semantic mapping. Simply inverting values can produce glowing text, weak borders, and saturated accents that feel harsher on a dark canvas.

@media (prefers-color-scheme: dark) {
  :root {
    --color-canvas: #020617;
    --color-surface: #0f172a;
    --color-text: #f8fafc;
    --color-text-muted: #cbd5e1;
    --color-action: #818cf8;
    --color-action-hover: #a5b4fc;
    --color-focus: #c7d2fe;
  }
}

Recheck the contrast matrix after remapping. A pair that works in the light theme says nothing about the equivalent dark-theme pair.

7. Validate in real components

Swatch pages hide problems. Put the tokens into actual buttons, form fields, cards, banners, tables, and empty states. Then test zoom, keyboard focus, disabled controls, validation messages, and content with realistic length.

I maintain Free Color Tool while applying this workflow, and the most useful improvements have come from testing colors inside real interface patterns rather than judging a palette in isolation.

Finally, test with more than one signal: automated contrast checks, color-vision simulation, grayscale inspection, and feedback from people using the interface. A good system makes important information readable without forcing color to carry the entire message.

Takeaway

The strongest color systems connect creative exploration to explicit rules. Define roles first, test the pairs that appear in the product, map primitives to semantic tokens, and verify every state in context. That process produces CSS that is easier to change and an interface that is easier to understand.

A Practical Workflow for Recoloring SVG Icons and Checking UI Colors

James Miller — Sat, 25 Jul 2026 07:51:36 +0000

When working on landing pages, dashboards, or small frontend projects, color work often looks simple until you start moving between assets.

A logo has one HEX value, an icon set uses another shade, screenshots contain colors you want to reuse, and the final UI still needs to pass contrast checks. If you skip this step, the interface can start to feel visually inconsistent even when the layout is good.

This is a practical workflow I use for handling image colors, SVG icons, and UI palettes without opening a heavy design app every time.

1. Start with the source color

Most color decisions start from an existing visual reference:

a logo
a screenshot
a product mockup
a brand image
an existing landing page
an icon or illustration

Instead of guessing the color by eye, extract the actual HEX value from the source image. This keeps the design closer to the original brand system.

For example, a blue that looks like #2563EB may actually be closer to #1D4ED8 or #3B82F6. That small difference matters when you are building buttons, links, icons, and hover states.

If you need a quick browser-based picker, this image color picker is useful:

https://freecolortool.com/image-color-picker.html

2. Build a small palette instead of using one color everywhere

A common mistake is using the same color for every UI element. Real interfaces usually need a small range:

primary color
hover color
muted background shade
border shade
text-safe dark version
light version for cards or badges

For example, if your base color is blue, you may need a darker version for hover states and a lighter version for backgrounds.

This is especially important when using Tailwind or design tokens, because you want colors that behave consistently across components.

3. Recolor SVG icons using fill and stroke correctly

SVG icons usually store color in one of two places:

fill for solid icons
stroke for outline icons

A solid icon might look like this:

<path fill="#000000" d="..." />

An outline icon might look like this:

<path stroke="#000000" d="..." />

If you only change fill, an outline icon may not update. If you only change stroke, a solid icon may stay the same. This is why it helps to check both values when recoloring SVGs.

For quick SVG color edits, I use this browser-based SVG recolor tool:

https://freecolortool.com/svg-recolor.html

It is useful when you just need to test a few icon colors and download the updated SVG.

4. Watch out for currentColor

Some SVGs use currentColor instead of a fixed HEX value:

<svg fill="currentColor" viewBox="0 0 24 24">
  <path d="..." />
</svg>

This means the SVG follows the CSS color property of its parent element.

Example:

.icon {
  color: #2563eb;
}

For frontend developers, currentColor can be cleaner than hardcoding HEX values into every SVG file. It makes icons easier to style across buttons, navigation menus, and themes.

5. Test contrast before shipping

A color may look good visually but still fail accessibility checks.

Before using a color for text, buttons, badges, or important UI states, check contrast against the background. This matters for:

button labels
navigation links
alert messages
form states
badges
icon buttons
text over colored backgrounds

If a color fails contrast, do not always change the entire brand palette. Sometimes a slightly darker or lighter shade is enough.

6. Keep the workflow lightweight

For small frontend tasks, the best workflow is usually:

Pick the real color from an image or brand asset.
Create a few supporting shades.
Recolor SVG icons to match the palette.
Check contrast on important UI combinations.
Export/copy values into CSS, Tailwind, or design tokens.

This avoids random color choices and keeps visual decisions consistent across the project.

Final thoughts

Good color work is not only about choosing a nice-looking palette. It is about making sure images, icons, buttons, text, and accessibility requirements all work together.

A small repeatable workflow can save a lot of time, especially when you are building landing pages, MVPs, dashboards, or UI components quickly.

If you are working with image colors or SVG icons, you can try the free browser-based toolkit here:

https://freecolortool.com/