Accessible Tables

The plain-language idea

Look at a spreadsheet-style table and your eyes do something automatic: they connect the value in a cell to the column header above it and the row label to its left, all in one glance. "42" becomes "42 open tickets, for the Support row."

A screen reader can't replicate that glance. It reads content in a linear order, cell by cell, and by default a cell is just its own text — "42" — with no built-in connection to any header, unless the table's markup makes that connection explicit. Heard in isolation, a sequence of bare values ("42," "Active," "March 2024") tells a screen reader user nothing about what any of them mean.

See it in a real thing: header cells versus styled cells

<!-- Looks identical, means nothing to a screen reader -->
<table>
  <tr><td><strong>Name</strong></td><td><strong>Status</strong></td></tr>
  <tr><td>Ada</td><td>Active</td></tr>
</table>

<!-- Real header cells, explicitly scoped -->
<table>
  <caption>Team member status, updated weekly</caption>
  <tr>
    <th scope="col">Name</th>
    <th scope="col">Status</th>
  </tr>
  <tr>
    <th scope="row">Ada</th>
    <td>Active</td>
  </tr>
</table>

A table with real <th> header cells, scoped to their column and row.

BackNext

The first version is a real, common trap: a bold <td> can be made to look pixel-identical to a proper header cell, but it carries none of the semantic information a <th> does — a screen reader has no way to know it's a header at all. The second version fixes that with three specific pieces. <th> marks a cell as a genuine header, not just visually distinct content. scope="col" or scope="row" makes explicit which axis a given header applies to — this matters as soon as a table has headers on both axes, like a data grid with column headers across the top and row labels down the left side, because without scope a screen reader can't tell which relationship a given <th> describes. And <caption> gives the whole table an accessible name and summary, announced before the screen reader starts reading rows — the equivalent of a sighted user reading a table's title before scanning it.

What people usually miss

Watch out

• A visually-bold <td> is not a substitute for <th>. They can render identically, but only <th> is exposed to assistive technology as a header — this is one of the most common accessible-table mistakes because it's invisible in a design review.
• scope becomes necessary, not optional, the moment a table has both row and column headers. A simple single-header-row table can sometimes get away without it, but a data grid with row labels needs scope="row" and scope="col" both present to disambiguate.
• <caption> is not the same as a heading placed visually above the table. A <h3> sitting outside the <table> element isn't programmatically tied to it; <caption> is a child of <table> itself and is what actually gets announced as the table's name.
• scope has a real ceiling. A genuinely complex table — merged cells (colspan/rowspan), or headers that span multiple levels — often can't be fully described by scope alone, and needs each data cell's headers attribute to list the ids of every header that applies to it, for fully explicit cell-to-header association.
• A table used purely for visual layout (not real tabular data) should not use <table> at all — the fix for accidental "table, 12 columns" announcements on a layout grid is CSS layout, not role="presentation" bolted onto real data markup.

Why this matters in interviews

"How would you make a data table screen-reader accessible?" is a real, common question, and naming scope, <caption>, and the headers/id fallback for complex tables — rather than just saying "add ARIA" — is what separates a candidate who's actually built one from one who hasn't.