Five mistakes teams make with semantic HTML

The gap between knowing this and actually doing it is where most teams lose ground. These are the ones we run into repeatedly when we audit semantic HTML.

Most development decisions are really maintenance decisions wearing a different hat. Assume whoever inherits this will have half your context and none of your patience.

What to watch for

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• The right element gives you behaviour and accessibility for free
• A div with a click handler is not a button
• Never checking whether the fix actually worked

Semantic markup is the cheapest accessibility work available. That sounds obvious written down. It is still the thing most often skipped. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

What to do next

How to tell if yours is fine

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Three things worth confirming about semantic HTML before you move on:

• Someone can say what the current setup is without going to look
• The right element gives you behaviour and accessibility for free — 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.