Five mistakes teams make with heading structure

It comes up on almost every project, usually later than it should. These are the ones we run into repeatedly when we audit heading structure.

Accessibility work almost always improves the experience for people who have no impairment at all. It rarely shows up as a line item, which is exactly why it slips.

Where it usually goes wrong

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Headings are how many people navigate a page
• One h1, then no skipped levels
• Never checking whether the fix actually worked

Do not choose heading levels for their font size. It is worth being explicit about, because assumptions differ quietly. Doing this properly once is usually cheaper than doing it approximately three times.

Making it stick

In practice

Most of it is correctness rather than charity: use the right element and much of it happens automatically. Three things worth confirming about heading structure before you move on:

• Someone can say what the current setup is without going to look
• Do not choose heading levels for their font size — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Worth checking on your own setup before it becomes someone else's problem to fix.