Data Tables

## The problem scope solves A sighted reader resolves a table cell by glancing up to the column header and left to the row label. A screen-reader user cannot glance. They move through the grid one cell at a time, and the only thing that keeps them oriented is the assistive technology announcing the headers that apply to the current cell. That announcement requires the browser to know which header cells govern which data cells — the *header association*. `scope` is the simple, declarative way to state it. ## The values `scope` is an attribute of `<th>` (only `<th>`, never `<td>`) with four keywords: - `scope="col"` — this cell is the header for the rest of the column beneath it. - `scope="row"` — this cell is the header for the rest of the cells in its row. - `scope="colgroup"` — this cell heads all the columns in its column group. - `scope="rowgroup"` — this cell heads all the rows in its row group (a `<thead>`, `<tbody>`, or `<tfoot>`). The missing-value default is `auto`, which is exactly the guessing mode described below. ```html <table> <caption>Revenue by region</caption> <thead> <tr> <td></td> <th scope="col">Q1</th> <th scope="col">Q2</th> </tr> </thead> <tbody> <tr> <th scope="row">EMEA</th> <td>12.4</td> <td>13.1</td> </tr> <tr> <th scope="row">APAC</th> <td>8.9</td> <td>9.7</td> </tr> </tbody> </table> ``` Note the empty top-left corner cell: it heads nothing, so it is a `<td>`, not a `<th>`. ## What the semantics map to `<th>` is not "a bold, centred cell". It maps to a header role in the accessibility tree — `columnheader` or `rowheader` depending on its orientation — while `<td>` maps to an ordinary cell. Bold and centred is just the user-agent stylesheet; the role is the part that matters, and it is the part you throw away when you use `<td>` with a bold class for row labels. ## What actually happens without scope Browsers implement a fallback algorithm that walks up the column and left along the row looking for header cells. For a plain table with one header row and no row labels, this typically produces the right answer, which is why so many tables get away with omitting `scope`. Two things go wrong as tables get real: 1. **Two-way tables.** When a table has both column headers and a row-label column, the guess about which header applies in which direction becomes ambiguous, and different assistive technologies resolve it differently. The user hears the wrong header, or none. 2. **Spanning and multi-row headers.** Once `colspan`/`rowspan` are in play, or there are two stacked rows of headers, position alone no longer determines the relationship. That is the point where `scope` is not enough either, and explicit `headers`/`id` association takes over. The practical rule: write `scope` on every `<th>` in a data table. It costs nothing, it removes the dependency on heuristics, and it documents intent for the next developer. ## Related header details A `<th>` may also carry an `abbr` attribute giving a shortened form of the header text; some assistive technologies use it when repeating a long header for every cell in a column. It is optional and support varies — never put essential information only there. Empty header cells are a smell. If a `<th>` has no text, either it heads nothing (make it a `<td>`) or the label is missing and the column is unexplained for everyone. ## How to check it You cannot verify header association by looking at the page. Inspect the accessibility tree in devtools and confirm each header cell shows a `columnheader` or `rowheader` role, or navigate the table with a screen reader's table-navigation keys and listen to what is announced when you cross a row or column boundary. A table that reads as a stream of naked numbers is a table with broken associations, however tidy the markup looks.