Five mistakes teams make with accessible tables

We end up explaining this on discovery calls often enough that it deserved writing down. These are the ones we run into repeatedly when we audit accessible tables.

Accessibility work almost always improves the experience for people who have no impairment at all. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

Where it usually goes wrong

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Header cells must be marked as headers
• Never use tables purely for layout
• Never checking whether the fix actually worked

A caption tells people what they are reading. The cost of getting this wrong is rarely visible on the day it happens. The version that survives contact with a real deadline is the simple one.

A reasonable first step

What this looks like day to day

The cost of retrofitting accessibility is several times the cost of building it in. 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

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.