How Using Semantic HTML Can Make Your Website More Accessible

Here’s an uncomfortable truth: most accessibility problems aren’t caused by missing ARIA attributes or failing to meet obscure WCAG criteria. They’re caused by developers using the wrong HTML elements. A <div> where a <button> should be. A <span> where a <heading> should be. Generic elements doing specific jobs, badly.

Semantic HTML is the foundation of web accessibility. It’s also the most underused tool in a developer’s toolkit. Let me explain why it matters and how to use it properly.

What Is Semantic HTML?

Semantic HTML means using HTML elements for their intended purpose. A <nav> for navigation. A <button> for interactive actions. An <article> for standalone content. A <header> for introductory content. Each element carries built-in meaning that browsers, search engines, and assistive technologies understand.

Non-semantic HTML — <div> and <span> for everything — carries no meaning at all. It’s a blank canvas. Great for layout. Terrible for communication.

Why Assistive Technologies Depend on Semantics

Screen readers don’t see your visual design. They don’t know that a styled <div> looks like a button because it has a border-radius, a background color, and a cursor pointer. To a screen reader, it’s just a generic container with some text inside it.

But a <button> element? A screen reader announces it as “button,” communicates that it’s interactive, and allows the user to activate it with Enter or Space. All of that behavior is built in — for free — when you use the right element.

The Big Five Semantic Elements

1. Landmarks: header, nav, main, aside, footer

These create a navigable map of your page. Screen reader users can jump directly to the main content, skip to the navigation, or find the footer — all without scrolling. If your page doesn’t use these, every screen reader user has to wade through your entire DOM from top to bottom.

2. Headings: h1 through h6

Headings create a document outline. Screen reader users navigate by headings constantly — it’s their primary way of scanning content. A proper heading hierarchy (h1 → h2 → h3, never skipping levels) is like a table of contents for the page.

3. Lists: ul, ol, dl

When a screen reader encounters a list, it announces the total number of items. “List, 5 items.” This gives the user context before they start navigating. A set of <div>s with dashes doesn’t do this.

4. Interactive Elements: button, a, input, select, textarea

These elements have built-in keyboard handling, focus management, and screen reader announcements. A <button> is focusable, activatable with Enter and Space, and announced as “button.” A <div onclick="..."> is none of those things unless you manually add tabindex, keyboard event handlers, and ARIA roles. Why rebuild what HTML gives you for free?

5. Content Elements: article, section, figure, figcaption, time, address

These communicate the purpose of content. An <article> is standalone content that could be syndicated. A <time> element with a datetime attribute gives machines a parseable date. A <figure> with <figcaption> associates an image with its description.

Common Anti-Patterns

Clickable divs: <div onclick="navigate('/about')">About</div> — Use <a href="/about">About</a>.

Styled spans as buttons: <span class="btn" onclick="submit()">Submit</span> — Use <button type="submit">Submit</button>.

Divs as headings: <div class="title">Section Title</div> — Use the appropriate heading level.

Missing form labels: An <input> without a <label> is anonymous to assistive technology. Always pair them.

The First Rule of ARIA

The W3C’s first rule of ARIA is: “If you can use a native HTML element with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state, or property, then do so.”

In other words: use the right HTML element before reaching for ARIA. ARIA is a patch for situations where HTML doesn’t have the right element. It’s not a replacement for semantic HTML.

Start Here

Open your site, disable CSS, and look at the raw content. Can you still understand the structure? Can you tell what’s a heading, what’s a list, what’s navigation, and what’s the main content? If yes, your semantics are solid. If not, you have work to do — and it’s some of the most impactful accessibility work you’ll ever ship.