Accessible tables, explained without the jargon

The gap between knowing this and actually doing it is where most teams lose ground. Here is accessible tables without the vocabulary that usually surrounds it.

Accessibility work almost always improves the experience for people who have no impairment at all. Assume whoever inherits this will have half your context and none of your patience.

The short version

Header cells must be marked as headers. Where this goes wrong is almost never a lack of knowledge. It rarely shows up as a line item, which is exactly why it slips.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. The cost of getting this wrong is rarely visible on the day it happens.

Never use tables purely for layout. Where this goes wrong is almost never a lack of knowledge. If it only works because one person remembers to do something, it does not work yet.

Where to go from here

A caption tells people what they are reading. Getting it slightly wrong is survivable. Ignoring it entirely is not. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

What this looks like day to day

Most of it is correctness rather than charity: use the right element and much of it happens automatically. 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

Pick the one that would hurt most if it failed, and start there.