Building a WCAG 2.1 AA Dashboard That 50K Users Actually Rely On

Analytics dashboards are where accessibility usually goes to die. Dense charts, color-coded everything, live-updating numbers — all of it hostile to screen readers and low-vision users. On a real-time energy dashboard serving 50K+ monthly users, WCAG 2.1 AA wasn't optional. Here's what actually moved the needle.

Color is not information

The fastest way to fail WCAG is to encode meaning in color alone. A red/green status that looks identical to a colorblind user is a defect, not a style choice.

• Pair every color with a shape, icon, or label.
• Verify contrast: 4.5:1 for text, 3:1 for large text and UI components.
• Never rely on hue alone in a chart legend — add patterns or direct labels.

Charts need a text alternative

A canvas or SVG chart is invisible to a screen reader. The fix isn't to describe every pixel — it's to expose the underlying data as an accessible table.

<figure role="group" aria-labelledby="chart-title">
  <h3 id="chart-title">Energy usage, last 24h</h3>
  <Chart data={data} aria-hidden="true" />
  <VisuallyHidden>
    <table>{/* same data, tabular */}</table>
  </VisuallyHidden>
</figure>

Live regions, used sparingly

Real-time updates are a trap: announce every tick and you flood the screen reader. Use aria-live="polite" only on a summary element that changes meaningfully, not on every streaming value.

Keyboard is the real test

If you can't operate the entire dashboard with a keyboard — filters, tooltips, drill-downs — it isn't done. Tab order, visible focus rings, and Esc to close overlays caught more real bugs than any automated scan.

The takeaway

Automated tools (axe, Lighthouse) catch maybe 30% of issues. The other 70% is keyboard testing and actually thinking about how a non-visual user builds a mental model of your data. Budget for it from day one — retrofitting accessibility costs far more.