A chart is assembled from a small number of repeating elements, and each one should be a component with its own token set: the plot area (the grid and axes), the mark (the bar, the point, the line), the legend, the tooltip, the axis label and the empty state.

If you build those six, every chart in the product inherits the same spacing, the same gridlines and the same legend behaviour, and adding the seventh chart type takes an afternoon instead of a sprint.

The question behind a chart is usually one of four: comparison, trend, distribution or relationship. Match the form to the question and the chart becomes obvious.

The most common mistake is not choosing badly — it is choosing *bar* for a trend, or *line* for a comparison. A line implies continuity between points that may not exist, and a bar implies a baseline comparison that a line chart cannot make.

The five drawings below are the same component wearing a different mark. The line asks *how did it change over time?*, the bar asks *which of these is bigger?*, the area asks *how do the parts make the whole?*, the pie asks *how is one whole divided?*, and the scatter asks *do these two things move together?*

Every one of them follows the same rules: the categorical palette in a fixed order, a zero baseline where a baseline exists, direct labels instead of a legend, a second channel besides hue, and the table of numbers underneath — which is the only version of the chart that a screen reader can use.

A single palette cannot do all three. Categorical colours separate unrelated series and must be distinguishable from each other — that is a qualitative palette. Sequential colours show magnitude along one dimension, from light to dark of a single hue, and must be monotonic in lightness. Diverging colours show a value around a meaningful midpoint, usually zero.

Build each as its own token group. Trying to use one ramp for all three is the root cause of most unreadable dashboards, because a categorical pair needs maximum hue separation while a sequential ramp needs none.

Roughly one in twelve men has some form of colour vision deficiency, and low vision, glare and bad projectors affect far more people than that. Every chart must survive the loss of colour.

The reliable fixes are unglamorous: direct-label the series instead of relying on a legend, add a pattern or a marker shape to distinguish fills, keep gridlines subtle but present, and — the one that solves most of it — provide the underlying data as a table. A screen reader user gets a real answer from the table; a sighted user gets the shape from the chart.

For the full accessibility strategy (WCAG 2.2 AA baseline, keyboard, semantics, motion, testing), see the <a href="/design-system/accessibility">Accessibility</a> chapter.

A layout that reflows is usually fine. A chart that reflows can become unreadable: a bar chart squeezed to 320px has unreadable axis labels, a legend of eight entries wraps into a wall, and a tooltip ends up off-screen.

Decide at which width the chart changes *kind* rather than just changing size. Below the breakpoint, a grouped bar chart becomes a horizontal bar chart, and a dense time series becomes a summary sparkline with the detail in the table.

A chart component is not done until it handles the boring states. Empty means there is no data — say why and say what to do next, never render an empty axis. Loading means show the frame and a skeleton so the layout does not jump. One point means do not draw a line between two coordinates you do not have. Error means keep the frame and explain the failure.

Every one of these is a design decision, and every one of them is a moment where a chart library will happily render something meaningless unless you handle it.