When semantic HTML is worth the effort
The advice here is unglamorous, which is probably why it gets skipped. Semantic HTML is not free, and pretending otherwise leads to bad decisions.
The question is rarely whether something can be built, but what it costs to keep running afterwards. Budget a little time for it every quarter and it never becomes a project of its own.
When it is worth it
The right element gives you behaviour and accessibility for free. It is worth being explicit about, because assumptions differ quietly. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.
When it is not
If nothing downstream depends on it and nobody is complaining, it can wait. The reasoning matters more than the rule, because the rule has exceptions.
How to decide
Semantic markup is the cheapest accessibility work available. Getting it slightly wrong is survivable. Ignoring it entirely is not. Write the reasoning down alongside the decision, because the reasoning is what changes first.
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
None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.