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:
- One
<h1>per page — the page’s primary title. Multiple h1s confuse screen readers about the page’s identity. - 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. - 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.
- 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:
- Screen-reader heading list. Open
Insert+F7in NVDA or VO+U → Headings. The displayed list should make sense as an outline of the page. If it doesn’t, fix the markup. - HeadingsMap browser extension. Renders the page’s heading outline visually. Levels and gaps are immediately apparent.
- 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.