Semantic HTML

A <div> with a click handler and a <button> look identical on screen. To a screen reader, keyboard, or voice control tool, they are completely different objects — and only one of them works correctly.

What semantic HTML is

Semantic HTML means using the HTML element whose meaning matches its purpose. A <button> for something a user activates. A <nav> for navigation. An <h2> for a section heading. An <a> for a link to another resource. These elements carry built-in semantics — they communicate their role, state, and properties to assistive technologies without requiring any additional code.

What non-semantic HTML costs

A <div> has no role. A <span> has no role. When you build interactive components from these elements, you must manually replicate everything the browser provides for free with semantic elements: keyboard interaction, focus management, ARIA role, ARIA state, and accessible name. The result is more code, more maintenance burden, and more opportunity for accessibility failures. The baseline approach is to use the element the browser already provides.

The most common violations

• Using <div> or <span> for buttons and links
• Using <div> with a font size for headings instead of <h1>–<h6>
• Using a <table> for layout rather than data
• Using <br> tags for spacing rather than CSS margin
• Building custom dropdowns, tabs, and modals from unsemantic elements when native or well-established ARIA patterns exist

ARIA as a supplement

ARIA attributes — role, aria-label, aria-expanded, aria-live — exist to fill gaps where native HTML semantics are insufficient. They should supplement semantic HTML, not replace it. The first rule of ARIA is: do not use ARIA if a native HTML element already communicates the same thing. ARIA does not add functionality — it adds meaning. The keyboard interaction still needs to be built separately.

Complex patterns and the ARIA Authoring Practices

For complex widget patterns that native HTML cannot cover — tab interfaces, comboboxes, disclosure widgets, tree views, modal dialogs, carousels — the WAI-ARIA Authoring Practices Guide (APG) at www.w3.org/WAI/ARIA/apg documents the correct keyboard interaction model and ARIA structure for each pattern. The APG is the authoritative reference for building custom interactive components accessibly. Before writing custom keyboard handlers or ARIA roles for any complex widget, consult the APG pattern for that component — it specifies which keys do what, which ARIA attributes are required, and where focus should move on each interaction.

The takeaway

Use the HTML element that matches the meaning. Before reaching for ARIA, ask whether a semantic native element would serve the same purpose. The most accessible component you can build is one that uses native HTML correctly — because the browser and platform already handle everything else. When a custom component is unavoidable, the WAI-ARIA APG provides the specification to build it correctly.