Creating an accessible table can require a lot of care. Things can look right in the editor and on the page, but have hidden accessibility issues. Like so many other things, it's also important that table features are used for what they're intended for, not for the appearance.
Here's some of the most common table issues across the WCMS as identified by Siteimprove, what they mean, and how to solve them.
"Table cell missing content"
Generally speaking, this comes from having cells that are identified as being headings, but are empty. All headers must contain some kind of content that identifies the row or column data, as appropriate - even if, visually, it seems like it should be obvious what the column represents.
It may seem obvious what the third column is for, but it still needs header text.
Adding a header to the column fixes the accessibility issue.
"No data cells assigned to table header"
This is often caused by a header cell that is set in the wrong direction - for example, a header spanning all the columns of a table, but set to the "row" scope instead of the "column" scope. This is easy to do since there is no visual feedback for the scope - the only way to see the scope after a table is created is to view it in source mode.
It's important to note that merging multiple columns that start with a row header does not automatically convert it to a column header. You can do this by switching to source mode and changing "row" to "col", though often it may be easier to follow if you change the table design entirely. For the following example, you might consider having separate tables for each term instead of using a spanned header, or maybe using a "Term" column to hold the term information instead of relying on headers.
Visually, this table seems correct (though maybe a bit awkward), separating the course list by term.
Looking at the source view for the table reveals that the spanned headers have a scope of "row", the same as the regular headers.
"Table headers aren't referenced correctly"
This is another accessibility issue that looks fine visually, and the only way to see and fix it is in source view. It seems to be caused by pasting in tables from other software which is adding invalid attributes to the HTML.
In the following example, the tags for the table data have a "headers" attribute which at first glance seems correct - the actual header text basically matches, after all - but that's not how that attribute works. Since the table eaders have a column scope anyway, the data is already being identified with the correct header, and the header attribute on the table cells should simply be removed.
"Table header cell is missing a header role"
Yet again, the cause of this issue can't be seen without switching to source mode, and might be caused by pasting a table from another program, though it can also be caused by manually switching a <td> to a <th> in source view without adding a "scope" attribute.
The instances we've seen of this seem to be from trying to give a cell a background colour - so remember, the <th> tag has actual meaning, and should not be used just to get a certain appearance. If the item is not a header, don't make it one. If you want to call attention to a particular cell, you might consider using styles to give it a different appearance, for example using the "highlight mark" option.
The table is trying to call attention to lunch, but that's not a header for any of the data. Lunch is important, but not enough to negate the need for accessibility.
Checking your site for table accessibility issues
As you are authoring content, you can check for table accessibility issues in a couple of different ways. Note that each method checks differently and may not report all issues.
When you're inside the visual editor (e.g. in a copy text block), you can click the "check accessibility" button, which will identify accessibility issues within your content, including table accessibility issues.
When you're on a page, the Editoria11y accessibility checker will identify accessibility issues with the whole page, again including table accessibility issues.
Additionally, if you have access to Siteimprove, you can check your site's accessibility report for instances of these issues. Visiting the link, you will get a list of all the pages where the issue occurs. If this is every page on your site, there is a good chance that the issue is within your site footer.
Further reading
- "", MDN Web Docs
- "", WebAIM
- "", Digital Services & Solutions
- "", San Diego State University