Semantic HTML for Accessibility

Why it matters

A page built from styled <div> elements can look finished and still be unusable: a screen reader user hears "clickable" instead of "button", opens an empty list of headings, lands in a field with no name and reads a table number with no column. Each of these is a failure of WCAG 2.2 success criterion 1.3.1 Info and Relationships or 4.1.2 Name, Role, Value, both Level A, so the page fails conformance at the lowest level and the people who depend on assistive technology cannot complete the task.

For the tester, semantics are among the cheapest accessibility checks there are. You do not need a screen reader to see that a heading is a styled <div> or that an input has no <label>: the markup and the browser’s accessibility panel show it in seconds, and the fix is usually a one-element change. Finding it in the first review of a new component saves a full screen reader round later, and the same roles and names make automated tests and locators more stable too.

From markup to the accessibility tree

When the browser parses HTML it builds the DOM, the live tree of the page’s elements, and from the DOM a second structure: the accessibility tree. Every meaningful element becomes a node with a role (heading, link, button, textbox, cell), an accessible name (the heading text, the link text, the label of a field) and states or properties (heading level 2, required, checked, disabled). Elements that carry no meaning, such as <div> and <span>, become generic nodes or are left out of the tree entirely.

Screen readers and voice control read this tree through the operating system’s accessibility API, not the rendered pixels. A screen reader announces role and name together ("Place order, button"), offers lists of headings, landmarks and links so the user can jump instead of reading in order, and uses the role to decide which keys operate the element. Voice control activates whatever the user names ("click Place order"), so the spoken name must exist in the tree. Keyboard users reach only what is focusable, which native controls are by default. Styling cannot add a role: CSS can hide content from the tree, but a <div> styled as a button is still a generic node in it.

• Role: what kind of thing it is. It comes from the element (<button>, <h2>, <a href>), or as a last resort from an ARIA role attribute, which a later lesson covers.
• Name: what it is called. The browser computes it from the content, a <label>, an alt, a <caption> or ARIA attributes, in the fixed order of the accessible name computation.
• State and value: what it is doing now. Native elements keep these up to date for free: a checked <input type="checkbox">, a disabled <button>, the text typed into a <textarea>.

Headings, landmarks and lists: the structure users navigate by

Screen reader users rarely read a page from top to bottom. They open the headings list to see what the page contains, jump to the main landmark to skip the menu, and hear "list, four items" before a list so they know how much is coming. Each of those moves depends on one element having been used, and each has a precise check.

• Headings, <h1> to <h6>: one <h1> for the page topic, <h2> for its sections, <h3> inside them. A visual heading made of bold text in a <div> is missing from the headings list and fails 1.3.1; heading text that does not describe its section fails 2.4.6 Headings and Labels (Level AA). Skipped levels confuse users but are not a WCAG failure on their own, so report them with lower severity.
• Landmarks: at the top level of the page <header> maps to the banner role, <nav> to navigation, <main> to main, <aside> to complementary and <footer> to contentinfo. A <section> only becomes a region when it has a name, usually from aria-labelledby pointing at its heading or from aria-label. Landmarks let users skip the blocks repeated on every page, which is what 2.4.1 Bypass Blocks asks for. Check that the content sits inside <main> and that two <nav> elements carry different names, such as "Main menu" and "Footer links".
• Lists, <ul> and <ol>: a screen reader announces that a list begins and how many items it has. A menu built from <div> rows reads as unrelated lines of text, and an <ol> of checkout steps loses its order when it becomes divs. Styled bullets alone do not create a list.

Buttons, links, labels and tables: name, role and relationships

The second group is where 4.1.2 Name, Role, Value applies: every user interface component must expose its name, role, states and value to assistive technology. Native elements do this by default; replacements built from <div> or <span> do not, and the wrong native element is a defect too.

• Button or link: a <button> performs an action on this page (submit, open, delete) and is activated with Enter and Space; an <a href> goes somewhere and is activated with Enter. Screen readers announce the two differently and list links separately, so a <div onclick> acting as a button, or a link styled as a button that only runs a script, has a clear expected result: the native element for what it does. An <a> without href is not a link at all: it is not focusable, and its text is read as plain text, not as a link.
• Labels: a field’s name comes from a <label> whose for equals the field’s id, or from a <label> that wraps the field. The placeholder attribute is only a fallback in the name computation and its hint disappears as soon as the user types, so a field whose only label is a placeholder is a defect to report. A group of radio buttons or checkboxes takes its shared question from <fieldset> and <legend>; without them the user hears "Yes, radio button" with no idea what the question was.
• Tables: <table> is for data with rows and columns, with <th scope="col"> or <th scope="row"> for the headers and a <caption> for the title. The tree then links each data cell to its headers, so as the user moves from cell to cell a screen reader announces the header that changed, for example the column name before each value, and the user can move along a row or a column. A grid of <div> elements, or a table whose headers are bold <td> cells, loses these relationships and fails 1.3.1. The reverse mistake also exists: a <table> used for layout, which can announce meaningless rows and columns.

Worked example: the same checkout page in two markups

A front-end component library renders the checkout page as markup A below: apart from the input itself, every element is a <div> with a class, styled to look like a heading, a menu, a field label, a summary table and a button. The design review passes, because on screen it is indistinguishable from markup B, which uses one semantic element per structure.

Open both in the browser’s DevTools (right-click an element and choose Inspect; in Chrome and Edge the Accessibility tab, in the same row of tabs as Styles, shows the selected element’s role and computed name) and the difference is immediate. In A, "Checkout" is a generic node with text, so the headings list is empty; the menu is two generic items that Tab never reaches; the input has no name; "Total" and "600 SAR" are unrelated text; and "Place order" is a generic node that only a mouse can activate. In B the tree shows heading level 1 "Checkout", a navigation landmark holding a list of two links, a main landmark, a required textbox named "Postal code", a table in which "600 SAR" is linked to its row header "Total", and a button named "Place order" that Tab reaches and Enter or Space activates. Nothing changed visually; everything changed for assistive technology.

<!-- A: div soup -->
<div class="title">Checkout</div>
<div class="menu">
  <div class="item" onclick="go('/orders')">Orders</div>
  <div class="item" onclick="go('/addresses')">Addresses</div>
</div>
<div class="hint">Postal code</div>
<input class="zip">
<div class="row"><div class="cell">Total</div><div class="cell">600 SAR</div></div>
<div class="btn" onclick="pay()">Place order</div>

<!-- B: semantic HTML, identical on screen -->
<nav>
  <ul>
    <li><a href="/orders">Orders</a></li>
    <li><a href="/addresses">Addresses</a></li>
  </ul>
</nav>
<main>
  <h1>Checkout</h1>
  <form action="/orders" method="post">
    <label for="zip">Postal code</label>
    <input id="zip" name="zip" required>
    <table>
      <caption>Order summary</caption>
      <tr><th scope="row">Total</th><td>600 SAR</td></tr>
    </table>
    <button type="submit">Place order</button>
  </form>
</main>

Try it: HTML Formatter

Frequently asked questions

References

• Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024The W3C Recommendation that defines the testable success criteria for accessible web content, organised under four principles and three conformance levels (A, AA, AAA).
• HTML Living StandardWHATWGThe HTML language, including named character references (entities) and the parsing rules browsers follow.
• Accessible Name and Description Computation 1.2W3C · 2026How browsers compute the accessible name and description of an element from labels, ARIA attributes and content (a W3C Working Draft).
• Understanding WCAG 2.2W3C Web Accessibility Initiative (WAI)The informative explanation of each WCAG 2.2 guideline and success criterion: intent, who benefits, examples and techniques (not normative).