Semantic HTML

The difference in practice

A <div class="text-2xl font-bold">Pricing</div> and an <h2>Pricing</h2> render identically with the right CSS. To a browser painting pixels they are the same. To everything else they are not. A screen reader user can jump between headings but not between bold divs. A search engine builds an outline from h1–h6. A language model extracting an answer uses the heading to decide what the paragraph below it is about.

The elements that do most of the work are few: header, nav, main, article, section, aside, footer for page structure; h1–h6 in order for hierarchy; ul, ol and dl for lists; table with th for tabular data; button for things that do something and a for things that go somewhere.

Why it matters more now than it did

Search engines have long used structure as a signal. AI assistants raised the stakes, because extracting a quotable passage from a page depends on being able to tell where a section starts and ends. A page built from nested divs with visual styling gives an extractor no boundaries, so it either quotes the wrong span or skips the page. Pairing clean structure with schema markup makes both the machine-readable outline and the explicit metadata available.

Accessibility is the same argument with a legal edge: in the EU, the European Accessibility Act applies to many consumer-facing digital services from June 2025, and native elements are the cheapest route to conformance.

The common mistakes

Using a div with an onclick instead of a button — it is not focusable, not keyboard operable, and not announced as a control. Skipping heading levels for visual reasons rather than restyling. Multiple h1 elements with no clear main heading. And reaching for ARIA attributes to patch semantics that a native element would have provided for free; the first rule of ARIA is not to use it when plain HTML will do.