Write Captions That Identify a Table and Summaries That Explain It

Give every public data table a short, standalone caption that identifies the dataset: subject, measure, population or place, and period. Add a separate summary only when the table’s structure needs explaining, which means nested header groups, more than one header row or column, scaled units or abbreviations, or blank, suppressed and estimated values. The caption identifies; the summary orients. Neither replaces <th> header cells with correct scope values, which is what actually gives each data cell its context.

Type the measure, grouping variables and period; the caption, the summary verdict and the markup note update beside the fields.

When a Caption Is Enough and When a Summary Is Needed

A caption is a short identifier for a table’s subject and purpose. It tells readers what the table covers so they can decide whether to inspect it.

A summary explains how a large, unusual or structurally complex table is organized. It prepares readers to navigate the cells.

The W3C Tables Tutorial describes captions as useful in most situations and summaries as orientation or navigation aids for complex tables.

Reader need	Use	It should provide
Identify the table	Caption	Subject, measure, coverage, period
Understand its structure	Summary	Rows, columns, groups, units, reading order
Understand both	Caption and summary	Identification, then nonduplicative orientation
Understand each cell	Semantic markup	Programmatic header-to-cell relationships

A label such as “Results” or “Table 1” gives no context when a screen reader announces it from a table list. A separate summary, on the other hand, is unnecessary when a table has one obvious header row and a conventional structure.

When both are present, the summary must add information rather than restate the caption:

• Caption: Employment by industry and age group, 2025.
• Summary: Rows list industries; columns group workers into four age ranges and report counts in thousands.

Captions and summaries cannot repair missing headers or wrong cell associations. Fix the structure first.

Caption Formula: Subject, Measure, Population, Period

Build the caption from these parts and drop any that are not needed to distinguish the table:

Subject + measure + relevant population or place + period

No word or character limit is supported by the guidance cited here. The caption should be short enough to scan and complete enough to make sense with no surrounding prose.

• Weak: Results
• Improved: Median apartment rent by neighborhood and bedroom count, 2024.

The improved version names the measure, the grouping variables and the period. A monitoring dataset might need a place as well:

Monthly bicycle counts by monitoring station, Portland, January–December 2025.

Another table needs less. “Population by district, 2025” is already distinctive.

Do not turn the caption into a container for all metadata. Source, methodology, licence, update cadence, limitations and missing-value rules belong in visible documentation near the table or in a data dictionary. Keep a detail in the caption only when readers need it to identify or distinguish the dataset.

Avoid captions that depend on position or surrounding text: “Data below”, “The following table”, “Results”, “Table 1”, “Breakdown by category”. If numbering is useful, combine it with a descriptive title: “Table 1. Median apartment rent by neighborhood and bedroom count, 2024.”

Summary Formula: Purpose, Rows, Columns, Groups, Units, Missing Values

Write a summary in this order and include only the parts readers need before navigating:

1. Purpose: the lookup or comparison the table supports.
2. Rows: what each row represents.
3. Columns: what each column represents.
4. Groups: whether rows or columns are nested under higher-level headers.
5. Units and abbreviations: counts, percentages, rates, currency, scaled units.
6. Missing-value rules: what blanks, symbols and status codes mean.
7. Optional takeaway: one directly observable pattern, if any.

Structural orientation is not interpretation. “Rows list monitoring stations, and columns report one month each” explains organization. “Values are highest in May and lowest in January” states an observable pattern. “The campaign caused the May increase” is a causal claim the displayed values cannot support, and it does not belong in a summary.

Use field names, not visual directions. Replace “the column on the right” with “2025 employment rate”, and “the sections at the top” with “the 2024 and 2025 column groups”. Field names survive resizing, reformatting and nonvisual reading; “right” and “top” do not.

Define Each Missing-Data State Separately

These states mean different things and are not interchangeable:

State	Meaning
Blank	No observation was submitted
Zero	A reported quantity of none
Unavailable	A value could not be provided
Not applicable	The field does not apply
Estimated	Produced by an estimation method
Suppressed	Intentionally withheld

Do not replace a blank with zero or “N/A” to fill the cell. State the rule the dataset actually follows, in a visible note near the table.

Worked Examples: Caption Only, Caption Plus Summary, Split the Table

These examples are synthetic and illustrate writing and structure, not measured accessibility outcomes.

Simple Time Series Needs Only a Caption

Caption: Monthly library visits, East Branch, January–December 2025.

Summary: Not needed.

A table with one Month column and one Visits column has an obvious reading order. A sentence explaining that rows are months adds nothing.

Geographic Comparison Needs a Caption and a Summary

Caption: Population and annual change by district, 2024–2025.

