For each layout table, does the linearized content remain understandable?
A screen reader reads a table cell by cell, from left to right and top to bottom. If you have used a <table> to visually lay out blocks of content, this linear reading can produce complete nonsense: sentences cut off, information in the wrong order, content that makes no sense outside the visual context.
The rule is twofold. First, the order of cells must remain logical when read in sequence. If removing CSS makes the page incomprehensible, the layout table fails the criterion. Second, the <table> element must carry role="presentation" to signal to assistive technologies that this table is purely graphical and not semantic.
Without role="presentation", a screen reader like NVDA or JAWS announces "table with 3 columns and 4 rows," then offers table navigation shortcuts. The user looks for headers, tries to understand relationships between columns — only to discover it was just a simple layout block. It is a waste of time and a source of real confusion.
Un test to ensure that layout tables are correctly linearized
Layout table with role="presentation" and coherent order
- Identify all
<table>elements used for layout (not for tabular data). - For each one, verify that
role="presentation"is present on the<table>tag. - Read the content of the cells in DOM order (first row left to right, then second row, etc.). This linearized content must remain understandable and coherent.
- If both conditions are met for all layout tables, the test is validated. If either is missing, the test fails.
Examples
❌ Non-compliant : Layout table without role="presentation" and incoherent order
<table>
<tr>
<td><img src="logo.gif" alt="XYZ mountaineering"></td>
<td rowspan="2" valign="bottom">at the summit !</td>
</tr>
<tr>
<td>XYZ takes you</td>
</tr>
</table>In linear reading, a screen reader reads: "XYZ mountaineering," then "at the summit !," then "XYZ takes you." The sentence "XYZ takes you to the summit" is fragmented and incomprehensible in this order. Furthermore, the absence of role="presentation" causes the screen reader to announce a table with 2 columns and 2 rows, and to offer unnecessary table navigation shortcuts.
✅ Compliant : Layout table with role="presentation" and coherent reading order
<table role="presentation">
<tr>
<td>
<img src="logo.gif" alt="XYZ mountaineering">
<p>XYZ takes you to the summit !</p>
</td>
<td>
<p>Professional equipment since 1987.</p>
</td>
</tr>
</table>With role="presentation", the screen reader ignores the table structure and reads the content directly. The DOM order matches the expected reading order. If CSS is removed and cells are read in sequence, the sentence remains logical. The user loses no information.
Tips and pitfalls
⚠️ role="presentation" does not neutralize incoherent reading order
A common audit error: add role="presentation" and consider the criterion validated. This is only one of two conditions. If cells are read in the wrong order (because of rowspan, colspan, or a visually complex structure), the content remains incomprehensible to a screen reader user, regardless of the ARIA role.
💡 Linearization test: read the source in order
To test quickly, open the inspector and read the text contained in each <td> in the order it appears in the DOM. If this reading produces coherent text, the criterion is on the right track. You can also disable CSS in DevTools and read the resulting page.
⚠️ Nested layout tables inherit role="presentation"
According to the ARIA specification, role="presentation" on a <table> removes the semantics of the element but not of its descendants. A nested <table> within it must also explicitly carry role="presentation" if it is used for layout.
⚠️ Layout tables must not contain semantic table elements
A table declared with role="presentation" must not contain <th>, <caption>, scope, or headers. If these elements are present, the table is treated as a data table — and the rules of criterion 5.1 apply instead. In practice, a forgotten <th> in a layout table is a frequent bug that contradicts the role="presentation" declaration.
Frequently asked questions
How do you distinguish a layout table from a data table ?
A data table presents relationships between information along two axes (rows and columns have meaning). A layout table is used only to visually position blocks of content. The practical test: if you can replace the <table> with <div> and flex/grid CSS without losing information, it is a layout table. If it contains <th> or a <caption>, it is a data table.
How do you verify RGAA compliance for tables generated by a CMS ?
Yes. The origin of the code (CMS, WYSIWYG editor, third-party component) does not change the obligation to comply. A <table> injected by a content editor without role="presentation" fails criterion 5.3 exactly as a table written by hand. Report the issue to the tool editor or correct the HTML output.
When should role="presentation" be used on a layout table to comply with RGAA ?
No. Visual order and DOM order can diverge, particularly with rowspan and colspan. RGAA 4.1.2 (criterion 5.3.1) requires that the order of access to cells in the DOM be consistent with the content, not just that the visual rendering be correct. This is why technique F49 of the WCAG specifically targets layouts with rowspan that break the logical sequence.
Why are summary attributes and caption forbidden in a layout table under RGAA ?
No, it is the opposite: a layout table must not have a <caption> or summary. These elements signal that the table contains structured data. Their presence on a layout table is an error that falls under criterion 5.4 (layout table must not have elements or attributes specific to data tables).
How do you test RGAA 5.3 on layout tables with a screen reader ?
With NVDA, navigate to the table: if it announces "table" with a number of columns and rows, role="presentation" is absent or ignored. With navigation mode (press T to move from table to table), a correctly configured layout table should not appear in the list. You can also use Chrome DevTools Accessibility: the accessibility tree of the <table> should display role: none.