01 — Purpose

Structure and meaning from the platform

Semantic HTML provides meaning and structure — use elements for their intended purpose, including landmarks that speed up navigation.

Browsers, assistive technology, and search engines all consume HTML semantics. A real button ships keyboard activation, focus behaviour, and a clear role. A styled div ships none of that unless you rebuild it by hand — often incompletely.

See the HTML standard and ARIA usage for when native HTML is not enough.

02 — Elements

Use elements for their intended purpose

The platform already provides useful semantics — use them.

  • buttons for actions — submit, toggle, open menu
  • links for navigation — moving to a URL or in-page target
  • headings for hierarchy — one logical outline, no skipped levels for styling
  • lists and tables for their real jobs — not stacked divs pretending otherwise

03 — Landmarks

Landmarks speed up navigation

Screen reader users jump by region — header, nav, main, footer — when structure is clear.

  • one main per page — wrap primary content, not every column
  • label multiple nav regions — “Main”, “Breadcrumb”, “Legal”
  • skip link to #main or equivalent — first keyboard shortcut
  • avoid landmark soup — prefer native elements over role="region" on generic divs

04 — Practice

Good semantic HTML

Semantic HTML improves accessibility, maintainability, resilience, and browser support.

05 — Avoid

Fake semantics

Div-based interaction and unnecessary ARIA create fragile interfaces.

  • div click handlers without role, keyboard, or focus
  • multiple unlabelled nav elements — “navigation, navigation, navigation” in rotor menus
  • unnecessary ARIA replacing native behaviour

06 — Close

Use what the platform gives you

Correct HTML is the cheapest accessibility win available.

Before adding JavaScript or ARIA, ask whether the right element already exists. Most custom widgets fail review because they reinvented a native control poorly.

See reading order and the accessibility QA checklist.