WCAG 2.4.10: Section Headings
A three-thousand-word page with no headings is a wall of text for everyone — and a dead end for screen reader users who navigate by jumping between headings. This criterion asks that you use section headings to organize your content: break long material into logical sections, and start each one with a real, marked-up heading.
The success criterion, in full
Section headings are used to organize the content.
Two official notes scope this sentence. First, “heading” is used in its general sense — it includes titles and other ways of adding a heading to different types of content. Second, the criterion covers sections within writing, not user interface components; labeling UI components is handled by 4.1.2 Name, Role, Value.
Who this helps and why
Headings are the skeleton of a document. Sighted readers scan them to find the part they need; screen reader users press H (or a level number key) to jump section by section, or open the headings list to see the whole outline at once. Content without section headings offers neither group any handholds.
Screen reader users
Heading navigation is the single most-used exploration strategy in screen reader surveys. No headings means reading linearly through everything to find one paragraph.
People with cognitive disabilities
Sections with clear titles chunk information into manageable pieces and provide a visible map of the content, reducing memory and attention load.
Low-vision and magnification users
At high zoom, headings act as landmarks that make it possible to keep track of position within a long document seen one slice at a time.
Keyboard and switch users
Well-structured sections pair with skip links and landmarks (2.4.1 Bypass Blocks) so users can move past repeated material to the section they want.
What counts as a section
2.4.10 applies where the content is, by its nature, organized into parts. You are not required to invent sections in a short piece of writing that flows as a single unit — a three-paragraph news brief does not need three headings. But when distinct topics, stages, or groups exist, each should be introduced by a heading:
- Long-form articles and documentation — one heading per topic, subsections nested beneath.
- Multi-part policies and legal documents — each clause or chapter titled.
- Long forms — groups of related fields introduced by headings (in addition to fieldset/legend groupings).
- Step-by-step instructions — each step or phase marked with a heading so users can jump back to a specific step.
- Reference pages — one section per API method, per FAQ topic, per configuration area.
Out of scope: individual UI components (buttons, menus, dialogs have names, not section headings) and content that genuinely has no internal structure. The judgment call is “would a sighted editor naturally break this into titled parts?” If yes, assistive technology users need those parts marked as headings too.
The heading criteria, together
Three criteria form WCAG’s heading pipeline, and 2.4.10 is the top of it:
1.3.1 Info and Relationships — Level A
Anything that looks like a heading must be a heading in code (h1–h6), and vice versa. Bold, enlarged paragraph text styled as a title fails here.
2.4.6 Headings and Labels — Level AA
The headings you have must describe their topic or purpose. It is a quality bar for existing headings — it never requires adding one.
2.4.10 Section Headings — Level AAA
The presence requirement: content organized into sections must actually use headings to mark those sections. This is the criterion that says “add the headings.”
Satisfy all three and you get the full benefit: sections exist (2.4.10), they are exposed to assistive technology (1.3.1), and their titles are worth reading (2.4.6). 2.4.1 Bypass Blocks rounds out the set — a sound heading structure is itself a recognized technique for letting users skip repeated content.
Code examples
Break long content into headed sections
The core fix: where the writing has parts, each part starts with a heading element — not a styled paragraph.
<!-- ✗ A wall of text; 'headings' are just bold paragraphs -->
<article>
<p><strong>Shipping</strong></p>
<p>Orders ship within two business days…</p>
<p><strong>Returns</strong></p>
<p>You may return items within 30 days…</p>
</article>
<!-- ✓ Real headings organize the sections -->
<article>
<h1>Store policies</h1>
<h2>Shipping</h2>
<p>Orders ship within two business days…</p>
<h2>Returns</h2>
<p>You may return items within 30 days…</p>
</article>Keep the hierarchy logical
Heading levels communicate nesting. Choose the level by the document outline, never by font size — restyle with CSS instead.
<!-- ✗ Levels chosen for their default size -->
<h1>Setup guide</h1>
<h4>Install the CLI</h4> <!-- skipped to h4 for smaller text -->
<h4>Configure a project</h4>
<h2>Troubleshooting</h2> <!-- outline is now nonsense -->
<!-- ✓ Levels follow the structure; CSS handles the look -->
<h1>Setup guide</h1>
<h2>Install the CLI</h2>
<h3>macOS</h3>
<h3>Windows</h3>
<h2>Configure a project</h2>
<h2>Troubleshooting</h2>Head grouped areas of long forms
On long forms, headings and fieldset/legend work together: headings give jump targets, legends bind the group semantics to the fields.
<!-- ✓ Sections of a long checkout form -->
<h2>Shipping address</h2>
<fieldset>
<legend class="sr-only">Shipping address</legend>
<label for="ship-name">Full name</label>
<input id="ship-name" autocomplete="shipping name" />
…
</fieldset>
<h2>Payment details</h2>
<fieldset>
<legend class="sr-only">Payment details</legend>
…
</fieldset>Common failures
- Long articles, policies, or documentation published as unbroken text with no section headings at all.
- Visual 'headings' created with bold or enlarged text instead of h1–h6, which also fails 1.3.1 — the sections exist visually but not programmatically.
- Choosing heading levels for their default font size, producing an outline (h1 → h4 → h2) that misrepresents the structure.
- Multi-page documents where only the first page has a title and subsequent sections run on without headings.
- Long settings or profile pages where distinct groups of options share one generic heading or none.
- Marking things up as headings that are not section titles — taglines, pull quotes, or every card title on a dashboard — which pollutes the outline users navigate by.
- Hiding all headings visually because the design 'doesn't need them', leaving screen reader users an outline the sighted team never reviews.
How to test for 2.4.10
- 1
Identify the content's natural sections
Read the page as an editor: where do topics, stages, or groups change? Note each place a sighted reader would expect a title. This is your expected outline.
- 2
Extract the actual heading outline
Use a screen reader's headings list, the browser accessibility tree, or a headings extension to dump every h1–h6 with its level. Compare it against the expected outline from step 1.
- 3
Check every section start has a heading
Any section boundary you identified that lacks a heading element is a 2.4.10 gap — including sections whose 'title' is only a bold paragraph (log that against 1.3.1 too).
- 4
Verify the hierarchy reads sensibly
In the outline, subsections should nest under their parents without skipped levels, and there should be a single h1 naming the page. Navigate by heading with a screen reader and confirm jumping section-to-section actually works.
- 5
Confirm heading text is descriptive
While you have the outline open, apply the 2.4.6 check: each heading read in isolation should say what its section contains. Presence (2.4.10) and quality (2.4.6) are tested in one pass.
The Heading Analyzer extracts a page’s full outline for review in seconds, and the WCAG 2.2 checklist covers the neighbouring structure criteria.
Frequently asked questions
What does WCAG 2.4.10 Section Headings require?
It requires that section headings are used to organize the content. Where content is structured into sections — chapters of a document, steps of a process, groups of settings, regions of a long article — each section should begin with a heading that identifies it. It is a Level AAA success criterion under Guideline 2.4 Navigable, introduced in WCAG 2.0. Unlike 2.4.6, which governs the quality of headings you already have, 2.4.10 is about actually providing headings to structure the content.
Does 2.4.10 apply to every part of a web page, including UI components?
No. The W3C's notes on this criterion say 'heading' is used in its general sense — titles and other ways of marking sections — and that the criterion covers sections within writing, not user interface components. A dialog, a menu, or a toolbar is a UI component, and labeling those is covered by 4.1.2 Name, Role, Value. 2.4.10 is aimed at prose and document-like content: long articles, documentation, policies, forms with grouped areas of content, and similar material.
How is 2.4.10 different from 2.4.6 Headings and Labels?
They are complementary quality and presence requirements. 2.4.6 (Level AA) says that whatever headings exist must describe their topic or purpose — it never requires you to add a heading. 2.4.10 (Level AAA) is the presence requirement: where the content is organized into sections, headings must actually be used to mark those sections. A page with zero headings can pass 2.4.6 and fail 2.4.10; a page full of headings named 'Section 1', 'Section 2' passes 2.4.10's structure expectation but fails 2.4.6's descriptiveness bar.
How does 2.4.10 relate to 1.3.1 Info and Relationships?
1.3.1 (Level A) requires that anything visually presented as a heading is marked up as a real heading (h1–h6 or role="heading") so assistive technology can perceive the structure. 2.4.10 requires that the sections of your content have headings at all. In practice you satisfy them together: break long content into logical sections (2.4.10), give each section a heading whose markup matches its visual role (1.3.1), and write heading text that describes the section (2.4.6).
Do heading levels have to be nested without skipping to pass 2.4.10?
Strictly, no — 2.4.10 requires headings to organize content, and neither it nor any other criterion normatively forbids skipping from an h2 to an h4. But a coherent hierarchy is the whole point of organizing with headings: screen reader users navigate by level, and a skipped level implies a subsection that does not exist. Treat a logical, unskipped hierarchy with a single h1 as the standard implementation of 2.4.10, and reserve deviations for cases where the document structure genuinely demands it.
Is 2.4.10 required for legal compliance?
Usually not directly — most legislation (ADA settlements, Section 508, the European Accessibility Act via EN 301 549) references WCAG Level AA, and 2.4.10 is Level AAA. However, pages with well-organized section headings are dramatically easier to navigate for screen reader users, benefit SEO through clear document outlines, and largely fall out for free if you already write structured content. It is one of the cheapest AAA criteria to meet, which is why many organizations adopt it as an internal standard anyway.
Related Success Criteria
A mechanism is available to bypass blocks of content that are repeated.
Web pages have titles that describe topic or purpose.
Focusable components receive focus in an order that preserves meaning.
The purpose of each link can be determined from link text or context.
More than one way is available to locate a page within a set of pages.