HTML Semantics and Accessibility

If an issue entry sent you here, you're in the right place. This article explains what HTML semantics is, why it matters for accessibility, and how choosing the right element prevents many ARIA issues before they appear. No prior experience with assistive technology is needed.

What HTML semantics is

Markup that carries meaning

Semantic HTML means choosing elements by what they are, not by how they look. A <button> is a button, an <h2> is a section heading, and a <nav> is a group of navigation links. Browsers use this meaning to build the accessibility tree, the structured version of the page that assistive technology reads. When your markup describes its purpose, browsers and assistive technology understand your content the same way you do.

Semantic and non-semantic elements

A semantic element describes its intended purpose. For example, <article> indicates a self-contained piece of content. A non-semantic element, like <div> or <span>, could mean anything, depending on the developer's intent. The HTML Living Standard defines the meaning of each element, so browsers, assistive technology, and developers share the same understanding.

From "div soup" to structure

Here is the same page structure written without semantics and with them:

<!-- Non-semantic "div soup" -->
<div id="header"></div>
<div id="nav"></div>
<div id="content"></div>
<div id="footer"></div>


<!-- Semantic markup -->
<header></header>
<nav></nav>
<main></main>
<footer></footer>

The two versions can look identical, but to assistive technology, only the second one has a structure. The <div> version is a flat wall of content with no landmarks to move between. The semantic version gives users a map of the page that they can navigate predictably and efficiently.

Why semantics matters for accessibility

More than good practice

For people who rely on assistive technology, semantics is essential:

• Screen readers announce each element's role, such as “button” or “heading level 2,” and let users jump between headings, landmarks, links, and form fields.
• Braille displays show what the screen reader conveys, including short role indicators, such as “btn” for a button or “h2” for a heading.
• Voice input software finds elements by their accessible names, and uses their roles to tell which elements users can activate. An element without an interactive role may not get a number or a name that users can say.

Benefits for users

• Predictable behavior – each element works the way users expect its role to work.
• Faster navigation – users can jump between headings, landmarks, links, and form fields instead of reading everything.
• Reduced cognitive load – a clear structure makes the page easier to understand.

The compliance angle

WCAG 2.2 is organized around four principles: content must be perceivable, operable, understandable, and robust (POUR). Standards and regulations that build on WCAG, such as EN 301 549 and Section 508, share these principles. Semantic HTML directly supports several success criteria, including 1.3.1 Info and Relationships, 2.4.6 Headings and Labels, and 4.1.2 Name, Role, Value.

A common failure case

A <div> with an onclick handler can look like a button, but it doesn't act like one. It can't receive keyboard focus, and it has no role, so a screen reader doesn't announce it as a button:

<!-- Avoid -->
<div onclick="submitForm()">Submit</div>


<!-- Recommended -->
<button type="submit">Submit</button>

The <button> is focusable, works with the keyboard, and has the correct role by default. The interactable-role validation flags elements like this <div>, which respond to pointer input without an interactive role. Using a native element resolves it.

Native HTML element types

Content sectioning

Elements: <header>, <nav>, <main>, <aside>, <section>, <article>, <footer>

Most of these elements can create landmarks: named regions of the page that assistive technology can list and jump to directly. Some of them only become landmarks in the right context. For example, a <header> is a banner landmark only when it isn't nested inside sectioning content, and a <section> is a region landmark only when it has an accessible name. <article> isn't a landmark, but screen readers still announce it as an article. For the full rules, refer to HTML Landmarks.

<main>
  <article>
    <header><h1>Accessibility in Forms</h1></header>
    <p>Forms are critical for user interaction...</p>
  </article>
</main>

Text content

Elements: <h1>–<h6>, <p>, <ul>, <ol>, <li>, <blockquote>

Headings create the outline that screen reader users navigate by. Keep them in a logical order, and don't skip levels to get a smaller font size; change the styling with CSS instead. Lists tell screen reader users how many items a group contains, and where it begins and ends.

<h1>Main topic</h1>
<h2>Subtopic</h2>
<h3>Detail</h3>

Inline text semantics

Elements: <strong>, <em>, <abbr>, <code>, <mark>

<strong> and <em> mark importance and stress emphasis in the code, unlike bold or italic styling alone. However, many screen readers don't announce emphasis by default, so put critical information in the text itself, as the word “Warning:” does in this example:

<p><strong>Warning:</strong> Passwords must be at least 12 characters.</p>

Images and multimedia

Elements: <img>, <figure>, <figcaption>, <audio>, <video>, <track>

Text alternatives and captions make visual and audio content available to everyone. It's a good practice to pair complex visuals, like charts, with a caption or a long description. For guidance on writing them, refer to Writing Effective Alt Text.

