Semantic HTML Is Not Optional — It's Structural Integrity
Accessibility is treated as a late-stage checklist in most teams. That's architecturally backwards. Semantic structure is the foundation, not the finish coat.
Let me describe a specific failure mode I've encountered across multiple engineering organizations. A product is built. It looks beautiful. The visual design is meticulous. Then, six months before launch, someone runs an accessibility audit. The report comes back. Hundreds of issues. The heading hierarchy is broken. Interactive elements aren't keyboard-navigable. Screen readers announce nonsense. The team panics.
This is what happens when semantic structure is treated as a feature rather than a foundation. You cannot retrofit meaning onto a structurally meaningless codebase without significant cost. The semantic layer isn't decoration applied after the engineering — it is the engineering.
HTML has a meaning system built into it. Headings establish hierarchy. Landmarks define regions. Buttons indicate interactivity. Labels describe inputs. When you use a div where a button belongs, you aren't just making things harder for screen reader users — you're discarding a system of structural meaning and replacing it with nothing.
I start with semantics. Every component I build begins with the question: what is this, structurally? What does it represent? What does a user expect to be able to do with it? Only once those questions are answered does visual styling enter the conversation.
The payoff is cumulative. Correct semantics gives you accessibility, keyboard navigation, and screen reader support for free. It also gives you better SEO, more maintainable code, and UIs that work correctly in contexts you haven't anticipated — browser extensions, content scrapers, voice interfaces, and whatever comes next.
Structural integrity isn't an accessibility feature. It's what good engineering looks like.