Oscar Rodriguez

Accessible charts: what I check before shipping one

· accessibility, data-visualization, front-end

Most of my days are spent turning numbers into pictures: stock prices, standings, box scores. A chart is one of the fastest ways to understand data, but only if you can actually see it, read it, and reach it. For a lot of people, a typical chart fails at least one of those.

Here’s the checklist I run before any chart ships. None of it is exotic, and most of it takes minutes once it’s a habit.

1. Color is never the only signal

Roughly 1 in 12 men has some form of color vision deficiency. If the only difference between “up” and “down” is green and red, a lot of your audience sees two identical lines.

  • Pair color with a second cue: an arrow, a +/− sign, a dashed vs solid line, a direct label.
  • Label series directly on the chart instead of relying on a color legend.
  • Check the palette with a color-blindness simulator (Chrome DevTools has one under Rendering → Emulate vision deficiencies).

2. Contrast applies to marks, not just text

Text needs a 4.5:1 contrast ratio against its background, but WCAG also asks for 3:1 for the graphical parts you need to understand the content: lines, bars, and the points that carry the data. Light gray gridlines can stay subtle, but the data itself can’t.

Dark mode is where this breaks most often. A palette tuned for a white background frequently drops below 3:1 on a dark one, so I check both themes, not just the one I designed in.

3. Every chart has a text alternative

A screen reader user should get the point of the chart without the picture. I think about it in two layers:

  • The summary: one or two sentences with the takeaway. “MSFT is up 2.3% today, recovering most of Tuesday’s drop.” This is what most people want.
  • The data: a real table with the underlying numbers, either visible below the chart or behind a “Show data” toggle.

That table is the easy part if your table component is already accessible. A semantic <table> gives screen readers rows, columns, and headers for free, which is a big reason we built one table component for three products on semantic HTML.

For an SVG chart, the summary goes on the element itself:

<svg role="img" aria-labelledby="chart-title chart-desc">
  <title id="chart-title">MSFT price, today</title>
  <desc id="chart-desc">Up 2.3%, recovering most of Tuesday's drop.</desc>
  <!-- marks -->
</svg>

Writing the summary has a side benefit: if I can’t say what a chart shows in one sentence, the chart probably isn’t clear to anyone else either.

4. Interactive means keyboard-interactive

Tooltips on hover are great until you don’t have a mouse. If a chart has interaction, I check that:

  • You can tab to it and move between data points with the arrow keys.
  • Focus is visible on the active point.
  • Whatever the tooltip shows is also announced, through an aria-live region or by moving focus to a labelled element.
  • Nothing important lives only in a tooltip.

5. Motion respects the user

Live data moves. Scores tick, prices update, bars animate in. For some people that motion is distracting or genuinely makes them feel sick.

@media (prefers-reduced-motion: reduce) {
  .chart * { transition: none; animation: none; }
}

With reduced motion on, the chart should still update, just without the animation. And for live views, I’m careful about announcing updates: a screen reader reading every price tick is noise, not information.

6. It survives zoom and small screens

I zoom the page to 200% and shrink the window to phone width. Axis labels that overlap, legends that fall off the edge, and tooltips that render off-screen all show up immediately.

7. Test it with a real screen reader

Automated tools like axe catch missing labels and contrast problems, but they can’t tell you whether the chart makes sense when read aloud. Five minutes with VoiceOver or NVDA catches what the tools miss.

The short version

  1. Don’t rely on color alone.
  2. 3:1 contrast for data marks, in light and dark mode.
  3. A one-sentence summary plus a data table.
  4. Full keyboard support, nothing hidden in tooltips.
  5. Respect prefers-reduced-motion.
  6. Check at 200% zoom and phone width.
  7. Listen to it with a screen reader.

Accessibility isn’t a pass at the end of the project. With charts, just like with tables, it’s much easier to design it in than to add it later, and the result is a chart that’s clearer for everyone.

What’s on your checklist that isn’t on mine? Let me know on LinkedIn.

← All posts