Make website data tables readable and accessible on mobile

Choose a table when the relationships need one

The WAI tables tutorial explains the purpose of accessible data-table markup: people need to identify how cells relate. A schedule, feature matrix or measurement series can depend on row and column relationships. An ordinary paragraph or group of independent cards may not.

Use a layout component for arranging a page, rather than a table used merely as invisible columns. Conversely, do not replace genuinely tabular comparisons with unlabelled text boxes just because cards look better at a small width.

For a fictional editorial review schedule, the question is “which page has which owner and status?” Decide those fields before choosing a display. Remove redundant columns, use clear units and explain abbreviations. Good content design can reduce complexity without discarding meaningful information.

Give the table a clear purpose and context

The WAI caption and summary guidance describes captions that identify a table, with additional explanation where structure needs it. A useful caption says what the data concerns; a separate note can state the period, units, fictional nature or important interpretation limits.

Do not make readers infer the subject from a distant heading. For the review schedule, “Fictional page-review assignments” identifies the example. If a table compares prices, its context needs the currency, billing period and applicable conditions rather than an unexplained number.

Keep a caption and an explanatory summary from needlessly repeating each other. Prefer a straightforward structure; a long instruction on how to navigate a tangled table can be a sign that separate, simpler tables would serve readers better.

<table>
  <caption>Fictional page-review assignments</caption>
  <thead>
    <tr>
      <th scope="col">Page</th>
      <th scope="col">Owner</th>
      <th scope="col">Status</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">About</th>
      <td>Editor A</td>
      <td>Review needed</td>
    </tr>
    <tr>
      <th scope="row">Contact</th>
      <td>Editor B</td>
      <td>Checked</td>
    </tr>
  </tbody>
</table>

Simplify grouped and multi-level headings

Some tables have grouped columns or headers that span several rows. WAI’s irregular-header tutorial explains grouping and appropriate scope relationships. Its multi-level tutorial uses explicit header identifiers and cell associations when the relationships require them.

Do not copy a complex headers/id pattern onto a simple table merely to add more attributes. Equally, one header row may be inadequate when a value depends on several grouped headings. Inspect the actual structure and use unique identifiers wherever explicit associations are required.

Before building a large matrix, try separating independent subjects into their own tables, each with a clear caption. For the fictional schedule, current review assignments and historical revision counts could be separate tasks. Separation is useful when it clarifies meaning, rather than hiding inconvenient comparison details.

Contain necessary scrolling without shrinking everything

WAI’s Reflow explanation recognizes an exception for content, such as data tables, whose meaning requires two-dimensional layout. It also shows placing a table in its own scrollable container so surrounding text can reflow at a narrow viewport.

The exception does not cover every heading, paragraph, search field or pagination control near the table. Check ordinary content at a width equivalent to 320 CSS pixels, such as a 1280-pixel desktop viewport at 400% zoom. These are CSS layout dimensions, not a requirement to use a particular phone model.

A horizontal swipe can be appropriate for the table, but it needs to be discoverable and operable. Do not clip the last column, suppress all overflow or reduce the text until the complete table happens to fit. Long cell content should still wrap sensibly where its meaning permits.

Mozilla’s overflow reference documents that scroll-container keyboard focusability varies. If the container cannot be reached and scrolled in supported browsers, the maintainer may need to make it focusable and give it an appropriate accessible name and context. Test that behaviour instead of adding tab stops to every cell.

Keep interactions as real, labelled controls

The ARIA table pattern distinguishes a static table from an interactive grid. Ordinary tables can contain links and buttons without turning every cell into a widget. Prefer native HTML table semantics where they fit.

For sorting, the WAI sortable-table example places buttons in sortable headers and exposes the active sort through aria-sort. A painted arrow alone does not tell all users what can be activated or which order is applied.

Define what happens to focus when sorting, filtering or paginating. Confirm that the visible rows, result count and current order agree, and that empty/error states make sense. An example pattern is a starting point for implementation and testing, not a certificate for an arbitrary plugin.

Check what your WordPress block actually publishes

The WordPress Table block guide documents header sections, captions and alignment controls, with final appearance depending on the theme. Use those supported controls for ordinary data, then inspect the public output.

An editor’s Caption label does not, by itself, establish the table’s accessible name or associations in every template. For example, the current Gutenberg table reference selects figcaption for its caption attribute. Verify your rendered relationship instead of treating a visual caption as proof of native table-caption semantics.

Likewise, confirm that header cells remain headers and that responsive CSS does not hide them or clip their row. If your chosen block cannot express a genuinely necessary complex structure, simplify the table or use a supported implementation that can preserve those relationships.

Use our plugin audit workflow before adding another table tool. A plugin is justified by a reader need and maintainable output, not merely by a longer feature list.

Test the associations and the actual task

WAI’s Info and Relationships explanation concerns information and relationships conveyed programmatically or in text. Combine markup inspection with a practical screen-reader check: locate the table, hear its identity, move through representative data cells and verify the appropriate headers.

Use supported browser/assistive-technology combinations and record which were tested. A single automated checker cannot demonstrate all reading and interaction behaviour. It can flag useful candidates, including missing or empty headings, but a human still needs to interpret the actual output.

The Keyboard explanation supports checking the full task without a pointer. Reach and operate sorting, filtering, links and pagination; scroll any necessary container; confirm visible focus and a way to move onward. Do not create a focus trap in the name of a responsive table.