Three myths about accessible tables

We end up explaining this on discovery calls often enough that it deserved writing down. A few things about accessible tables that get repeated more often than they get checked.

Most of it is correctness rather than charity: use the right element and much of it happens automatically. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

“It only matters for big sites”

Header cells must be marked as headers. There is a version of this that is over-engineered, and it is worth avoiding. The version that survives contact with a real deadline is the simple one.

“We can deal with it after launch”

Sometimes true, usually expensive. Getting it slightly wrong is survivable. Ignoring it entirely is not.

“Our platform handles it”

A caption tells people what they are reading. There is a version of this that is over-engineered, and it is worth avoiding. Write the reasoning down alongside the decision, because the reasoning is what changes first.

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
• Never use tables purely for layout — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If any of that sounds like a description of your current setup, it is fixable.