``` …pause for a second. There’s probably a better option. ## The Subtle Shift The real change isn’t technical — it’s mental. Instead of asking: “What do I need to style this?” Start asking: “What _is_ this element?” That small shift leads to better decisions automatically. ## This Isn’t Only About Screen Readers Semantic structure helps: - **Keyboard users** — focusable controls are predictable when you use real links and buttons. - **Search engines** — content hierarchy still signals what matters. - **Your team** — the next developer reads `
` vs “div #3” faster than you think. Accessibility conversations often get framed as “edge cases.” That’s a statistical mistake. Disability is common; situational limits (sunlight, one hand, slow network) are universal. ## A Practical Review Habit Before merge, ask: - Can I navigate this screen with headings and landmarks alone? - Are all interactive controls real controls? - Do form fields have discoverable names? - Did I introduce a “fake” element because CSS was annoying? Annoying CSS is a **you** problem. Broken structure is a **user** problem. ## Closing Thought Div soup isn’t a crime. Every developer has written it at some point. But staying there is a missed opportunity. Semantic HTML isn’t about being “correct” or “by the book.” It’s about making your code more understandable, more accessible, and more maintainable. In a field where complexity is always increasing, anything that makes systems easier to understand is worth taking seriously. So next time you reach for a ``, take half a second and ask: **“Is this really just a box?”** Sometimes it is. But more often than not, it’s something more — and HTML already has a word for it. If you wouldn’t ship a REST API where every field was named `data` and `thing`, don’t ship a page where every region is `div`. Structure is part of the product. Treat it that way.
---