Accessible charts: a publishing checklist with a worked example

An accessible chart lets readers recover the message and the evidence when they cannot distinguish its colours, see the image, or use a pointer. This guide is for people publishing charts in reports, slide decks, and web pages.

Start with the question

Write the question the chart answers before selecting a chart type. “How did the three teams' response times change?” gives you a useful design constraint. “Show the metrics” does not.

For a simple category comparison, try a labelled bar chart. For a sequence over time, try a line chart with an explicit time axis. This is a starting point: the right choice depends on the question and data. If there are only three values and no meaningful visual pattern to reveal, a short sentence or table may be clearer.

Give every essential encoding a second route

W3C's guidance on use of colour explains why colour cannot be the only visual means of communicating information. Label series directly where practical; combine colours with line styles, marker shapes, patterns, or text.

Check the chart in greyscale. If “the red line” is the only way to identify a series, revise the labels. Greyscale is a useful diagnostic, but passing it does not establish overall accessibility.

Also check text size at the final published size. A label that is readable in an editor can become tiny when a figure is placed in a document. Explain abbreviations, state units, and avoid requiring readers to rotate their heads to read labels.

Publish a text alternative and the values

W3C's complex-images tutorial describes a short alternative that identifies the image and a longer description conveying its essential information. A useful longer description gives the main pattern, important comparisons, and relevant qualifications. Provide a data table when readers need exact values.

The text should answer the same question as the chart. An inventory of colours and shapes rarely does that on its own.

Worked example: support response times

The following fictional data represent each team's monthly median time to first response, in hours. They are illustrative, not measured business results.

Month	Team A, hours	Team B, hours	Team C, hours
January	12	8	10
February	9	8	11
March	6	8	12

Chart plan: use three lines over January–March, with direct team labels and different marker shapes. Label the vertical axis “Median first-response time (hours)”. State that lower values mean faster responses. Show the same measurement window for every series.

Possible short alternative: “Line chart of monthly median first-response times for three teams, January to March. Description and values follow.”

Possible longer description: “Team A's median first-response time decreased each month, from 12 hours in January to 6 in March. Team B remained at 8 hours. Team C increased from 10 to 12 hours. Team A had the longest time in January and the shortest in March.”

Necessary qualification: this chart compares team medians, not every individual request. Without request counts and distributions, it cannot show whether most requests improved or explain why the teams differed. Do not infer that a staffing change caused the trend from this chart alone.

Avoid misleading comparisons

State the denominator for percentages. “Resolved within a day” needs a definition of eligible requests and a time window.
Use consistent units across comparable panels.
Show missing periods as missing rather than silently connecting them as if values were observed.
For bars whose length represents magnitude, start the quantitative axis at zero. For other chart types, make any restricted scale clear and consider whether it exaggerates differences.
Distinguish estimates from observations and explain uncertainty when it affects interpretation.

Check the delivery format

For a web chart, test the page's reading order and the route to its description and data. If tooltips reveal essential information, provide an equivalent route that works without hovering. Interactive controls need meaningful labels and keyboard operation.

For slides or PDFs, check the exported file as well as the editable source. Keep the explanation close to the figure, and verify that text remains readable. A text alternative entered in an authoring tool may not survive every export path.

Reusable review checklist

The question and main takeaway are explicit.
Units, period, source, and denominator are stated.
Series remain identifiable without colour alone.
Labels are readable at the final size.
A short alternative and useful description are available.
Exact values are available where needed.
Missing data and material uncertainty are explained.
The published format has been checked.

This is a practical authoring checklist, not a complete WCAG conformance assessment. The example and editorial recommendations are original; the linked W3C resources explain the accessibility principles.

Suggest an edit