Each layout table must not use elements specific to data tables. Is this rule followed?
A screen reader reads a <th> and announces « header ». It reads a <caption> and announces a table title. When these elements appear in a layout table — a <table> used solely to position content visually — the screen reader announces a semantic structure that doesn't exist. The user is looking for data, row/column relationships: there are none.
This criterion requires layout tables to remain semantically neutral. Concretely: no summary attribute on the <table>, no <caption>, <thead>, <th>, <tfoot> elements, no elements with role="rowheader" or role="columnheader". On <td> cells: no scope, headers, or axis attributes.
A clean layout table contains only <tr> and <td>. That's it. Criterion 5.3 additionally requires the role="presentation" attribute on the <table> itself — the two criteria go hand in hand to fully neutralize table semantics.
Un test to ensure that no data tag is misused for formatting
Absence of data tags in layout table
- Identify all layout tables on the page (tables used only for visual page layout, not for data).
- For each
<table>layout, verify the absence of the following elements and attributes:summaryattribute on<table>- Child elements
<caption>,<thead>,<tfoot>,<th> - Elements with
role="rowheader"orrole="columnheader"
- For each
<td>inside this table, verify the absence ofscope,headers, andaxisattributes. - If all layout tables meet these conditions, the test is passed. As soon as a single forbidden element is present, the test fails.
Examples
❌ Non-compliant : Layout table with data tags
<table summary="Two-column layout">
<caption>Main content and sidebar</caption>
<thead>
<tr>
<th scope="col">Content</th>
<th scope="col">Navigation</th>
</tr>
</thead>
<tbody>
<tr>
<td>Main article...</td>
<td>Navigation links...</td>
</tr>
</tbody>
</table>This table is used only to position two blocks side by side. Yet it contains a summary, a <caption>, a <thead>, and <th> elements with scope. A screen reader like NVDA will announce « table, Main content and sidebar, column 1 Content, column 2 Navigation ». The user expects tabular data and navigates between cells with arrow keys — for nothing: it's just page layout.
✅ Compliant : Semantically neutral layout table
<table role="presentation">
<tbody>
<tr>
<td>Main article...</td>
<td>Navigation links...</td>
</tr>
</tbody>
</table>The table contains only <tr> and <td>, with no data tags. The role="presentation" attribute (criterion 5.3) neutralizes residual semantics. The screen reader ignores the structure and reads the cell content in sequence, like ordinary text.
Tips and pitfalls
⚠️ The « visual » <th> lingering in a layout
This is the most common audit error. A developer uses <th> to make text bold without CSS, in a layout table. Visually, it looks like a section heading. To the screen reader, it's a table header announcing non-existent columns. Use <strong> or CSS instead.
⚠️ summary inherited from an old template
The summary attribute on <table> was common before HTML5 to describe data tables. It still lingers in old templates, including on layout tables. It's invalid in HTML5 and forbidden here. Remove it systematically from layout tables.
⚠️ role="columnheader" in a nested component
A JavaScript widget (calendar, booking grid) may inject elements with role="columnheader" inside a parent layout <table>. The criterion applies to the whole: if such a role is present in the table, the test fails, even if it's a third-party component. Isolate widgets in <div> rather than layout <table>.
💡 5.3 and 5.8 are complementary, not redundant
Criterion 5.3 requires role="presentation" on the <table> to neutralize semantics. Criterion 5.8 forbids data tags inside. Both are necessary: role="presentation" without removing <th> leaves semantic elements active in some screen readers.
⚠️ A table can change nature depending on context
A table displaying prices is a data table (criteria 5.1 to 5.7). The same table styled differently for responsive layout doesn't become a layout table for that. The nature of a table depends on content, not CSS. Don't transform a data table into a layout table to escape header constraints.
Frequently asked questions
How do I distinguish a layout table from a data table?
Ask yourself: if you remove the table and read the content in linear sequence, does the information still make sense? If yes, it's probably a layout table. If relationships between rows and columns carry information (pricing, schedules, comparisons), it's a data table. When in doubt, prefer the data table — it's more restrictive but more robust.
How do I efficiently audit RGAA criterion 5.8 on layout tables?
In DevTools, select all <table> elements on the page and look for summary attributes, <caption>, <thead>, <tfoot>, <th> children, and scope/headers/axis attributes on <td>. From the command line, document.querySelectorAll('table th, table caption, table thead, table tfoot') immediately returns suspect tables. Then identify which ones are layout tables.
What effect does role="presentation" have on a <th> in an RGAA layout table?
None. Criterion 5.8.1 forbids the presence of <th> in a layout table, without exception. Replacing <th> with <td> is the only compliant solution. Neutralizing a <th> with role="presentation" is not part of RGAA methodology and remains a risk zone with some screen readers.
How do I fix layout tables with <th> generated by a CMS or WYSIWYG?
This is a frequent problem with rich editors. The fix must happen at the source: configure the CMS to not generate <th> in layout tables, or add server-side transformation. Manually fixing the generated HTML is not sustainable long-term.
Why are CSS display: table tables affected by RGAA criterion 5.8?
They aren't. A <div> with display: table in CSS is not an HTML <table> element. Criterion 5.8 applies exclusively to <table> elements in the DOM. Page layouts via display: table or CSS Grid are outside the scope of theme 5 criteria.