Accessible Headings and Page Structure: A Practical WCAG Guide

Accessible headings are real heading elements, <h1> through <h6>, that describe the section that follows them and sit in a logical outline. Text that only looks like a heading because it's big and bold doesn't count. Pair those headings with landmarks (<header>, <nav>, <main>, <footer>) and a page title that says what the page is, and you have most of what WCAG asks for on page structure.

This matters because headings are how many screen reader users read a page. In WebAIM's Screen Reader User Survey #11 (1,780 respondents, July to August 2026), 67.8% said navigating by headings is how they first try to find information on a long page, and 88.3% found heading levels very or somewhat useful.

Below, we separate the WCAG requirements from the habits that are good practice but not rules, show how heading navigation works in practice, and walk through a before-and-after rebuild of a typical service page.

What WCAG requires for headings and page structure

No single success criterion is called "headings". The requirements are spread across five criteria, and all of them were already in WCAG 2.0, so they apply under the AODA's WCAG 2.0 Level AA baseline as well as WCAG 2.2. Our summary of AODA requirements and deadlines covers who has to meet that baseline.

Two details are easy to miss. First, 2.4.6 does not require you to add headings. The W3C's Understanding document for 2.4.6 says it only requires that the headings you do have are descriptive. The requirement to use headings at all is the AAA criterion 2.4.10. Second, 1.3.1 does the heavy lifting in practice: once you visually present something as a heading, it has to be marked up as one.

How screen reader users navigate by headings

Picture a long page read aloud from top to bottom, navigation menu included, with no way to glance ahead. Headings are the way around that. On a desktop screen reader, users typically:

• Press H to jump to the next heading (NVDA and JAWS in browse mode), or 1 to 6 to jump to the next heading at that level.
• Open a list of every heading on the page (NVDA's Elements List with NVDA+F7, JAWS's Headings List with Insert+F6, or the VoiceOver rotor on a Mac or iPhone) and pick one.
• Press D or R, depending on the screen reader, to move between landmarks.

That headings list is the clearest test of your structure. If the list reads like a table of contents, users can find what they need. If it shows "Read more" six times, or skips the section they want because it was styled as bold text, they're back to listening to the whole page. Our screen reader testing guide walks through checking this yourself.

Rules for accessible headings

Use real heading elements, not styled text

A <p class="title"> or <div class="section-heading"> looks like a heading to sighted users and is invisible as one to everyone else. Use <h1> to <h6>. If your CMS has a "Heading 2" option in its editor, use that rather than bolding a line and bumping the font size. If you truly can't change the element, role="heading" with aria-level works, but it's a fallback, not a first choice.

Choose the level by structure, then style it with CSS

The most common structural mistake we see is choosing a heading level for its size. A sidebar heading becomes an <h5> because the design wanted it small, or a section heading becomes an <h1> because it was meant to look big. Pick the level that reflects where the section sits in the outline, then make it look however the design needs:

<h2 class="heading-small">Related services</h2>

.heading-small {
  font-size: 1rem;
  text-transform: uppercase;
  letter-spacing: 0.05em;
}

One H1 per page: good practice, not a WCAG rule

WCAG doesn't limit how many <h1> elements a page can have, and HTML allows more than one. A single <h1> that names the page's main topic is still the convention we recommend, because it gives screen reader users a reliable landing point: press 1 and you're at the start of the content. The usual problem isn't two H1s, it's the wrong one, such as the site logo wrapped in an <h1> on every page while the actual page title is an <h2>.

Don't skip heading levels (best practice)

Jumping from an <h2> straight to an <h4> isn't a WCAG failure on its own, but it makes users wonder whether they missed a section. Go down one level at a time. Going back up is fine: an <h4> can be followed by an <h2> when a new major section starts.

Write headings that describe the section

This is the 2.4.6 part. Someone scanning only the headings list should know what each section covers.

Vague: "Overview", "More info", "Learn more"
Descriptive: "What the AODA requires", "Booking a site visit", "Pricing for multi-location clinics"

Don't use headings for things that aren't headings

The reverse problem also creates noise. A pull quote, a bold call-to-action line or a testimonial author's name shouldn't be a heading just to get bigger text. And watch for empty headings left behind by page builders. They show up in the headings list as blank entries.

Before and after: fixing a page outline

Here's a pattern we see often on small-business sites built with page builders. Visually, the page looks well organized. Structurally, it isn't.

<div class="header">
  <h1><img src="logo.svg" alt="Example Dental"></h1>
  <div class="menu">...</div>
