This article stems from a tweet I almost sent…
I’d been trying to find clear reasons explaining why tables are not an accessible way to present content, except data. I know they’re not, but the person I needed to convince wanted external proof, and a more detailed reason than “they are difficult for screen reading software to navigate”.
My draft tweet:
“Does anyone have a link to a page explaining why tables are not an accessible way to present content, except data? Need evidence to show a stakeholder… Searched GDS service design manual and accessibility pages, W3 site, RNIB, Google… @a11ylondon #accessibility”
In the end, University of Minnesota via a Google search came up with the best explanation of why tables aren’t accessible. So many authoritative sites that I hold in high esteem advised against using them, but no-one was saying why.
Your design’s great… but I think a table would be good
And when you tell a stakeholder, no you can’t have this thing that you think is a very good solution, and have been using forever, they tend to want to know why, with more detail than “it isn’t good for accessibility”, and that’s not unreasonable of them.
But why though?
So as I say, University of Minnesota came up with the goods:
“Screen readers will read the content of a table in a linear fashion — left to right, top to bottom.”
Which means tables can’t be scanned vertically up and down by column, or diagonally, or from one row to another two rows down, skipping the middle one, by people using screen readers in the same easy way that people looking directly at tables without a screen reader can — so they are not a useful, or equal, way of presenting information for quick comparison for those users.
This was a great explanation to access, as the thing the stakeholder wanted to use the table for was a comparison chart… of what were essentially product search results. So, a lot of rows and comparisons to make. (Obviously, there are various other reasons why this wouldn’t work for search results!)
Keep it simple. Always.
University of Minnesota also mentions that non-simple table layouts should not be used:
“Tables should not contain merged cells as they are difficult to navigate with screen readers… Complex tables that include nested tables or that require two rows in order to explain the information contained in the columns, are more difficult to tag for accessibility.”
Merged cells are difficult to navigate because they confuse the reading order.
Screen reading software in action
Watch this video about good and bad table design, it’s narrated by a screen reader:
Screen reader reading different table layout
Jaws 16 reading a data table with three headers
Find out more about accessible tables and making your website accessible:
- GOV UK content design guidance on tables
- W3 tutorial on accessible tables
- The University of Minnesota on using tables
- GOV UK how to make accessible tables for data presentation
- GOV UK on helping people to use your service
- RNIB on accessible websites
Photo by Sydney Rae on Unsplash
Blog post originally posted on medium.com