Start with roles, not color names
A design system needs color roles that describe purpose: background, foreground, surface, border, primary action, primary text, focus ring, success, warning, and destructive. Names like blue, teal, and lavender are useful for designers, but they do not tell developers which combinations are safe.
Preview the palette in real components
Buttons, cards, forms, alerts, links, charts, and focus indicators all use color differently. A preview catches the decisions that a static swatch board hides: whether link text is distinguishable, whether a focus indicator is visible, whether chart bars remain readable, and whether error states have enough contrast against the surface behind them. Color is only half of chart accessibility — for the data table, SVG labelling, and never-color-alone series cues, see the accessible charts & data visualization guide.
Light mode
Light mode usually needs darker foreground colors, visible borders, and accent colors that remain readable on white or near-white surfaces.
Dark mode
Dark mode needs larger visual separation between surfaces. Borders, muted text, and focus rings often need to be lighter than their light-mode equivalents.
Accessible palette workflow
Start with real UI roles
Define background, foreground, primary, secondary, accent, border, focus, success, warning, and destructive colors before naming decorative swatches.
Test foreground and background pairs
Check the actual text and component pairings that will appear in the interface, including normal text, large text, buttons, links, and form labels.
Preview component states
Review hover, active, disabled, selected, warning, error, and focus states because state colors often fail even when default colors pass.
Validate light and dark mode separately
Create separate surface, border, and text choices for dark mode instead of simply inverting a light mode palette.
Document token usage
Write clear rules for which tokens can be used together so designers and developers do not create inaccessible combinations later.
Accessible Color FAQ
Is a color palette itself WCAG compliant?
Not by itself. WCAG contrast depends on the foreground and background colors used together, the text size, and the component context. A palette can support accessibility, but the pairings must still be tested.
What contrast ratios should UI teams target?
Use at least 4.5:1 for normal text, 3:1 for large text, and 3:1 for non-text UI components such as borders, focus indicators, icons, and chart elements. Use 7:1 for normal text when targeting WCAG AAA.
Why do disabled states still matter?
Disabled controls are often exempt from some contrast requirements, but extremely faint disabled states can confuse users. They should be visibly different while still understandable in the overall layout.
Do charts need accessible colors?
Yes. Chart colors should have enough contrast against their background and should not rely on color alone. Use labels, patterns, ordering, or legends so information remains clear for color blind users.