At a glance
A converted table needs the same data relationships as the source. Compare cells, row and column headers, units, totals and notes, then test how a reader identifies each value’s context. A visually aligned grid without programmatic header associations is insufficient evidence of a usable HTML table.
A reader needs to know that 12 means applications in April, not an isolated number.
| Source relationship | HTML review | Expected evidence |
|---|---|---|
| Month above each count | Column header cells | April identifies its column |
| Application type beside counts | Row header cells | Permit identifies its row |
| Values measured in thousands | Caption or nearby description | Units remain explicit |
| Note excludes withdrawn cases | Connected note text | Qualification preserved |
Scroll sideways to see all columns. Use arrow keys when the table is focused.
List the tables before comparing
Identify every source table and mark continuations across pages. A repeated page header is not another data row. Decide whether a wide or multi-part table should remain one table, be split with repeated context, or receive a separate accessible data view.
Record which elements are real data tables and which are layout arrangements. Turning two visual columns into a table can introduce false relationships. Turning a true table into disconnected paragraphs can remove relationships readers need.
- Identify source tables and continuation pages.
- Compare every header, cell, unit and total in the agreed review scope.
- Inspect row/column associations and merged spans.
- Check captions, notes and references from the surrounding text.
Check both values and their context
For a simple table, use semantic header cells with appropriate row or column scope. A merged or layered header can require more explicit associations and specialist review. The right markup depends on the actual relationship, not on copying the source’s border styling.
Pick representative values and ask a reviewer to state their complete meaning using the HTML alone. Check negative values, empty versus zero cells, footnote markers and totals. A value in the correct visual location can still be announced with the wrong header.
| Check | Question |
|---|---|
| Blank cell | Is it missing data, not applicable or zero? |
| Multi-level header | Which group and subheading identify this value? |
| Continued table | Did the next page lose or duplicate a row? |
| Footnote | Does the qualification still apply to the right cell? |
Scroll sideways to see all columns. Use arrow keys when the table is focused.
Finish with a reader test
Use keyboard and a suitable screen-reader/table-navigation workflow to inspect the delivered HTML. Check mobile scrolling, caption visibility and the ability to reach content after the table. A responsive wrapper should preserve the table’s semantics.
Log defects against the source table and exact output revision. Repeat the affected tests after correction and keep the results with the publication record. Automated checks can identify some markup problems, but not whether a misplaced figure or missing qualification changed the data’s meaning.
Sources and scope
Methods, worksheets and illustrative examples are DocAccessible editorial contributions. These references support the technical or product details described above. W3C techniques are informative guidance; they are not a certification scheme.
- W3C PDF6: table markup
Table, row, header and data-cell structure in PDF.
- W3C H63: HTML table header scope
Associating row and column headers with data cells in HTML.
- W3C: evaluating web accessibility
Automated tools and knowledgeable human evaluation serve different roles.
Written by the DocAccessible team under our editorial policy. Suggest a correction if a source or product detail needs updating.