A chart can look clear to the person who made it and still be difficult to use. A colour legend may be obvious to the designer but meaningless to someone who cannot distinguish the colours. A line chart may communicate a trend visually while leaving a screen-reader user with no useful way to discover the values. A tooltip may contain the most important explanation but appear only when a pointer hovers over a tiny point.
Accessible data visualisation is not a request to remove visual design. It is a requirement to give the information more than one usable route. The chart, its labels, a concise explanation, and an underlying table can work together so that people can choose the representation that suits them.
Start with the question, not the chart type
Before choosing a bar chart, line chart, scatter plot, or map, write down the question the visual should answer. Are we comparing categories? Showing a change over time? Explaining a distribution? Showing a relationship between two measurements? A chart that does not answer a clear question is difficult to label and even harder to make accessible.
That question should influence the title and the short description. “Monthly visits” is a label, not an explanation. “Visits increased after the navigation redesign, while the number of returning visitors stayed stable” gives the reader a meaningful starting point. The summary should describe the important pattern without pretending that a correlation proves a cause.
Give the chart a useful name and a textual summary
A chart needs a title that identifies the subject, a time period where relevant, and units. Axis labels should explain what each measurement represents. If the values are percentages, say whether they are percentages of all users, of completed sessions, or of another denominator. If the vertical axis starts above zero, make that choice visible rather than allowing the scale to exaggerate a small difference.
For a static chart, a short paragraph can communicate the main finding and any caveat. For a complex visual, the summary should not attempt to narrate every data point. It should help the reader understand the purpose and then offer a more detailed route to the underlying information.
Provide the data in a form people can inspect
A data table is often the simplest companion to a chart. It lets a reader inspect exact values, compare rows, copy information, and use familiar table navigation. It also makes the visual more robust when images fail to load, when a chart library is unavailable, or when someone needs the numbers for another task.
The table should have proper headers and a sensible reading order. Do not turn it into a giant unlabelled grid merely to expose every internal value. If the dataset is large, provide a useful summary and a separate download or paginated table, and explain what the export contains. The table is an alternative representation of the same data, not a dumping ground for implementation details.
Never make colour carry the whole meaning
Colour is useful for grouping and emphasis, but it should not be the only way to distinguish series or states. Add direct labels, different line styles, markers, patterns, or clear annotations. A red line and a green line are not a sufficient explanation if the legend is the only place where their meaning appears.
Check contrast between text and its background, and check that thin lines and small markers remain visible at ordinary zoom levels. Avoid relying on subtle differences between neighbouring shades. A chart may be technically colourful and still be hard to read on a low-quality display, in bright light, or when printed in grayscale.
Interactive charts need keyboard and focus design
Interactive charts introduce additional questions. Can a person reach the chart controls with a keyboard? Is the currently selected point obvious? Can the same information shown in a hover tooltip be opened by keyboard focus or an explicit button? Does the focus indicator remain visible? Can a user leave the chart without tabbing through hundreds of individual marks?
For a chart with many points, a practical design might expose a small number of keyboard controls for moving between series and points, while keeping the complete data available in a table. The interaction model should be documented and tested with assistive technology rather than assumed to work because the chart is technically built from HTML or SVG.
Live-updating charts need particular care. Announcing every incoming value can make a screen reader unusable. Instead, announce meaningful state changes, provide a pause option where appropriate, and let people inspect the current snapshot on demand. Animation should not be the only way to communicate a transition.
A practical chart structure
A useful implementation can keep the visual and its explanation together:
<figure aria-labelledby="visits-title"
aria-describedby="visits-summary">
<h2 id="visits-title">Monthly visits, January–June</h2>
<p id="visits-summary">
Visits rose in spring and levelled off in June.
Returning visitors remained broadly stable.
</p>
<!-- The chart has an accessible name and a
separate data table follows it. -->
<div role="img" aria-label="Line chart of monthly visits">
...
</div>
<figcaption>Source and measurement notes.</figcaption>
</figure>This is only a structural sketch. A real chart may need a more detailed accessible interaction model, and a complex SVG may need carefully chosen title and description elements. Do not apply role="img" blindly to an interactive chart: doing so can hide its internal controls from assistive technology. Choose semantics based on what the chart actually allows people to do.
Test the information, not just the colour palette
- Can someone understand the chart’s purpose from its title and summary?
- Are units, time ranges, scales, and data sources clear?
- Can the key information be found without relying on colour or hover?
- Can keyboard users reach and operate every meaningful control?
- Can screen-reader users discover the summary and inspect exact values?
- Does the chart remain understandable at narrow widths and high zoom?
- Do updates avoid overwhelming people with constant announcements?
These checks complement the broader interaction work described in our guide to accessible keyboard, touch, and pointer controls. The same principle applies: essential information and actions should not depend on a single input method.
Useful standards and references
The W3C’s complex images tutorial explains how to provide a long description for visuals that contain information beyond a short alternative text. The WAI tables tutorial covers table structure and relationships. WCAG’s Non-text Content guidance is also relevant when a chart communicates information that is not available elsewhere.
A good chart does not force everyone to read it in the same way. It lets a visual reader recognise a pattern, a keyboard user navigate controls, a screen-reader user understand the summary, and a detail-oriented reader inspect the values. When those routes agree, the chart becomes more trustworthy as well as more accessible.
What do you want to say about this?