01

Choose the encoding before the hues

First decide whether color represents categories, an ordered quantity, or divergence around a meaningful midpoint. A categorical palette assigns distinct identities and must not imply an order that the data lacks. A sequential scale changes systematically from low to high. A diverging scale uses two directions around a stated center. Mixing these roles produces misleading readings even when every individual color looks pleasant. Keep the number of simultaneous categories small enough to label and distinguish in the chart.

  • Use distinct hues for unordered categories and keep their mapping stable across related views.
  • Use an ordered lightness progression for magnitude, with a legend that states direction and units.
  • Use a diverging scale only when the midpoint has a defensible meaning such as zero or a target.
02

Never make color the only key

WCAG 2.2 requires that color not be the sole visual means of conveying information. A legend made only of colored squares still asks the reader to match colors. Add direct labels where space permits, and use marker shapes, line styles, patterns, or spatial grouping as redundant channels. Redundancy is especially important for thin lines, tiny points, adjacent areas, printouts, and screenshots. The alternative cue must remain visible at the size and density in which the chart is actually used.

  • Label important lines or regions directly instead of forcing repeated trips to a separate legend.
  • Combine color with dash patterns or marker shapes, but keep each pattern visually simple.
  • Expose category names in accessible text and in tooltips that are also reachable without a mouse.
03

Measure contrast in context

For graphical objects and states needed to understand content, WCAG non-text contrast generally requires at least 3:1 against adjacent colors. The relevant comparison is contextual: a bar against the plot background, one touching region against another, or a focus indicator against both sides it crosses. Text labels follow text contrast requirements, commonly 4.5:1 for normal text and 3:1 for qualifying large text. Test rendered antialiasing and thickness because a compliant numeric pair can still become hard to locate when marks are tiny.

  • Measure each essential mark against the color immediately surrounding it in the final chart.
  • Check labels independently; a high-contrast bar does not make low-contrast text acceptable.
  • Retest hover, selection, muted, focus, and disabled-like states rather than only the default image.
04

Build a maintainable category set

Begin with a neutral surface and text system, then choose category colors that differ in more than one channel. Reserve semantic colors such as error red for semantics if the surrounding product already uses them that way. Define tokens by category role rather than by a color name, document the intended background, and provide a fallback pattern or shape. When categories exceed the tested set, group minor values into an “Other” category or switch to interaction and filtering rather than generating barely distinguishable colors.

  • Name tokens by role, such as chart-category-1, and store the tested foreground and background pair.
  • Keep the same category mapped to the same token across panels, filters, tables, and exports.
  • Specify a deterministic overflow strategy instead of recycling colors for unrelated categories.
05

Design legends and interaction together

A legend should state the mapping without hiding the data. Preserve source order when it is meaningful; otherwise use a documented stable order. Let users highlight a category from both the legend and the chart, with equivalent keyboard operation and visible focus. Do not communicate selection solely by saturation or opacity. Pair the state with an outline, marker, label change, or isolation of nonselected marks. Tooltips supplement labels but cannot be the only place where essential values or category names appear.

  • Make interactive legend controls real keyboard-focusable controls with clear accessible names.
  • Show selection with a boundary or shape change in addition to a color or opacity change.
  • Provide exact values in a table or accessible equivalent when the visual cannot expose them reliably.
06

Test with realistic data and outputs

Palette review must use crowded, sparse, extreme, missing, and overlapping data rather than an ideal sample. Inspect the chart at target size, browser zoom, forced-colors mode, and grayscale; simulate color-vision differences as an additional check, not as proof of accessibility. Print or export when those workflows matter. Ask reviewers to identify categories and values without prompts, then record failures by mark and context. Keep the test dataset and contrast pairs so later theme changes can be evaluated reproducibly.

  • Test the maximum supported categories and the smallest supported mark size on every intended background.
  • Verify missing values, negative values, alerts, focus, and selection without relying on a hue alone.
  • Document palette limits and choose another visualization when the data exceeds those limits.
S

Primary sources

The factual claims in this article are checked against these published specifications.

  1. W3C WCAG 2.2 — Use of Color
  2. W3C WCAG 2.2 — Non-text Contrast
  3. W3C WCAG 2.2 — Contrast (Minimum)