Semantic HTML.
Semantic HTML means choosing each element for its meaning rather than its appearance — a heading element for a heading, a button element for a button, a list element for a list.
The value of semantic markup is that a single choice brings several things for free. When the right element is used, the role declaration, keyboard support, focusability and built-in behaviour all come from the browser — none of them written by hand.
The reverse is also true, and expensive. Imitating a button with a div requires rebuilding four things by hand: focusability, keyboard events, role declaration and pressed state. When one of the four is forgotten the component stops working for some users — and usually at least one is forgotten.
- Something that GOES somewhere is a link; something that DOES something is a button. Confusing them breaks the keyboard behaviour along with the expectation.
- Heading level is not chosen for visual size; the level describes the structure, the size is set with CSS.
- A paragraph in bold is not a heading; it never appears in a screen reader’s navigation list.
- A structure that looks like a list but is not marked up as one does not say how many items there are.
- Tables are for data, not layout; a layout table is read out row by row and column by column.
The benefit of semantic HTML is not limited to accessibility either. Search engine crawlers derive the document structure from the same markup, and answer engines find section boundaries from headings when quoting a passage. Three readers — human, crawler and model — look at the same source.
The practical audit method is simple: turn off the page’s stylesheet and read the remaining HTML. If the document is still understandable, if headings look like headings and the order makes sense, the semantic structure is sound. If it is not, the page’s meaning has been buried in CSS — and no reader that does not read CSS can see it.
Semantic choices have a maintenance side too. Built-in elements evolve with browser updates; when a new assistive technology appears you need do nothing to support it. Hand-built imitations, by contrast, freeze in the assumptions of the day they were made and drift apart over time.
A practical habit: before writing a new component, check whether HTML already has an equivalent. There are built-in elements for disclosure blocks, progress bars, date inputs and dialogs — and most teams write them from scratch because they do not know they exist.