Accessible Tables

Structuring data tables with proper headers and markup so assistive technologies can parse them.

stellae.design

Accessibility

Accessible tables ensure that screen readers can navigate and understand the relationships between data cells and their headers. HTML tables have built-in accessibility when marked up correctly: <th> elements define headers, the scope attribute indicates direction (col or row), and <caption> provides a table description. Screen readers use this structure to announce header context as users navigate cells — without it, users hear isolated values with no context. WCAG 2.1 SC 1.3.1 (Info and Relationships, Level A) requires that table structure and relationships are programmatically determinable. For complex tables with merged cells or multi-level headers, headers/id attributes create explicit associations. Responsive tables present additional challenges — ensuring mobile adaptations maintain meaningful structure.

Why It Matters

Data tables are one of the most information-dense patterns in web interfaces, presenting structured relationships between rows and columns that sighted users parse through spatial positioning — but for screen reader users, that spatial context is entirely absent unless the table is semantically marked up to communicate which headers describe which cells. When tables lack proper accessibility structure, screen reader users hear a flat stream of disconnected values with no indication of what each number, date, or label refers to, making it impossible to compare data, identify trends, or complete tasks like reviewing an invoice or understanding a schedule. Given that tables appear in nearly every business application, e-commerce order history, dashboard, and government service, their accessibility directly determines whether millions of users can participate in essential digital activities.

Real-World Examples

GOV.UK's accessible data table pattern

GOV.UK's design system provides a table component that uses semantic `<table>` markup with `<caption>` elements describing the table's content, `<th>` elements with proper scope attributes, and responsive behavior that maintains header associations even on narrow viewports through a stacking pattern rather than horizontal scrolling. The tables include zebra striping for visual readability and sufficient color contrast that meets WCAG AA standards, while the semantic structure ensures screen reader users can navigate efficiently using table-specific keyboard shortcuts. This approach demonstrates that accessible tables do not require complex ARIA — correct semantic HTML handles the majority of accessibility requirements.

Inclusive Components' sortable table pattern

Heydon Pickering's Inclusive Components demonstrates a sortable data table that uses native `<th>` buttons for sort controls, applies `aria-sort` to indicate the current sort direction, and announces sort changes through a visually hidden live region so screen reader users receive immediate feedback. The pattern maintains keyboard operability by making sort headers focusable buttons within the `<th>` elements, and it preserves the user's current focus position after a sort operation rather than moving focus to the top of the table. This implementation shows how interactive table features can be layered onto accessible foundations without breaking the underlying semantic structure.

Counter-example

Dashboard built entirely with div-based grid layout

A project management dashboard displays task data in a grid layout built entirely with `<div>` elements and CSS Grid, styled to look exactly like a table but carrying no semantic table structure — screen reader users encounter a wall of text with no navigable rows, columns, or header associations. When a user tries to use table navigation shortcuts (Ctrl+Alt+Arrow keys in NVDA), nothing happens because the assistive technology does not recognize the layout as a table. Adding `role="table"`, `role="row"`, and `role="cell"` after the fact partially restores navigation but still fails to associate headers correctly, creating a fragile accessibility band-aid over a fundamentally flawed structure.

Role-Specific Guidance

Common Mistakes

• The most widespread mistake is building data displays with `<div>` elements and CSS Grid or Flexbox because developers want more styling control, not realizing that this completely destroys the semantic table structure that screen readers depend on for cell-by-cell navigation and header association. Another frequent error is omitting `scope` attributes on `<th>` elements, which works acceptably in simple tables where screen readers can infer associations but fails completely in tables with row headers, merged cells, or multiple header levels. Teams also neglect responsive table behavior, either hiding columns on mobile (making data inaccessible) or implementing horizontal scroll without any indication to screen reader users that content extends beyond the visible viewport.