Getting started with semantic HTML
The gap between knowing this and actually doing it is where most teams lose ground. A short on-ramp to semantic HTML for teams who have not touched it before.
Code gets read far more often than it gets written, and usually by someone with less context than the author had. It rarely shows up as a line item, which is exactly why it slips.
The reason this keeps coming up
The right element gives you behaviour and accessibility for free. Getting it slightly wrong is survivable. Ignoring it entirely is not. If two people in the business would answer this differently, that gap is the actual problem.
Your first week
- Find out what is already in place
- A div with a click handler is not a button
- Change one thing and measure it
Semantic markup is the cheapest accessibility work available. This is the sort of thing that compounds, quietly, in both directions. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.
What this looks like day to day
The question is rarely whether something can be built, but what it costs to keep running afterwards. 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
None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.