How to Create Accessible Data Tables in HTML

First decide whether the content is truly tabular

A data table represents information whose meaning depends on relationships across rows and columns. A price comparison, schedule, measurement series, invoice, or specification matrix is naturally tabular because readers compare values against headers.

A two-column visual arrangement of a contact form, navigation links, product cards, or paragraphs is not a data table. Use CSS Grid or Flexbox for layout. Semantic table markup tells assistive technology to expect data relationships, so using it for placement creates false structure.

If each item can be read independently without row or column context, a list, definition list, headings, cards, or ordinary paragraphs may be simpler and more usable.

Accessible markup preserves the data relationships

Sighted readers repeatedly glance from a value to its row and column headings. Screen reader users often navigate cell by cell while software announces the applicable headers. Correct markup lets the same relationship survive when visual lines, color, alignment, or the full table are not perceived at once.

WCAG 2.2 Success Criterion 1.3.1 requires information, structure, and relationships conveyed through presentation to be programmatically determinable or available in text. Bold text and a gray background can make a cell look like a header, but only semantic markup exposes its role reliably.

Build the semantic anatomy of a simple table

The table element contains the data grid. A caption is the table’s associated title. The thead, tbody, and optional tfoot elements identify row groups. Each tr is a row. Header cells use th; data cells use td.

<table>
  <caption>Support response times by plan</caption>
  <thead>
    <tr>
      <th scope="col">Plan</th>
      <th scope="col">Weekdays</th>
      <th scope="col">Weekends</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Standard</th>
      <td>24 hours</td>
      <td>48 hours</td>
    </tr>
  </tbody>
</table>

For the value “24 hours,” a user can determine both “Standard” and “Weekdays.” Those associations—not the borders or colors—make the value intelligible.

Give the table a useful caption

A caption identifies the overall topic and remains programmatically associated with the table. It is especially useful when several tables appear on the same page or when users navigate directly between tables.

Write a concise title that distinguishes the data: “Quarterly revenue by region, 2025” is more useful than “Table 1.” If a visible heading immediately before the table already provides an adequate title, avoid needless repetition, but preserve a clear programmatic identity through an appropriate pattern.

<p class="table-title">
  Office opening hours
</p>
<table>...</table>

<table>
  <caption>
    Office opening hours
  </caption>
  ...
</table>

A caption is not the place for a long explanation of navigation or trends. Put a fuller introduction in nearby prose and keep the caption as the table identifier.

Use th and scope to express simple associations

Mark every genuine header as th. In a table with both top-column headings and first-column row headings, add scope="col" and scope="row" so the direction is explicit.

Do not use th merely because you want bold, centered, or shaded text. A total may be a data value rather than a header; style it with CSS if it does not label other cells. Likewise, do not use td for real headers and rely on bold styling.

Escalate markup only when the header structure requires it

Simple tables are easier to understand and maintain. Before coding a complex table, ask whether it can be split into two smaller tables, whether repeated information can move to prose, or whether a simpler header arrangement can preserve the task.

With explicit associations, a data cell might use headers="region-north quarter-q1 revenue". Every referenced ID must exist in the same table and identify an appropriate header cell. This method is powerful but error-prone when data changes, so validate generated output and retest after editing rows or columns.

Make cell content understandable and consistent

Perfect markup cannot rescue unclear data. Use descriptive headers, define abbreviations, include units, and keep comparable values in consistent formats.

• Put units in the column header when they apply to the whole column: “Revenue (USD thousands).”
• Distinguish zero, not applicable, not measured, and missing data; a dash alone can be ambiguous.
• Use the same date, currency, decimal, and percentage formats within a column.
• Explain unfamiliar abbreviations before or within the table.
• Do not communicate status only through red and green cell backgrounds; include text, icons with names, or another cue.
• Write meaningful link names. “Edit Standard plan” is clearer than several links that all say “Edit.”
• Avoid merging cells purely to create visual spacing.

Keep relationships intact on small screens and at zoom

Wide tables can overflow a mobile viewport or force horizontal page scrolling at high zoom. A dependable starting point is to place the table inside a labeled or contextually clear horizontal-scroll container while leaving the semantic table intact.

<div class="table-scroll"
     tabindex="0"
     aria-label="Support response times; scroll horizontally">
  <table>...</table>
</div>

Only make the wrapper focusable when keyboard users genuinely need it to scroll and the focus purpose is clear. Ensure its focus indicator is visible. Avoid freezing so many rows or columns that little data remains visible.

Some responsive patterns turn every row into a card and inject column names with CSS-generated content. Test these carefully: CSS text may not be exposed consistently, source order can become confusing, and the original table relationships may be obscured. If the data is more usable as cards on every screen, it may not need to be a table in the first place.

Treat sorting and filtering as controls layered onto a table

A sortable header is both a data header and the location of a control. Put a real button inside the th rather than adding a click handler to the header cell. The button needs an action-oriented accessible name or surrounding context, keyboard operation, and visible focus.

Communicate the current sort state programmatically, commonly with aria-sort on the applicable header cell, and update it after sorting. Announce significant changes when necessary without causing excessive interruptions. Filtering controls need visible labels and should explain which table they affect.

Audit the final table rendered by WordPress

The WordPress Table block can create a basic grid, but visual header styling does not guarantee that the generated cells are correct for your data. A theme may change display properties, hide overflow, reduce contrast, or add wrappers. Pasted spreadsheet data can lose its semantic markup.

1. Confirm the content is tabular.Replace layout grids and label-value pairs with more appropriate semantic structures.
2. Identify the caption and headers.Check the final HTML for caption, th, and accurate row or column direction.
3. Inspect every association.Navigate across representative cells and verify that changing headers are announced.
4. Review merged or multi-level cells.Validate groups or explicit id and headers references after each edit.
5. Zoom and resize.Check reflow, horizontal scrolling, clipped focus, sticky content, and text enlargement.
6. Test color and content.Verify contrast, non-color status cues, units, abbreviations, empty values, and link names.
7. Use keyboard and screen reader navigation.Test controls, scroll containers, sorting, filtering, and cell-by-cell context.

For a simple, controlled starting point, use the DOFIW Accessible Table Generator to create semantic HTML and then test it in the published theme.

What a table generator can—and cannot—solve

The generator can produce a caption, column and row header cells, explicit scope values, table sections, and reusable HTML from the data you provide. Processing occurs locally in the browser; the entered table data is not uploaded to a server.

A generator for simple tables should not be forced to model irregular or multi-level headers it does not support. Complex data may require custom markup, restructuring, and assistive-technology testing. Generated code is a starting point, not a conformance certificate.

Common table mistakes and direct fixes

• Table used for layout: replace it with semantic HTML and CSS Grid or Flexbox.
• Headers coded as td: use th for cells that label rows or columns.
• Bold cells assumed to be headers: expose the relationship in markup, not only presentation.
• No table identity: add a concise caption when a visible table title is provided or needed.
• Scope in the wrong direction: map each header to the rows, columns, or groups it actually labels.
• Broken headers references: verify that every listed ID exists, is unique, and belongs to the same table.
• Overly complex grid: simplify or split the table before adding more attributes.
• Blank or symbol-only values: define what missing, zero, unavailable, and not applicable mean.
• Color-only statuses: include visible text or another distinguishable cue.
• Identical action links: include the row subject in each link’s accessible purpose.
• Responsive CSS destroys display semantics: preserve the table or test the transformed structure thoroughly.
• Testing only the editor: inspect and navigate the final WordPress output at mobile size and high zoom.

Accessible data table checklist

Continue the DOFIW structured-content workflow

Frequently asked questions