Concepts

Heading hierarchy

Also: heading levels, heading structure, heading order

The structural use of `<h1>` through `<h6>` to convey content organisation. Screen-reader users navigate by heading; an incoherent hierarchy makes a page incoherent for them. WCAG 1.3.1 requires programmatic heading structure.

Heading hierarchy is the discipline of using <h1>-<h6> elements to form a consistent outline of a page’s content. Done right, it gives screen-reader users a free table of contents. Done wrong (skipped levels, decorative-only headings, multiple h1s, generic divs as headings) it makes the page incoherent for assistive-tech users.

The basic structure

<h1>Article title (one per page)</h1>
  <h2>Major section</h2>
    <h3>Sub-section</h3>
    <h3>Sub-section</h3>
  <h2>Major section</h2>
    <h3>Sub-section</h3>
      <h4>Sub-sub-section</h4>

The rules:

  1. One <h1> per page — the page’s primary title. Multiple h1s confuse screen readers about the page’s identity.
  2. No skipped levels descending. An <h2> can be followed by an <h3> (one level deeper) but not by an <h4> (two levels deeper). Skipping a level signals to a screen reader that something was missed in between.
  3. Headings reflect content structure, not visual styling. If a piece of text looks big but isn’t a heading of new content, use a styled paragraph, not a heading.
  4. No empty headings. <h2></h2> is meaningless. Either populate it or remove it.

Why screen readers care

The single most common screen-reader navigation operation is “jump to next heading” — the H key in JAWS and NVDA, the rotor “Headings” mode in VoiceOver, the headings reading-control in TalkBack.

A user opening a long article presses H repeatedly to get a sense of the article’s structure before reading any of it. If the headings are coherent, they get a free outline of the piece. If the headings are decorative-only or skip levels, they get noise.

What goes wrong in production

  • No <h1>. The page has no primary heading. Screen readers announce the page title from <title>, but the in-page heading navigation has no anchor. Common on poorly-structured CMS pages where the article title is drawn as styled text but never marked as <h1>.
  • Multiple <h1>s. “Hero title” + “first section title” both marked <h1>. Screen-reader users hear two h1s and can’t tell which is the page title.
  • Skipped levels. <h1><h3> because the design didn’t want <h2>-sized text. Screen-reader navigation reads “missing heading level.”
  • Divs styled as headings. <div class="hed-xl">Section title</div>. Screen reader gets no heading. Fix: use the correct <hN>, style with CSS.
  • Headings used for layout. Putting <h2> on a sidebar label so it looks like a heading visually, but the label is not a heading in content terms. Use a styled paragraph.

How to audit heading hierarchy

Three approaches:

  1. Screen-reader heading list. Open Insert+F7 in NVDA or VO+U → Headings. The displayed list should make sense as an outline of the page. If it doesn’t, fix the markup.
  2. HeadingsMap browser extension. Renders the page’s heading outline visually. Levels and gaps are immediately apparent.
  3. axe-core scan. Catches missing h1, skipped levels (in some configurations), and empty headings.

Why one h1 per page is a debated point

HTML5 originally suggested that nested <section> elements created their own heading scopes, allowing multiple <h1>s. Browsers and screen readers never implemented this behaviour. The W3C’s WCAG Working Group has reverted to “one h1 per page” as the operative guidance. Most modern style guides and accessibility audits enforce the one-h1 rule.