Accessible Data Tables and Dashboards: What Government Sites Get Wrong and How to Fix It

Budgets, permit statistics, performance dashboards, health data, election results. Government publishes a great deal of information as tables and charts, and almost all of it is built for people who can see a grid at a glance.

A screen reader user meets the same table as a stream of cells with no way to tell which column a number belongs to. A chart built as a flat image says nothing at all. These are some of the most common failures we see, and they are fixable.

Why do tables and dashboards fail so often?

Because they are usually made in a hurry, by a tool, for a visual audience. A table is pasted from a spreadsheet into a page editor. A dashboard is embedded from a business-intelligence product. A chart is exported as a picture. None of those steps asks whether the structure survives.

WCAG 1.3.1 (Info and Relationships) requires that information conveyed visually is also available in the markup. For a table, the relationship between a data cell and its headers is the information.

What makes a data table accessible?

Real header cells. Column and row headings must be marked up as header cells (th), not bold text in ordinary cells. That is what lets assistive technology announce “Fiscal year 2025, Parks, Actual” as you move through the grid.

Scope, or explicit associations for complex tables. A simple table with one row of column headers and one column of row headers needs scope on its headers. Tables with merged cells or multiple header levels need more careful association, and often the better fix is to split them into several simple tables.

A caption. A short visible title attached to the table itself helps everyone find the table they want, and gives screen reader users a way to decide whether to enter it.

No layout tables. Do not use tables to position content. Use CSS.

No blank or merged-for-looks cells. Empty header cells and decorative spanning confuse both navigation and reading order. If a value is genuinely not applicable, say so in the cell.

Sensible behaviour on small screens. Content must remain usable when zoomed or viewed in a narrow window (WCAG 1.4.10 Reflow). Large tables may legitimately scroll in two directions, but the scrolling region must be reachable and operable from the keyboard.

How do I make a chart accessible?

A chart is a non-text image of data, so WCAG 1.1.1 (Non-text Content) applies. A useful approach has three parts.

1. Say what the chart shows. A short text alternative that states the point: not “bar chart” but what the reader is meant to learn from it.
2. Provide the data. A table of the underlying values next to the chart, or reachable from it, is the most robust alternative because it gives every user the same information.
3. Do not rely on colour alone. WCAG 1.4.1 (Use of Color) says colour cannot be the only way to tell series apart. Add labels, patterns or direct annotations. Lines, bars and chart elements that carry meaning also need enough contrast against their background under WCAG 1.4.11 (Non-text Contrast).

Complex charts also need a keyboard path. If hovering reveals a value, the same value must be available on focus.

What about interactive dashboards?

Dashboards are the hardest case, because they combine charts, filters, maps and tables in an embedded product that your team may not control.

Ask three questions before you publish one:

• Can it be operated by keyboard alone, including filters, drop-downs and any drill-down?
• Does it expose names, roles and values to assistive technology (WCAG 4.1.2), so a screen reader can tell a filter from a label?
• Is the underlying data available elsewhere in an accessible form?

If the answer to the first two is no, do not stop at the dashboard. Provide an equivalent: an accessible table, a downloadable data file, and a plain-language summary of the main findings. Be honest about what is and is not covered; an accessibility statement is the place to say so. Where the dashboard is supplied by a vendor, it also belongs in the conversation described in the third-party content problem, because responsibility does not transfer to the vendor.

What if the table is in a PDF or spreadsheet?

The same structure has to exist in the file. In a PDF, a table needs proper table tags with header cells, or it is read as a run of unrelated text. What a remediated PDF contains explains the tagging, and PDF/UA vs WCAG explains how the two standards relate.

In Excel, name the sheets, mark the header row, avoid merged cells, and keep one table per sheet where possible. Accessible Word, PowerPoint and Excel documents covers the checklist. The fastest reliable fix for a spreadsheet that feeds a dashboard is often to publish the clean source data file alongside it.

What changes when the table is translated?

Quite a lot, and it is where agencies get caught out.

• Headers and captions must be translated, not only the data. A table with English headers over Spanish content is a mixed-language table, and parts in another language need correct language tagging under WCAG 3.1.2. Translated documents that fail WCAG 3.1.2 covers this.
• Numbers, dates and units differ between languages and regions. Decimal separators, date order and currency formatting should follow the target audience, with the convention stated.
• Text expands and contracts. A header that fits in English may wrap or overflow in German or Vietnamese, and right-to-left languages such as Arabic reverse the column order. See Arabic and RTL accessible PDFs.
• Chart alternatives must be translated too, as must any alt text, which is a translation task in its own right: alt text in translation.

Machine translation of a table frequently scrambles cell order or loses the header relationships entirely. Screen readers and machine translation explains why.

A short plan

1. Inventory your tables, charts and dashboards. Start with the ones residents use to make decisions: fees, schedules, eligibility, safety data.
2. Check structure first: real headers, captions, no layout tables.
3. Give every chart a text alternative and a data table.
4. Test dashboards with a keyboard and a screen reader, then decide whether to fix, replace, or provide an equivalent.
5. Translate structure and content together, and verify the translated version separately.
6. Record what you checked, so you can show it. What reviewers look for in Section 508 test evidence is a good model.

Where Taika fits

We remediate data-heavy documents and pages, including table structure, chart alternatives and tagged PDFs, and we translate and verify them in the languages your residents use, so the accessible version and the translated version are the same version. We meet and exceed ISO 17100, 9001 and 27001 standards.

Have tables or dashboards to fix? Send us a few representative examples, the format each one is in (web page, PDF, spreadsheet, embedded dashboard), roughly how many you publish, and the languages you need, then request a quote. Our document accessibility service page explains how we scope this work.