How Do You Make a Chart Usable for Everyone?

How Do You Make a Chart Usable for Everyone?

Give every series a second visual difference besides colour, make sure the marks clear a 3:1 contrast ratio, and write a text alternative that states the finding rather than describing the picture. Those three changes fix most inaccessible charts, and none of them requires a new charting library.

Dashboards are where accessibility work usually stops. Teams fix the forms, fix the navigation, fix the colour contrast on buttons, and then ship a set of line charts that are five shades of one hue with a legend that is the only key to which is which.

This walkthrough covers what the standards actually require of a chart, what the text alternative should contain, and the design decisions that make the difference before any code is written.

Why Is Colour Alone Never Enough in a Chart?

Because a meaningful share of your users cannot reliably tell your series apart by hue, and the standard treats that as a baseline failure rather than a refinement. WCAG Success Criterion 1.4.1 Use of Color, at Level A, states that "color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element."

A five line chart with a colour coded legend fails that on its face. The only way to know which line is revenue is to match its hue against the legend, and matching hues is exactly the ability the criterion says you cannot assume.

The fix is a second channel per series. Dashed and dotted line styles. Different marker shapes at data points. Direct labels at the end of each line, which is often better than a legend anyway because it removes the matching step for everybody.

The understanding document is careful about a partial defence people like to use. It allows that colours differing "not only in their hue, but that also have a significant difference in lightness" can count as a distinction, if "the difference in relative luminance between the colors leads to a contrast ratio of 3:1 or greater." So a light blue against a dark blue can be legitimate.

But it closes the loophole in the same breath. "If content relies on the user's ability to accurately perceive or differentiate a particular color an additional visual indicator will be required regardless of the contrast ratio." If the reader has to know which colour means which, no amount of contrast saves it.

What Contrast Do Chart Elements Actually Need?

Three to one against adjacent colours, for anything that carries meaning. WCAG Success Criterion 1.4.11 Non-text Contrast, at Level AA, requires that the visual presentation of user interface components and graphical objects have "a contrast ratio of at least 3:1 against adjacent color(s)."

Chart marks are graphical objects. The bars, the lines, the points, and the slices all need to clear that ratio against the plot background, and against each other where they touch. This is the requirement that kills most pastel palettes.

Gridlines and axis labels are a separate question and often over designed in the wrong direction. Gridlines do not carry the data, so they can be quiet. Axis labels are text and fall under the normal text contrast rules, which are stricter, and they are the element teams most often make too light.

Test the palette against the real background, including the card the chart sits on rather than pure white. A palette validated against white and then placed on a tinted panel can lose enough contrast to fail. Our piece on SaaS dashboard UX covers the surrounding layout decisions.

What Should the Text Alternative for a Chart Say?

The finding, then the shape, then the numbers. Not a description of the visual. Someone reading with a screen reader does not want to be told there is a line chart with five lines. They want to know what the chart shows.

The W3C's own tutorial on complex images sets out the structure. It says "a two-part text alternative is required," where "the first part is the short description to identify the image and, where appropriate, indicate the location of the long description," and the second part is a long description, described as "a textual representation of the essential information conveyed by the image."

So the short part names the chart and points onward. The long part carries the content. In our work the long description that people actually find useful opens with the conclusion, because that is what a sighted reader gets in the first second of looking at the chart.

A good long description for a trend chart says which way the line went, over what period, by how much, and where the notable turns were. A bad one lists every data point in order, which is technically complete and practically unusable.

Where Should the Long Description Live?

On the page, visible to everyone, not hidden in an attribute. The W3C tutorial names a text link adjacent to the image "that refers to a separate web page or a section of the same web page that contains the long description," describing the location within the alt attribute itself, and using the figure and figcaption elements to group the image with its description.

It also notes the ARIA described-by attribute for "linking to descriptions anywhere on the same page," with the caveat that this "works best for text-only descriptions without structural elements." That caveat matters, because a description containing a table is exactly the structural case it warns about.

Our default is a visible caption or a disclosure below the chart, because a description everyone can read is better than one only some tools surface. Plenty of sighted users cannot read a chart quickly either, and a sentence stating the finding helps all of them.

Hiding the description also makes it rot faster. Content nobody sees is content nobody notices is wrong when the data changes.

Should Every Chart Have a Data Table?

Every chart should have a way to reach the numbers, and a table is usually the simplest one. It does not have to be visible by default, but it should be one interaction away and it should be a real table with headers.

The table also solves problems the chart cannot. It gives precise values where the chart gives approximations, it can be copied into a spreadsheet, and it works when the visualisation library fails to load. That last one is more common than teams assume.

Build it as semantic markup rather than a grid of styled divs. A screen reader can navigate a properly marked up table by row and column header, which turns a wall of numbers into something explorable. Our piece on web data table design covers getting that structure right.

For a chart with thousands of points, a full table is not the answer. Offer a download instead, and let the long description carry the summary.

How Many Series Can One Chart Carry?

Four or five if they need to be told apart, and the accessibility requirement is part of why. Once you need a second visual channel per series, you run out of distinguishable channels quickly. There are only so many line styles a reader can hold in mind.

This is a case where the accessibility constraint improves the design. A chart with nine series was never readable for anyone. It looked sophisticated and communicated nothing. Splitting it into three charts of three series each is better for every reader.

When you genuinely need to show many series, show one clearly and the rest as context. A single highlighted line against a set of muted ones communicates a comparison without asking anyone to decode a nine item legend.

Direct labelling is the other lever. If each series is labelled at its end, the number you can carry rises, because the reader no longer has to match anything.

What About Tooltips and Hover Only Data?

Hover only data is invisible to touch users and to keyboard users, so any value that exists solely in a tooltip is effectively missing. Treat the tooltip as an enhancement on top of data that is already reachable.

The practical requirement is that the chart's data points are focusable and that focus reveals the same information hover does. That is more work than a hover handler and it is the difference between a chart that is explorable and one that is a picture.

Axis labels and a visible value range do a lot here too. If the reader can see the scale and the approximate value, the tooltip becomes a precision tool rather than the only route to the number.

Test it the obvious way. Put the mouse away and try to read your chart with the keyboard only, then try it on a phone. Our piece on screen reader testing covers adding the third pass.

Does Dark Mode Break Your Chart Palette?

Usually, yes. A palette tuned for contrast against a white plot area will not hold the same ratios against a dark one, and the failures are not symmetrical. Light colours that were fine on white can become glaring, and dark ones become invisible.

Chart palettes therefore need to be defined per theme rather than inverted mechanically. That is more work than it sounds, because the series need to stay distinguishable from each other as well as from the background, in both themes.

The saving grace is the second channel again. If your series are already distinguished by line style or marker shape, a theme change cannot break the distinction. Only the contrast needs revalidating, which is a measurable check rather than a judgement call.

What Would We Fix on Your Dashboard First?

Print one chart in greyscale. If you cannot tell the series apart, you have a Level A problem and you have found the highest value fix in the whole dashboard. That test takes a minute and needs no tooling.

Then check your palette against the panel background rather than white, and check your axis labels as text rather than as decoration. Those two checks catch most of the contrast failures we find.

After that, write one real finding sentence under each chart. It is the cheapest improvement available, it serves everybody, and it usually reveals that one or two of your charts do not have a finding worth stating, which is its own useful discovery.

If you want help auditing or rebuilding the data visualisation in a product, we are happy to look at it with you. You can find us at phoenix.studio.