Tables & data

A table is a grid of relationships: every cell means something only because of the row and column it sits in. Sighted users get that for free — they glance up to the column heading and left to the row heading and read the cell in context. A screen reader can do exactly the same, but only if the structure is in the markup. Give it real header cells with the right scope and it will announce “Quarter 2, Revenue, £48,000” as the user moves through the grid. Leave the headers as plain <td> cells and the table collapses into a flat stream of numbers with no labels at all — noise, not data.

Who this affects

• Screen reader users navigate tables cell by cell and rely on the associated headers being read back with each value. Without header semantics they hear bare cell contents and have to count columns by hand to work out what each number means — if they can at all.
• Low-vision and zoom users magnify the page until only a few cells fit on screen, so the headings scroll out of view as they read across a wide row. Sticky, programmatic headers and a clear caption keep the table’s purpose and column meanings reachable even when most of the grid is off-screen.
• Cognitive users benefit from a <caption> that names the table up front, and from a real data table not being padded out with layout tables that add meaningless rows and columns to wade through.

Standards covered

The lesson in this category maps table structure to the success criteria and laws that require it. The same markup satisfies all of them at once.

Lessons

• Accessible data tables

  Real header cells, scope on every header, a caption that names the table, and never exposing a layout table as data — the four fixes behind most table failures.

  1.3.1 1.3.2

• Complex tables with multi-level headers

  Tie every cell to its row and column headers with scope or headers/id.

• Responsive & sortable tables

  Keep header associations and a keyboard-scrollable region when tables adapt.