<figure>
  <img src="chart.png" alt="Bar chart of sales growth from 2023 to 2024">
  <figcaption>Annual sales growth</figcaption>
</figure>

Embedded content

Elements: <iframe>, <embed>, <object>

Screen readers may announce an <iframe> without a title as just “frame,” with no clue to what it contains. Give each frame a descriptive title, as the frame-title validation checks.

<iframe src="map.html" title="Company office location map"></iframe>

Table content

Elements: <table>, <caption>, <thead>, <tbody>, <th>, <td>

A caption and header cells make tabular data navigable. As users move through a table, screen readers announce the row and column headers that each cell belongs to.

<table>
  <caption>Monthly expenses</caption>
  <thead>
    <tr><th scope="col">Category</th><th scope="col">Amount</th></tr>
  </thead>
  <tbody>
    <tr><td>Rent</td><td>$1200</td></tr>
  </tbody>
</table>

Forms

Elements: <form>, <label>, <input>, <textarea>, <select>, <fieldset>, <legend>, <button>

A <label> that is programmatically associated with its field gives the field an accessible name, and clicking the label moves focus to the field. This supports success criteria 1.3.1, 3.3.2, and 4.1.2, and is what the label validation checks.

<label for="email">Email address</label>
<input type="email" id="email" name="email" required>

Interactive elements

Elements: <a>, <button>, <details>, <summary>, <dialog>

Native interactive elements come with keyboard support and accessibility behavior built in. In this example, <details> and <summary> create a disclosure widget that users can open with the keyboard, and screen readers announce whether it is expanded or collapsed, with no scripting at all.

<details>
  <summary>More information</summary>
  <p>This section contains extra details...</p>
</details>

Semantic HTML vs. ARIA-based semantics

Native HTML first

The general principle is to use native HTML semantics first, and add ARIA only when no suitable HTML element exists:

• Built-in accessibility – native elements come with keyboard support, focus behavior, and roles already in place.
• Fewer mistakes – ARIA is powerful but fragile, and incorrect use can harm accessibility.
• Broader compatibility – assistive technology handles native HTML most reliably.
• Compliance – WCAG requires the role of every user interface component to be programmatically determinable, and native HTML does this automatically.

Where ARIA use goes wrong

When ARIA is written by hand, small mistakes slip in. Several validations catch them:

• aria-valid-attr flags attributes that don't exist in the WAI-ARIA specification, usually typos, like aria-lable.
• aria-allowed-attr flags attributes that aren't supported by an element's role, for example aria-checked on a button.
• aria-prohibited-attr flags attributes that a role prohibits, for example aria-label on a plain <span>.
• aria-required-attr flags roles that are missing a required attribute, for example role="checkbox" without aria-checked.

Native elements avoid all four: an <input type="checkbox"> carries the right role and state, with no ARIA to get wrong.

Conditional semantics in HTML

Some elements only take on a semantic role when they are used in the right way:

• <section> becomes a region landmark only when it has an accessible name.
• <form> becomes a form landmark only when it has an accessible name.
• <header> and <footer> become banner and contentinfo landmarks only when they aren't nested inside sectioning content, such as <article> or <section>.
• <aside> is a complementary landmark at the top level of the page. When it is nested inside sectioning content, it is a landmark only if it has an accessible name.

This example shows the difference an accessible name makes:

<!-- Recommended: a section with an accessible name -->
<section aria-labelledby="features-heading">
  <h2 id="features-heading">Features</h2>
  <p>Our product offers several benefits...</p>
</section>


<!-- Avoid: a section without an accessible name -->
<section>
  <p>Content here...</p>
</section>

For the full mapping rules, refer to the HTML Accessibility API Mappings (HTML-AAM) and ARIA in HTML specifications.

Practical tips for writing accessible HTML

Recommended practices

• Prefer <button> over <div role="button">.
• Keep headings in a logical order.
• Write meaningful text alternatives for images.
• Associate every form field with a <label>.

Patterns to avoid

• Using <div> or <span> for elements that have a native equivalent.
• Skipping heading levels for styling.
• Overriding native semantics with ARIA when it isn't needed.

Conclusion

Semantic HTML is the backbone of accessible, usable, and compliant web design. By choosing elements by their purpose, you improve the experience of assistive technology users and align your work with accessibility standards like WCAG. Every time you write HTML, ask yourself: am I describing meaning, or just appearance?

Learn More

• HTML Living Standard, WHATWG
• HTML Accessibility API Mappings (HTML-AAM), W3C
• ARIA in HTML, W3C
• Accessible Rich Internet Applications (WAI-ARIA) 1.3, W3C
• HTML elements reference, MDN
• How to Meet WCAG (Quick Reference), W3C