Semantic HTML: Structure as Accessibility Infrastructure

Why it exists

The web began as a document system where markup carried meaning. When developers replace meaningful tags with generic containers, browsers and assistive technologies lose the structural map they need to present content to users who cannot see the screen. Semantic HTML preserves that map without extra JavaScript or ARIA by using the right element for the right purpose.

The mental model

Think of HTML tags as the architectural blueprint of a building. A div is an unmarked room, a button is a door with a handle, and a nav is a hallway sign. Screen readers and keyboards navigate by reading those signs. When you use the wrong tag, you are hanging a picture over a door and expecting visitors to know it opens. The browser supplies behavior, focus management, and announcements for free when you pick the native element that matches your intent.

How it works

Every HTML element has an implicit role in the accessibility tree that the browser exposes to assistive tech. A button element is focusable, clickable with Enter or Space, and announced as a button. A heading element creates a navigable outline. A table element exposes row and column relationships. When you use a div with an onClick handler instead, none of that happens unless you manually add tabindex, key listeners, and ARIA roles. Native semantics do the work for you.

When to use it

Use semantic elements whenever the content matches their purpose. Use button for clickable actions, a for navigation links, h1 through h6 for document outline, nav and main for page regions, ul and ol for lists, and table for tabular data. Use landmark regions so screen reader users can jump directly to content without tabbing through every interactive element. Use label elements explicitly tied to inputs so form fields announce their purpose.

When not to use it

Do not use a heading tag just because you want large bold text; that pollutes the outline and disorients screen reader users who navigate by heading. Do not wrap everything in divs and add ARIA as a retrofit; ARIA is powerful but fragile, and native HTML is more robust. Do not choose a tag based on its default browser styling rather than its meaning. If the semantics do not fit, that is when you reach for ARIA, not before.

One canonical example

Imagine a modal dialog. The correct pattern uses a button to open it, a dialog element or a div with role dialog, a focus trap, and an h2 for the title. The dialog element itself handles focus management and backdrop behavior in modern browsers. If you instead build it from nested divs with CSS positioning, you must rebuild focus trapping, Escape key handling, and screen reader announcements from scratch. A single dialog tag replaces dozens of lines of accessibility code.