Can every reader understand the decision behind your chart?

Start with the reader’s question and the data definition

Before choosing bars, lines or a pie, write the sentence the reader should be able to answer. A service company might ask, “Which months had the most completed bookings?” An online shop might ask, “Did the share of orders delivered on time change?” Those are different questions and need different measures. Define a completed booking, the time zone, the period and the population included before a designer draws a shape. If the source has missing records or estimates, say so beside the chart. A graphic can look precise while the underlying measure is ambiguous. The accessible version must carry the same qualifications, not just a bare list of numbers. This preparation is also useful for readers who can see the graphic but need to judge whether the business conclusion follows from the evidence.

Separate observation from illustration. If you use sample values to teach a choice, label them hypothetical and do not let them appear in a live performance chart. If the chart reports real customer or sales information, show the source, period, unit and last verified update in ordinary text. Do not infer a causal story from a movement alone. A fall in enquiries might reflect a changed form, a holiday, missing tracking or a real shift in demand. The description can identify the movement and its scale without claiming the cause. When a small firm publishes a chart externally, this discipline protects both accessibility and truthfulness.

Give the chart a short name and a full equivalent

The W3C Web Accessibility Initiative treats charts and graphs as complex images. Its guidance calls for a short alternative that identifies the chart, plus a longer description that communicates essential values, relationships and trends. “Sales chart” is too vague; dumping every value into an alt attribute is difficult to navigate. A useful short alternative could identify the measure and period, then point to an adjacent text summary and data table. The summary answers the original question in words. The table preserves exact values for a reader who needs to compare cells or reuse data. W3C’s example places structured long description material, including headings and a table, in page content rather than forcing it into a single uninterrupted string.

Imagine a chart with four bars showing completed service appointments by quarter. The visual can rapidly show that the third quarter is highest, but a reader needs to know the count, not merely that one bar is taller. A short label might say that quarterly completed appointments are compared and that the full values follow. The text below can identify the high and low quarter, while a four-row table gives every count and the same unit. If only percentages are drawn, explain their denominator: percentage of all requests, of accepted bookings or of appointments scheduled in that quarter. Each denominator answers a different business question. The equivalent must match what the picture actually encodes.

The equivalent also needs to distinguish a true zero from an unknown value. If a day has no bookings, zero can be a meaningful observation; if the booking feed failed, displaying zero would falsely imply no demand. Mark missing data in words and in the table, and explain any threshold used to hide a small category. For a comparison across time, state whether earlier values were revised and whether all periods use the same definition. Readers who rely on the text should receive those cautions at the same point as readers looking at a visual note. This prevents a polished graphic from turning a data-quality problem into a confident business recommendation.

Keep the exact data in a navigable table

A table is more than a screenshot of a spreadsheet. Give it a caption that names the measure and period, column and row headings that explain each dimension, and units in the heading or caption. If figures are rounded in the chart, clarify whether the table contains raw or rounded values. Where a category was suppressed for privacy or too few observations, mark that omission explicitly instead of silently leaving a blank. W3C’s non-text-content explanation notes that, where possible and practical, actual data can be given in a table. The table should be part of the page or a clearly named adjacent destination. A download alone may help analysts, but it cannot replace an immediately understandable answer for a customer deciding what the chart means.

Check the table with a keyboard and a screen reader. Can the reader find the caption, understand the heading associated with a number and move between cells without losing context? On a narrow phone, a wide table may scroll; make sure the first column remains understandable and that scrolling does not hide the control. Avoid merging cells merely for visual elegance if it makes headings ambiguous. If the chart updates when a customer changes filters, update the summary and table from the same data selection. A stale table beside a fresh chart creates two conflicting answers and is not an accessible equivalent. If a CSV download is offered, keep its column names and units aligned with the visible table, and state whether hidden or suppressed values are omitted from the file. A download with different definitions is a second dataset, not an accessibility substitute.

Make visual comparisons readable too

Accessible text does not excuse a confusing visual design. Put the unit next to the scale, start a bar comparison from a common zero baseline when bar lengths represent magnitude, and avoid a truncated axis that exaggerates a small difference. A line chart can use a different baseline if the purpose is to show change, but its range must be clear and the accompanying words must not magnify the result. Label series directly where practical. W3C’s use-of-color guidance says color must not be the only visual way to convey information. Use a combination of names, shapes, patterns or direct labels so two series remain identifiable in greyscale and for readers with color vision differences.

Do not treat every visual as needing the same solution. A simple two-value comparison may be clearer as a sentence or a small table than as a chart. A chart is useful when shape or pattern makes a relationship easier to notice, but it must not require hovering to reveal every exact value. On touch devices there is no reliable hover, and keyboard users may not reach pointer-only tooltips. If tooltips add detail, make that detail available through focus and the surrounding table. Test zoom and narrow layouts so axes and labels do not clip. When a visualization is interactive, record the selected filter and units in visible text so readers know which view they are evaluating.

Work through a booking example without invented results

Suppose a clinic wants to show customers the distribution of available appointment slots across the coming week. Before publishing, the editor defines whether a slot means an open time, a clinician who can accept a booking, or actual remaining capacity after reservations. The chart might group by day, but the table should give each day and exact number still available at the stated update time. A sentence should explain the practical decision: which days currently have more choices, and that availability can change. If capacity is updated often, the chart, summary and table should all come from the same snapshot. This is a hypothetical design example, not an observed clinic dataset or a promise that any particular appointment is free.

A reviewer then checks three paths. First, look at the chart and state the takeaway without reading the table. Second, hide the image or use a screen reader and answer the same question through the short alternative, summary and table. Third, use a phone at high zoom and try the interactive controls. If the answers differ, fix the chart data or text rather than choosing one audience’s version as authoritative. Include a check that all displayed values reconcile with the source extract. This catches an editorial error that accessibility testing alone would miss.

Set a maintenance rule before release

Assign one owner to the measure, one source of truth and an update trigger. A chart that once accurately represented a month can become misleading when the period label stays fixed but its data changes. For scheduled refreshes, test that the summary, table, caption and visual all change together. When a source is unavailable, show a dated last-verified state or a clear unavailability message rather than quietly displaying new-looking artwork with old numbers. If the chart supports a customer decision, provide the route to the current detailed information as well. This avoids treating a historical trend as a live availability or price statement.

The publishing decision is straightforward: use a chart only when it adds understanding, and release it when the same conclusion can be reached through the equivalent text and values. Keep the short alternative concise, the long explanation useful, the table exact and the source qualifications visible. Record what was tested, including keyboard, screen reader, zoom, color-independent series identification and data reconciliation. A chart that passes those checks can serve both a fast visual scan and a careful audit of the underlying business claim.