Getting started with accessible tables
It comes up on almost every project, usually later than it should. A short on-ramp to accessible tables for teams who have not touched it before.
Most of it is correctness rather than charity: use the right element and much of it happens automatically. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.
What is actually at stake
Header cells must be marked as headers. It is worth being explicit about, because assumptions differ quietly. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.
Your first week
- Find out what is already in place
- Never use tables purely for layout
- Change one thing and measure it
A caption tells people what they are reading. There is a version of this that is over-engineered, and it is worth avoiding. It is worth deciding this deliberately rather than inheriting whatever the last person set up.
In practice
Accessibility work almost always improves the experience for people who have no impairment at all. Three things worth confirming about accessible tables before you move on:
- Someone can say what the current setup is without going to look
- A caption tells people what they are reading — and you know whether that is true here
- There is a way to tell whether the last change to this helped
The point is not perfection, it is knowing which of these you have consciously chosen to skip.