Semantic HTML: The Most Underrated Skill in Frontend Development

"Use semantic HTML" often gets treated as a style preference — cleaner-looking markup. It's actually a functional requirement with a real, measurable cost when skipped, on three separate axes: accessibility, SEO, and free browser behavior you'd otherwise have to rebuild by hand.

What you lose with a `<div onClick>` button

<!-- Looks identical. Isn't. -->
<div onclick="submit()">Submit</div>
<button onclick="submit()">Submit</button>

• Keyboard access — a real `<button>` is focusable and activates on Enter/Space by default. A `<div>` needs manually added tabindex, and manually added keydown handlers for both keys, to match behavior that's simply free on the real element.
• Screen reader semantics — a `<button>` is announced as a button, with its pressed/disabled state communicated automatically. A `<div>` is announced as nothing — a screen reader user has no idea it's interactive at all without extra ARIA attributes bolted on to fake what the real element gives you natively.
• SEO structure — `<h1>`–`<h6>`, `<nav>`, `<article>`, and `<main>` give a crawler real, parseable structure about what the page's important content and hierarchy actually is, distinct from decoration. A page built entirely from generic `<div>`s hands a crawler no such signal.

The practical rule

Reach for the element whose native behavior matches your intent, before reaching for a generic one plus hand-rolled behavior: `<button>` for anything clickable that performs an action, `<a>` for anything that navigates, real heading tags in actual hierarchical order, `<nav>` around navigation, `<main>` around the page's primary content once per page. This is the same underlying principle behind this site's own heading-hierarchy audit noted in its decisions log — semantic correctness caught real bugs a purely visual review missed entirely.