</div>
<div class="content">
  <p class="big-title">Family dentistry in Mississauga</p>
  <h4>Our services</h4>
  <h2>Book online in two minutes</h2>
  <h4>Cleanings and checkups</h4>
  <p><strong>Emergency appointments</strong></p>
</div>
<div class="footer">...</div>

The logo is the only <h1>, the real page title is a paragraph, a promotional line is an <h2> because it was meant to stand out, and one service is bold text that never appears in the headings list. There are no landmarks either. Here's the same page rebuilt:

<header>
  <a href="/"><img src="logo.svg" alt="Example Dental home"></a>
  <nav aria-label="Primary">...</nav>
</header>
<main>
  <h1>Family dentistry in Mississauga</h1>
  <p class="promo">Book online in two minutes.</p>
  <h2>Our services</h2>
  <h3>Cleanings and checkups</h3>
  <h3>Emergency appointments</h3>
  <h2>Visit us</h2>
</main>
<footer>
  <nav aria-label="Footer">...</nav>
</footer>

The headings list now reads like a table of contents:

H1  Family dentistry in Mississauga
    H2  Our services
        H3  Cleanings and checkups
        H3  Emergency appointments
    H2  Visit us

Nothing about the visual design has to change. The promo line can keep its large type through CSS, and the service headings can stay the same size they were.

Landmarks: the other half of page structure

Headings outline the content. Landmarks mark out the regions of the page, so a screen reader user can jump straight to the main content or the footer. HTML elements give you most of them without any ARIA:

• <header> becomes the banner landmark when it's the page-level header (not when it's inside an <article> or <section>).
• <nav> is a navigation landmark.
• <main> holds the page's primary content. Use one per page.
• <footer> becomes the contentinfo landmark at page level.
• <aside> is complementary content, such as a related links panel.
• <section> and <form> only become landmarks when they have an accessible name, for example through aria-labelledby pointing at their heading.

Label repeated landmarks

When a page has more than one <nav>, give each a short aria-label such as "Primary", "Footer" or "Breadcrumb". Leave the word "navigation" out of the label, since screen readers already announce the landmark type and you'd get "Primary navigation navigation". Keep landmarks few and meaningful: wrapping every block in a named <section> just adds noise. If you're reaching for ARIA roles to fix structure, our ARIA best practices guide explains when native HTML is the better choice.

Add a skip link

Landmarks help screen reader users, but sighted keyboard users can't use them. A "Skip to main content" link as the first focusable element, visible when it receives focus, covers them. It's one of the first things we check in a keyboard accessibility review.

Page titles: the first thing a screen reader announces

The <title> element is announced when a page loads and is what users see in browser tabs, bookmarks and history. Success criterion 2.4.2 asks that it describe the page's topic or purpose. Put the specific part first, so the useful words come before the repeated site name:

Weak: "Example Dental | Home | Services"
Better: "Emergency appointments | Example Dental"

On single-page apps built with React, Angular or Vue, confirm the title changes on every route change. A title that stays "Home" across the whole app is a common failure that automated scans can miss, because each scanned URL might load correctly on its own.

Heading structure, accessibility and SEO

Good heading structure helps search too, but be precise about how. Google's SEO Starter Guide says headings in semantic order are "fantastic for screen readers" but that, from Google Search's perspective, it doesn't matter if they're out of order. Where accessibility and SEO genuinely overlap is in the words: descriptive headings and a clear, specific page title help searchers and screen reader users decide whether the page is what they want. Google uses the <title> and headings among its sources for the title shown in results. Fix structure for your users, and the search benefit comes with it.

How to check your heading structure

An automated tool can flag empty headings, missing page titles, skipped levels and a missing <main>. Our free accessibility scan reports these. What a tool can't judge is whether a heading describes its section, or whether bold text should have been a heading. That takes a person. A quick manual check:

1. Open a headings outline, either with a browser extension that lists headings or with a screen reader's headings list.
2. Read only the headings. Do they make sense as a table of contents?
3. Look at the page. Is anything styled as a heading missing from the list?
4. Check that each template has one <main> and labelled navs.
5. Check the page title in the browser tab on every template, including after navigation.

Page structure checklist

• Every visual heading is a real <h1>–<h6>.
• Heading levels follow the outline, not the font size.
• One <h1> names the page's main topic.
• Levels go down one step at a time.
• Headings describe their sections; no "More info" or empty headings.
• Header, nav, main and footer landmarks are present; multiple navs are labelled.
• A visible-on-focus skip link reaches the main content.
• Every page has a unique, descriptive <title>, specific part first.

Frequently asked questions