# Give data tables headers that survive nonvisual reading

Canonical: https://githtml.com/guides/accessible-data-table-headers
Published: 2026-09-26
Publisher: WaveTech LLC / gitHtml

Use a real table for genuinely tabular data, identify its subject with a caption, and mark row and column headers appropriately. Keep units and caveats visible. If the header structure becomes difficult to explain, split the table into simpler comparisons instead of relying on merged cells and visual position alone.

## Decide whether the content is tabular

A table is appropriate when the meaning of a value depends on its row and column. Monthly measurements by service are a clear example. A set of unrelated prose descriptions is not automatically a table just because a grid makes it look tidy. Choose the structure that helps readers understand relationships rather than the structure that resembles a spreadsheet export.

Write the question the table answers and identify which fields are necessary. Unused columns increase navigation work, particularly on a phone or with a screen reader. Remove redundant data or move it to a separate reference artifact. Keep any caveat that changes interpretation in the main table or immediately beside it.

## Make associations explicit

Use header cells for labels and data cells for values. In a simple table, scope attributes can identify row and column headers. Include a caption that describes the dataset rather than a generic label such as Table one. Units belong in the relevant labels or values so a reader does not need to infer them from visual formatting.

Complicated merged headers require more careful association and testing. Before adding that complexity, consider whether several smaller tables would communicate the comparison better. Do not convert header cells into ordinary styled cells merely to achieve a particular appearance. Likewise, color alone should not distinguish totals, warnings, or missing values.

## Test a value in context

Choose a value in the middle and one near the final column. Verify that a reader can determine the subject, measure, unit, and limitation for each. On a narrow screen, a local scrolling wrapper can preserve the table while keeping prose stable. Check keyboard and assistive navigation as well as visual scrolling.

1. Use a caption that names the subject and period where relevant.
2. Check row and column header associations.
3. Write missing-data states explicitly instead of leaving ambiguous blanks.
4. Provide the main conclusion in prose outside the table.
5. Review the actual rendered artifact with representative data, not only an empty template.

````html
<table>
<caption>Export size by format, in kilobytes</caption>
<tr><th scope="col">Format</th><th scope="col">Size</th></tr>
<tr><th scope="row">Text-only HTML</th><td>42</td></tr>
</table>
````

## Sources and further reading

- [W3C WAI: tables with one header](https://www.w3.org/WAI/tutorials/tables/one-header/)

## Related guides

- [Build a heading outline that makes a long report navigable](https://githtml.com/guides/heading-hierarchy-readable-html)
- [Use landmarks to separate navigation from the report body](https://githtml.com/guides/document-landmarks-for-html-reading)
- [Write screenshot alternatives that explain the useful information](https://githtml.com/guides/alt-text-for-document-screenshots)
- [Describe architecture diagrams as relationships, not shapes](https://githtml.com/guides/text-descriptions-for-architecture-diagrams)

Editorial approach: https://githtml.com/guides/about