Why is using an HTML <table> purely for page layout treated as an accessibility defect, and what must the markup do if a layout table is unavoidable?

## The claim a <table> makes Choosing `<table>` is not choosing a grid appearance; it is declaring "the content here is tabular data whose meaning depends on row and column relationships". Browsers pass that declaration into the accessibility tree as a `table` role, with `row` and `cell` roles beneath it. Assistive technology takes it seriously and changes behaviour accordingly. ## What a screen-reader user experiences on a layout table Three distinct costs: **Announced dimensions.** Entering the table produces something like "table with 4 columns and 9 rows". For a real dataset that is orientation. For a page header split into cells, it is a lie that makes the user brace for structure. **Table navigation mode.** Screen readers give tables their own navigation keys for moving cell by cell, row by row, and jumping to headers. On a layout table, those keys move through arbitrary pieces of a page and report positions that mean nothing. **Reading order.** Table content is read row by row across cells. When cells were chosen to place things visually — a sidebar cell next to a content cell — the linear order the user hears can interleave content that visually reads top-to-bottom in separate columns. None of this is about tidiness or about the markup being old-fashioned. It is a concrete, reproducible degradation for a real group of users, which is why interviewers treat "tables are just outdated" as a shallow answer. ## The fix, in order of preference 1. **Do not use a table.** Layout belongs to CSS; the markup should be whatever elements describe the content — sectioning elements, lists, or plain `<div>` wrappers where nothing more meaningful applies. 2. **If the table cannot be removed, neutralise it.** Put `role="presentation"` (its synonym `role="none"` behaves identically) on the `<table>` element. That removes the element's table semantics. Because `<tr>`, `<td>` and `<th>` are required owned elements of a table, the presentational role propagates down to them, so one attribute on the table is enough — the rows and cells are exposed as if their content were written inline. ```html <table role="presentation"> <tr> <td><img src="logo.png" alt="Acme"></td> <td><a href="/pricing">Pricing</a></td> </tr> </table> ``` ## What a layout table must not contain Everything that asserts data-ness has to go: - **No `<caption>`.** A caption names a table of data; a layout table is not one. - **No `<th>` and no `scope`.** Header cells assert relationships between cells. A presentational role and a header cell in the same table are a contradiction, and some tooling will surface it as an error. - **No `headers`/`id` association**, for the same reason. - **No `summary` attribute** — that attribute was removed from HTML entirely and belongs nowhere. Also do not put `role="presentation"` on a table that *does* hold data because a checker complained about missing headers. That hides the problem from the audit and from the user simultaneously; the fix is to mark the headers up properly. ## Where layout tables still live HTML email is the honest exception: many email clients still lack reliable support for modern CSS layout, so table-based layouts remain standard practice there. The discipline is the same — `role="presentation"`, no caption, no header cells — and it applies to the clients that do expose an accessibility tree. ## The mirror-image mistake The reverse defect is worth naming: taking a genuine data table and destroying its semantics from the CSS side. Overriding a table's default display in order to reflow it — a common trick for narrow viewports — makes many browsers drop the table, row and cell roles from the accessibility tree, so a properly marked-up table stops behaving like one. Whatever the reflow technique, the check is the same as for any table: look at the accessibility tree, or navigate it with a screen reader, and confirm it is still exposed as a table with the headers you wrote. ## How to answer this in an interview Lead with the mechanism — table role, announced dimensions, grid navigation, reading order — not with "it's bad practice". Then give the escape hatch and its conditions. That order shows you understand *why* the rule exists, which is the difference between reciting it and being able to apply it to a case the rule did not anticipate.