Semantic HTML & Accessibility Basics
Why semantics matter beyond styling — ARIA basics, accessible forms, and how screen readers and search engines actually read your page.
Why Semantic Tags Matter — For More Than Just Tidy Code
By this point in the track you have already used <header>, <nav>, <main>, <section>, <article>, <aside>, and <footer> — semantic tags that describe what a piece of content is, not just how it should look. It is tempting to think of the difference between these and a generic <div> as purely stylistic — after all, a <nav> and a <div class="nav"> can be made to look pixel-identical with CSS. This module is about the part of the story that has nothing to do with appearance at all: semantic tags are read directly by software other than a rendering engine — screen readers, browser extensions, search engine crawlers, and browser built-in features like Reader Mode — and each of those depends on the tag actually being correct, not merely styled to look correct.
<!-- Version A — looks fine, means nothing to assistive technology -->
<div class="nav">
<div class="nav-item"><a href="/">Home</a></div>
<div class="nav-item"><a href="/about">About</a></div>
</div>
<!-- Version B — identical appearance with the right CSS, but this
is machine-readable structure, not just visual grouping -->
<nav>
<ul>
<li><a href="/">Home</a></li>
<li><a href="/about">About</a></li>
</ul>
</nav>Both versions render identically once styled. The difference only becomes visible the moment something other than a sighted user with a mouse tries to use the page — which, across a real, large user base, is a meaningfully large fraction of visitors, and is also legally significant in many jurisdictions (covered further in Part 07).
How Screen Readers Actually Use Landmark Navigation
Semantic elements like <header>, <nav>, <main>, <aside>, and <footer> are called landmarks in accessibility terminology. Screen readers (VoiceOver on macOS/iOS, NVDA and JAWS on Windows, TalkBack on Android) build a navigable list of every landmark on the page, and expose a dedicated keyboard shortcut that lets a user jump directly between them — without needing to listen to every single line of content in between.
<header>...</header> → Landmark: "banner"
<nav>...</nav> → Landmark: "navigation"
<main> → Landmark: "main"
<article>...</article> → Landmark: "article"
<aside>...</aside> → Landmark: "complementary"
</main>
<footer>...</footer> → Landmark: "content info"
<!-- A VoiceOver or NVDA user can press a single key combination to
jump straight from "banner" to "main", skipping the entire
navigation menu — every single time, on every page that uses this
structure, without the site author writing a single line of extra code. -->This is precisely the accessibility equivalent of a sighted user visually scanning a page and immediately recognizing "that block at the top is the header, that block down there is the footer" without reading every word — landmarks give a non-visual user the exact same fast, skippable structure, but only if the underlying tags are the correct semantic ones rather than generic <div>s.
The "skip to main content" link — landmark navigation's visible cousin
A related, very common pattern is a "Skip to main content" link placed as the very first focusable element on the page, visually hidden until it receives keyboard focus. This exists for keyboard-only users (not necessarily screen reader users — someone using a keyboard due to a motor impairment, or simply preference, benefits from this too) who would otherwise need to tab through an entire navigation menu on every single page before reaching the actual content.
<body>
<a href="#main-content" class="skip-link">Skip to main content</a>
<header>...</header>
<nav>...</nav>
<main id="main-content">
...
</main>
</body>
<style>
.skip-link {
position: absolute;
top: -40px; /* off-screen by default */
left: 0;
background: #000;
color: #fff;
padding: 8px 16px;
z-index: 100;
}
.skip-link:focus {
top: 0; /* snaps into view the instant it receives keyboard focus */
}
</style>A <main> landmark with an id serves as this link's target, which is one more reason a page should have exactly one <main> — multiple instances confuse both this pattern and the landmark-jumping behavior described above.
Basic ARIA Roles — For When Semantic HTML Alone Isn't Enough
ARIA (Accessible Rich Internet Applications) is a set of attributes that add accessibility information HTML cannot express on its own — most often needed for custom interactive widgets that have no native HTML equivalent, like a tab panel, a modal dialog, or a custom dropdown built from <div>s and JavaScript rather than a native <select>. The single most important rule of ARIA, stated in the official spec itself, is worth internalizing before anything else:
<button> is already keyboard-focusable, already announces itself as "button" to a screen reader, and already responds to Enter and Space — none of that has to be reconstructed with ARIA. ARIA should be reached for only when no native element covers the pattern you need, not as a default habit.<!-- A custom-built tab interface, made of divs, needs explicit roles
since <div> carries no semantic meaning of its own -->
<div role="tablist">
<div role="tab" aria-selected="true">Overview</div>
<div role="tab" aria-selected="false">Reviews</div>
<div role="tab" aria-selected="false">Shipping</div>
</div>
<div role="tabpanel">
Overview content goes here...
</div>Common roles you will genuinely see in production codebases include role="alert" (for content that should be announced immediately, like a form validation error), role="dialog" (for a modal), and role="button" — the last of which is almost always a code smell, since it usually means a <div> or <span> is being made to behave like a button with JavaScript, when a real <button> would have needed no role at all.
<div role="alert" id="form-error">
Please enter a valid email address.
</div>
<!-- role="alert" causes screen readers to announce this text
IMMEDIATELY when it appears in the DOM, without the user
needing to navigate to it manually — appropriate specifically
for urgent, time-sensitive messages like this one. --><nav> already has an implicit role of navigation, <button> already has an implicit role of button. Explicit role attributes exist to cover the gap where no native element fits, not to duplicate what semantic HTML already provides for free.aria-label, aria-labelledby, and aria-describedby
aria-label provides an accessible name for an element directly, as a string, overriding whatever text content the element would otherwise be announced with. It is most commonly needed on icon-only buttons — a trash-can icon with no visible text has nothing for a screen reader to announce unless something explicitly supplies a name.
<!-- Without aria-label, a screen reader announces this as
just "button" — completely unhelpful -->
<button>
<svg><!-- trash can icon --></svg>
</button>
<!-- With aria-label, it announces as "Delete item, button" -->
<button aria-label="Delete item">
<svg><!-- trash can icon --></svg>
</button>aria-labelledby — pointing to existing visible text instead of duplicating it
When the accessible name should come from text that is already visible elsewhere on the page, aria-labelledby references that element's id rather than repeating the string — useful because it keeps a single source of truth; if the visible text changes, the accessible name updates automatically along with it.
<h2 id="billing-heading">Billing Information</h2>
<section aria-labelledby="billing-heading">
<!-- This section is announced as "Billing Information" without
repeating that string anywhere in an aria-label -->
...
</section>aria-describedby — supplementary description, not a replacement name
aria-describedby is subtly different — it adds extra descriptive text after an element's accessible name is announced, rather than replacing that name. It is the standard pattern for connecting a form field to its own helper text or error message.
<label for="password">Password</label>
<input type="password" id="password" aria-describedby="password-hint">
<p id="password-hint">Must be at least 12 characters, with one number.</p>
<!-- A screen reader announces: "Password, edit text, protected.
Must be at least 12 characters, with one number." -->Alt Text — What Actually Makes It Good or Bad
You met the alt attribute in the Images and Media module as a required attribute on every <img>. This module goes further: not every non-empty string is good alt text, and the difference between good and bad alt text is entirely about whether it conveys the same information or purpose the image conveys to a sighted user — not about literally describing every visual detail.
<!-- Failure 1: describes pixels, not purpose -->
<img src="chart.png" alt="a blue and orange bar chart">
<!-- Failure 2: redundant filler that adds no information -->
<img src="ceo.jpg" alt="image of the CEO">
<!-- Failure 3: keyword-stuffed for SEO, unreadable as a sentence -->
<img src="shoes.jpg" alt="running shoes sneakers athletic shoes buy shoes online cheap shoes">
<!-- Failure 4: empty when the image is actually meaningful content -->
<img src="warning-icon.png" alt=""><!-- Fix 1: describes what the chart actually communicates -->
<img src="chart.png" alt="Quarterly revenue grew 34% from Q1 to Q4 2025">
<!-- Fix 2: no filler — a screen reader already announces "image" itself -->
<img src="ceo.jpg" alt="Maria Chen, CEO of Norwell Robotics">
<!-- Fix 3: reads as a natural sentence, describing the actual product -->
<img src="shoes.jpg" alt="Men's blue running shoes with reflective trim">
<!-- Fix 4: a meaningful icon gets meaningful alt text, not an empty string -->
<img src="warning-icon.png" alt="Warning: this action cannot be undone">Fix 2 demonstrates a rule worth calling out explicitly: never begin alt text with phrases like "image of" or "picture of." Screen readers already announce that the element is an image before reading the alt text itself, so prefixing it produces an announcement like "image, image of the CEO" — redundant, and a real, common mistake even among people who genuinely intend to write good alt text.
When alt="" is actually the correct choice — purely decorative images
Failure 4 above was wrong specifically because that icon was meaningful. A genuinely decorative image — a background flourish, a repeated visual divider that adds no information — should have alt="" (present, but empty) so a screen reader skips it entirely rather than interrupting the page's content with a description of something that carries no meaning. An empty alt is a deliberate, correct signal, not a shortcut or an oversight, and it is meaningfully different from omitting the alt attribute altogether — which some screen readers instead read aloud as the full image filename.
Accessible Forms — Tying Back to the Forms Modules
The previous two modules covered form controls in depth without dwelling on accessibility specifically — this section closes that loop, connecting patterns you have already learned back to exactly why they matter for a non-sighted or keyboard-only user.
<!-- Inaccessible — placeholder is not a label, and disappears once typing starts -->
<input type="email" placeholder="Email address">
<!-- Accessible — a real <label>, connected via matching for/id -->
<label for="email">Email address</label>
<input type="email" id="email">A screen reader announces a properly connected label the instant a user tabs into the field — "Email address, edit text." A placeholder-only input, once the user starts typing, leaves a screen reader user with genuinely no way to recall what the field was even for, since the placeholder text itself is never announced as a label at all in most screen readers, and disappears visually the moment there is real input.
The <fieldset>/<legend> pattern from the previous module is itself an accessibility feature, not just visual grouping — recall from Part 02 of that module that a screen reader announces the legend before every control nested inside, giving a user navigating a long form the same "which section am I in" context a sighted user gets for free from the visual box around the group. And the aria-describedby pattern from Part 04 of this module is precisely how you should connect a field to helper text or a validation error message — an error message that only appears in red text next to a field, with no aria-describedby connecting it, is entirely invisible to a screen reader user who has no way to know it exists.
<label for="email">Email address</label>
<input type="email" id="email" aria-describedby="email-error" aria-invalid="true">
<p id="email-error" role="alert">Please enter a valid email address.</p>aria-invalid="true" additionally flags the field itself as currently failing validation, and role="alert" (from Part 03) ensures the error text is announced immediately rather than requiring the user to navigate to it manually.
"Div Soup" — Why It Fails Real Users, Not Just SEO
"Div soup" is the (somewhat derisive) term for markup built almost entirely out of <div> and <span>, with classes doing all the work that semantic tags should be doing. Most discussion of this problem focuses on search engine optimization — and it is true that search engines weight semantic structure when ranking pages — but that framing badly undersells the actual harm, which is to real people using real assistive technology, right now, regardless of how a page ranks in search results.
<div class="header">
<div class="logo">Acme Co</div>
<div class="nav">
<div class="nav-item" onclick="location.href='/'">Home</div>
<div class="nav-item" onclick="location.href='/pricing'">Pricing</div>
</div>
</div>
<div class="main">
<div class="title">Welcome</div>
<div class="button" onclick="submitForm()">Submit</div>
</div>Walk through what a screen reader user actually experiences with this markup, point by point. There is no <header>, <nav>, or <main> landmark, so the "jump between sections" navigation from Part 02 has nothing to jump to — the entire page is one undifferentiated block of content that must be read start to finish. Every <div class="nav-item"> is announced as plain, unremarkable text, not as a link — because it is not a link; it is a div with an onclick handler, which is entirely invisible to keyboard navigation and to a screen reader's "list all the links on this page" feature. The <div class="title"> is not a heading, so it does not appear in the "jump between headings" navigation either, even though visually it clearly reads as one. And the <div class="button"> is not keyboard-focusable at all by default, meaning a keyboard-only user — again, not necessarily a screen reader user — cannot Tab to it or activate it with Enter or Space, full stop.
<header>
<div class="logo">Acme Co</div>
<nav>
<a href="/">Home</a>
<a href="/pricing">Pricing</a>
</nav>
</header>
<main>
<h1>Welcome</h1>
<button type="submit">Submit</button>
</main>A further, less obvious cost: div soup with no semantic structure also produces a genuinely worse experience for Reader Mode (in Safari, Firefox, and Chrome), for browser translation features, and for any tool — including AI-driven ones — that tries to programmatically extract the "real" content of a page from its markup. Semantic structure is, in a real sense, an API your HTML exposes to every piece of software that isn't a human looking at rendered pixels.
An Accessibility Audit at an Austin Healthcare Startup
A patient-portal startup is weeks from launch when a legal requirement surfaces: as a healthcare provider, the product must meet WCAG 2.1 AA accessibility standards, both because it is the right thing to do and because non-compliance carries real legal exposure under the ADA for a company handling patient data. An external accessibility auditor is brought in to review the appointment-booking flow before launch.
<div class="page">
<div class="topbar">
<div class="logo">MedLink</div>
<div class="menu-item" onclick="goTo('/appointments')">Appointments</div>
<div class="menu-item" onclick="goTo('/messages')">Messages</div>
</div>
<div class="content">
<div class="page-title">Book an Appointment</div>
<div class="field">
<input type="text" placeholder="Reason for visit">
</div>
<img src="doctor-photo.jpg">
<div class="submit-btn" onclick="bookAppointment()">Confirm Booking</div>
</div>
</div>The audit's findings
The auditor's report reads almost like a checklist against this exact module. No landmarks (Part 02) — a screen reader user has no way to jump past the top bar to the actual booking content. Navigation built from div.menu-item with onclick instead of real <a> tags (Part 07) — completely unreachable by keyboard, and invisible to a screen reader's link list. A placeholder standing in for a real <label> on the reason-for-visit field (Part 06) — the field's purpose disappears the instant a patient starts typing. A missing alt attribute entirely on the doctor's photo, not even an empty one (Part 05) — most screen readers fall back to reading the raw filename, doctor-photo.jpg, aloud to the patient. And a div.submit-btn standing in for a real <button>, unreachable by keyboard entirely — meaning a keyboard-only user cannot complete a booking at all.
<div class="page">
<header>
<div class="logo">MedLink</div>
<nav>
<a href="/appointments">Appointments</a>
<a href="/messages">Messages</a>
</nav>
</header>
<main>
<h1>Book an Appointment</h1>
<div class="field">
<label for="reason">Reason for visit</label>
<input type="text" id="reason" placeholder="e.g. Annual checkup">
</div>
<img src="doctor-photo.jpg" alt="Dr. Elena Ruiz, Family Medicine">
<button type="submit">Confirm Booking</button>
</main>
</div>None of these fixes changed a single pixel of the rendered page — the CSS classes and visual design were untouched. The team ships on schedule, the audit is cleared, and the engineering lead adds an automated axe-core accessibility scan to the CI pipeline specifically so this exact class of issue is caught on every future pull request, not only at a pre-launch audit.
Four Misconceptions About Accessibility
6 Interview Questions — With Complete Answers
Accessibility Mistakes Beginners Make Constantly
Errors and Audit Failures You Will Hit With Accessibility
🎯 Key Takeaways
- ✓Semantic tags are read by more than a rendering engine — screen readers, browser extensions, search crawlers, and Reader Mode all depend on the tag being genuinely correct, not merely styled to look correct.
- ✓Landmark elements (header, nav, main, aside, footer) let screen reader users jump directly between page regions with a keyboard shortcut, exactly like a sighted user visually scanning a layout.
- ✓The First Rule of ARIA: use a native HTML element with the behavior you need before reaching for role and other ARIA attributes to recreate that behavior manually.
- ✓aria-label supplies an accessible name directly; aria-labelledby points to existing visible text for that name; aria-describedby adds supplementary description after the name, commonly used for form hints and errors.
- ✓Good alt text conveys meaning or purpose, phrased as a natural sentence, without "image of" prefixes. alt="" is the correct, deliberate choice for purely decorative images — it is not a mistake.
- ✓A placeholder is never a substitute for a real, connected <label> — it disappears once typing starts and is not reliably announced as a label at all by most screen readers.
- ✓Div soup fails real keyboard-only and screen-reader users directly, not just search rankings — unreachable "links" and "buttons," missing landmarks, and missing heading structure are all invisible in a normal sighted visual review.
- ✓Nearly every accessibility fix changes only the underlying markup, not the rendered visual design — accessibility and visual design are largely independent axes, not a tradeoff against each other.
What comes next
Module 11 opens Phase 2 of the HTML track with a survey of HTML5's browser-facing APIs — custom data-* attributes and the JavaScript dataset property that reads them, the contenteditable attribute, and the native drag-and-drop API.
Module 11 → HTML5 APIs OverviewDiscussion
0Have a better approach? Found something outdated? Share it — your knowledge helps everyone learning here.