For each complex data table that has a summary, is it relevant?
A blind user who arrives at a complex data table — multiple groups of headers, merged cells, intersecting axes — cannot scan it visually to grasp its structure. They navigate cell by cell, without any global reference point. The summary is what tells them, before they start: "here's how this table is organized, here's how to read it". If this summary is vague or misleading, it makes things worse.
Criterion 5.2 does not verify whether a summary exists — that's the role of criterion 5.1. It verifies that the summary present is relevant: that it actually describes the table's structure or explains how to navigate it. A summary that repeats the table's title, or merely says "statistical data table", adds nothing.
A relevant summary answers these questions: how are the headers organized? Should you read by row or column to find a value? Are there groups of columns? This is precisely what W3C technique H73 describes: a brief explanation of how the data is organized or how to navigate the table.
If the table also has a <caption>, the summary must not duplicate it. The <caption> identifies the table; the summary explains its structure. These are two distinct roles.
Un test to assess the relevance of the table summary
Relevance of summary of complex table
- Identify all complex data tables that have a summary (those identified in test 5.1.1).
- For each summary found, verify that it fulfills at least one of these conditions:
- It describes the table's structure (organization of headers, groups of rows or columns);
- It explains how to navigate the table to find a specific value.
- Verify that the summary does not merely repeat the content of the
<caption>. - If all summaries meet these conditions, the test is validated. If a single summary is missing meaning or misleading, the test is not validated.
Examples
❌ Non-compliant : Summary that duplicates the title without providing structural information
<table summary="Bus schedules for the urban network">
<caption>Bus schedules for the urban network</caption>
<thead>
<tr>
<th scope="col">Line</th>
<th scope="col">Monday-Friday</th>
<th scope="col">Saturday</th>
<th scope="col">Sunday</th>
</tr>
</thead>
<tbody>
<tr>
<th scope="row">Line A</th>
<td>6:00 AM - 10:00 PM</td>
<td>8:00 AM - 8:00 PM</td>
<td>9:00 AM - 6:00 PM</td>
</tr>
</tbody>
</table>The summary repeats word for word the content of the <caption>. A screen reader reads both in succession: the user hears the same information twice without learning anything about the table's structure. W3C technique H73 explicitly specifies that the summary must not duplicate the title.
✅ Compliant : Summary that explains how to navigate a complex schedule table
<table aria-describedby="schedule-summary">
<caption>Line 12 Schedule — Center Direction</caption>
<thead>
<tr>
<th scope="col">North Station</th>
<th scope="col">Republic Square</th>
<th scope="col">City Hall</th>
<th scope="col">Chatelet</th>
</tr>
</thead>
<tbody>
<tr>
<td>07:00</td>
<td>07:08</td>
<td>07:15</td>
<td>07:22</td>
</tr>
<tr>
<td>07:30</td>
<td>07:38</td>
<td>07:45</td>
<td>07:52</td>
</tr>
</tbody>
</table>
<p id="schedule-summary">Columns represent the stations served, from left to right in the order of the route. Rows represent successive departures. Find your station in the column header, then read down to find the departure time.</p>The summary explains the reading logic: how columns and rows are organized, and how to find the desired information. The screen reader user understands the structure before navigating cell by cell. Implementation via aria-describedby is valid in HTML5, unlike the summary attribute declared obsolete.
Tips and pitfalls
⚠️ Summary identical to caption
This is the most frequent error in audits. The summary says "Table of 2024 financial results" while the <caption> says exactly the same thing. The screen reader user hears the information twice, without learning anything more. The summary answers "how is this structured?", not "what is this table?".
⚠️ Vague or generic summary
A summary like "This table presents statistical data" is worthless. It explains neither the structure, nor how to read intersections, nor the organization of headers. For a summary to be relevant, it must be specific: which dimensions does the table cross, how to locate a specific value.
⚠️ Criterion not applicable if no summary is present
Criterion 5.2 applies only if the complex table already has a summary. If it does not, criterion 5.1 is concerned. In an audit, a complex table without a summary fails 5.1 but makes 5.2 non-applicable. These are two distinct defects that should not be confused.
💡 The summary attribute is obsolete in HTML5 — but its content is still audited
W3C technique H73 historically relies on the summary attribute of <table>, declared obsolete since HTML5. RGAA auditors also check valid alternatives: text adjacent to the table linked via aria-describedby, or a <details> block placed before the table. What matters for criterion 5.2 is the content of the summary, regardless of the implementation technique.
⚠️ A summary that is too long can harm the experience
A relevant summary is not an exhaustive summary. If it lists all the values in the table or describes each cell, it becomes an obstacle to navigation. The objective is a brief explanation of the structure and navigation — two to four sentences are usually sufficient even for the most complex tables.
Frequently asked questions
How do you evaluate whether a table summary is relevant according to RGAA?
Ask yourself this question: by reading only the summary, would a blind user know how to look for a specific value in this table? If the answer is no, the summary fails criterion 5.2. If it merely repeats the title or indicates that the table contains data, it is not relevant.
How do you differentiate between using aria-describedby and summary to summarize an RGAA table?
Yes, it's actually the recommended method in HTML5. Add descriptive text in an identified element (for example a <p id="table-summary">), then associate it with the table via aria-describedby="table-summary". The relevance of the content remains subject to criterion 5.2, regardless of the technique chosen.
In which cases does RGAA criterion 5.2 apply to layout tables?
It does not. Criteria 5.1 and 5.2 concern only complex data tables. Layout tables are handled by RGAA criteria 5.7 and 5.8. A layout table should not have a summary — that would be false information provided to screen reader users.
How do you effectively audit RGAA criterion 5.2 on summary relevance?
Open the code inspector and search for summary attributes on <table> tags, as well as aria-describedby associations pointing to descriptive text. For each summary found on a complex table, read its content and verify that it explains the structure or navigation. Then compare with the <caption> if it exists — if both texts are identical or nearly identical, the criterion fails.
What should the summary of a table without a <caption> contain to satisfy criterion 5.2?
No. These two roles remain distinct even without a <caption>. The summary should focus on structure and navigation. The absence of a title is a problem addressed by criterion 5.4, not 5.2. Mixing both pieces of information in the summary harms clarity and makes auditing each criterion harder.