Table Accessibility Checker
Check that data tables have headers a screen reader can use, and that layout tables say they are not data.
About this tool
Examines every table on a page and checks whether its structure can be read by something that cannot see it.
A sighted reader gets the relationship between a cell and its column from where it sits. A screen reader gets it from `<th>` elements, and in tables with more than one header row or column, from `scope`. Without them it announces a grid of values with nothing attaching them to anything — and the table looks completely correct on screen, which is why this goes unnoticed.
The opposite mistake is also checked. **A table used for layout is announced as a data table**, so a screen reader reads "table with 3 columns and 8 rows" before a page header that is not tabular at all. `role="presentation"` silences that; removing the table is better.
Also reported: missing captions, `<th>` used without `scope` in tables that need it, and cells whose `colspan` or `rowspan` do not add up.
Common questions
When do I need scope?
Whenever the table has headers in more than one direction, or more than one header row. On a simple table with a single header row, browsers infer the relationship correctly and scope adds nothing. Adding it anyway is harmless.
Does every table need a caption?
It needs a name from somewhere. A caption is the most robust, because it stays attached to the table when the surrounding page is reflowed. aria-label or aria-labelledby pointing at a nearby heading also works.
What is wrong with a layout table?
It is announced as data. A screen reader user hears the dimensions and enters table navigation mode for something that is not a table of anything. Modern CSS grid and flexbox do the job with no such cost.
Do tables affect SEO?
A well-marked-up table is easier for a search engine to extract, which matters for specification and comparison content. The accessibility case is much stronger, and the two fixes are the same fix.