A short guide to accessible tables

This is one of those topics that looks small until it costs you something. Everything we would tell a client about accessible tables in the time it takes to drink a coffee.

Accessibility work almost always improves the experience for people who have no impairment at all. 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. Where this goes wrong is almost never a lack of knowledge. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

Where to start

Never use tables purely for layout. Small and consistent beats large and occasional here. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

The mistakes we see most

A caption tells people what they are reading. This is the sort of thing that compounds, quietly, in both directions. Doing this properly once is usually cheaper than doing it approximately three times.

The short version

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

Most of the value here comes from doing the first two things, not all of them.