Summary: Rows identify districts. Columns are grouped by year, with population fields for 2024 and 2025 followed by a 2025 annual-change field expressed as a percentage.

If observations are incomplete or protected, add a visible note:

Missing-data note: A blank means no observation was submitted; zero means a reported count of none; “S” means the value was suppressed.

Multi-Level Dataset: Simplify Before You Describe

Suppose one table compares public transport ridership by mode, fare type, quarter and year. Keeping every dimension in one grid requires merged year headings, quarter subheadings and multiple row groups.

Split it instead:

1. Quarterly bus ridership by fare type, 2025
2. Quarterly rail ridership by fare type, 2025

Each table then has a direct caption, fewer header levels and simpler cell associations. WebAIM’s data-table guidance recommends flattening tables where possible because heavily marked-up complex tables remain hard to understand even when the markup is correct.

If the combined table must remain:

Caption: Quarterly public transport ridership by mode and fare type, 2024–2025.

Summary: Rows group fare types under bus and rail services. Columns are grouped into 2024 and 2025, with four quarterly count fields under each year. Values are passenger journeys in thousands.

Markup That Carries the Caption and Cell Relationships

A caption and summary only work on top of real table markup. Accessible tables distinguish header cells from data cells and establish the relationship between them.

For an ordinary table: put a <caption> element directly inside <table>, before <thead>. Mark column headers as <th scope="col"> inside <thead>, and the first cell of each body row as <th scope="row"> when that cell labels the row. Everything else is <td>. Screen readers use these associations to announce the relevant header as the reader moves cell by cell.

For grouped structures, scope="colgroup" and scope="rowgroup" identify headers that apply to a group of columns or rows. Relationships that cannot be expressed horizontally or vertically need unique id values on the headers and matching headers values on each data cell. That adds markup and opportunities for error, so simplify or split the table before reaching for it.

<thead>, <tbody> and <tfoot> organize sections and help styling. They do not on their own establish which header applies to which cell.

Associate a Visible Summary Without the Obsolete summary Attribute

Explanatory context should stay visible. A short summary can sit inside the <caption>; a longer one goes in nearby text.

When nearby text needs a programmatic link to the table, give the paragraph a unique id and reference it from the table with aria-describedby. For the district example: a paragraph with id="district-summary" containing the summary text, then <table aria-describedby="district-summary"> with its own <caption> inside. The W3C caption and summary guidance documents both the visible caption-based summary and the aria-describedby association.

Do not rely on the HTML summary attribute on <table>. It is obsolete and invisible to sighted readers. Current MDN table accessibility guidance favors visible captions with correct header markup.

A <figure> with <figcaption> can group a table with its explanatory text, but a figure caption alone may not identify the table in screen-reader table-navigation mode. Adding aria-labelledby or aria-describedby strengthens the link, though some implementations then announce the text more than once.

Pre-Publication Check for Writing and Structure

Review the editorial content and the published implementation separately.

Editorial check

• The caption names the subject and measure, plus population, place and period where they distinguish the table.
• Units and abbreviations are defined.
• The summary uses field names, not visual directions.
• Source, methodology, update information and limitations are available nearby.
• Blank, zero, unavailable, not-applicable, estimated and suppressed states are defined separately.

Structural check

• Headers are real <th> cells, not styled <td> cells.
• scope values are correct for ordinary or grouped relationships.
• id and headers are reserved for relationships scope cannot express.
• Unnecessary merged cells and header levels are removed.
• <caption> is directly inside <table>.
• Nearby summary text is visible and associated with aria-describedby.
• Each data cell keeps its header context during cell-by-cell navigation.

Inspect the published page rather than assuming the spreadsheet’s structure survived conversion; table semantics are routinely lost between formats. Automated checkers are a first pass, not proof. Section508.gov’s table guidance recommends clear captions, meaningful headers, simple structures and an accessibility check, with manual markup inspection and screen-reader testing on top.

Static-table guidance does not say how captions or summaries should change after sorting, filtering, searching or pagination. Evaluate those interactive states separately against the actual implementation.

TablePage publishes spreadsheets as public, interactive data pages, but the publisher still has to inspect the captions, descriptions, headers and associations on the final page. Because the page is public, test with synthetic or appropriately public data and never publish sensitive rows.

Frequently Asked Questions

Does a native HTML data table need alt text?

No. A native HTML table is not an image. It needs a descriptive caption plus semantic header and data cells with correct associations. A table published as an image does need a text alternative, but a native table is far more useful because readers can navigate and select its cells.

Should I use the HTML table summary attribute?

No. The summary attribute is obsolete and should not be the primary description method. Use a visible caption for identification and, for a complex table, visible summary text in the caption or nearby, associated with aria-describedby when needed. Simplify the table before writing a long structural explanation.