WCAG 2.4.10 Section Headings: Why Headings Matter for Website Accessibility

What WCAG 2.4.10 Section Headings requires

WCAG 2.4.10 Section Headings says page sections must have clear, descriptive headings so people can find and understand content fast. The guideline focuses on the text used for headings rather than their visual style. Good headings let people scan a page, jump to the part they need, and predict what will be in a section.

Who benefits and why headings matter

Semantic, descriptive headings help several groups:

• People using screen readers who move by headings to find content quickly.
• Keyboard users who need predictable landmarks for navigation.
• People with cognitive impairments who rely on short summaries to decide what to read.
• Anyone scanning a page on mobile or small screens.

How to write accessible section headings

• Make the heading a short summary of the section. Begin with the topic word.
• Avoid vague labels such as “More”, “Details” or “Click here”.
• Keep headings concise. One short sentence or a phrase is best.
• Use consistent casing and punctuation across the site.
• Include context where needed. For example write “Invoice settings” rather than “Settings” on an invoicing page.

Correct HTML implementation

Use semantic heading elements such as <h2> through <h6> to mark sections. Do not use styling alone to create the look of a heading. Screen readers and browser accessibility APIs rely on the element type, not the font size.

Heading levels and document structure

Choose heading levels to show hierarchy. Start with the top-level heading for the page and nest subsections under lower-level headings. Avoid jumping from an <h2> to an <h5> without intermediate levels unless a clear reason exists.

When to use WAI-ARIA headings

If you cannot use native heading elements, use role=“heading” and include aria-level to indicate its level. Only use this when semantic elements are not possible. Incorrect ARIA use can make content harder to navigate.

Testing section headings

Testing needs both automated checks and manual verification.

• Automated tools can confirm heading elements exist and are in the accessibility tree.
• Manual checks judge whether headings are descriptive. Use a screen reader to jump between headings and listen if each heading summarizes the following content.

Simple manual test you can run now

1. Open the page in a browser with the accessibility inspector or a screen reader.
2. List all headings in order. Most devtools show a heading outline.
3. For each heading, ask: does this heading preview the section that follows? If not, rewrite it.
4. With a screen reader, navigate by heading. Confirm you can jump to the section and understand purpose without reading the whole section.

Common mistakes and how to fix them

• Using bold or large text in a <div> instead of a heading element
  Fix: Replace the <div> with an appropriate <h*> element.
• Headings that are not descriptive
  Fix: Rewrite the heading to name the section topic, for example change “More info” to “Delivery options”.
• Duplicate headings that do not add context
  Fix: Add specific context, for example “Order history: 2024” instead of repeating “Order history”.
• Skipping heading levels without reason
  Fix: Use a logical sequence of levels to reflect structure or use ARIA with aria-level when needed.

Practical examples: wrong and right

Problem	Accessible heading
Visual look: “Account” in bold on top of the section but coded as a <div>	<h2>Account details</h2>
Heading says “More” near a list of payment methods	<h3>Saved payment methods</h3>
Two sections both called “Overview” with different content	<h2>Product overview <em>— pricing</em></h2> and <h2>Product overview <em>— technical specs</em></h2>

CMS and editorial checklist

• Always use the CMS heading tool to add a semantic heading element.
• Write headings that preview the section and contain unique context when reused.
• Ask authors to proof headings separately from body copy during content review.
• Train editors on when to use headings versus captions or labels.

When automated tests are not enough

Automated scans can flag missing heading elements. They cannot judge whether a heading actually helps a user. Manual testing with real headings navigation is required for full confidence.

Quick author-friendly checklist for WCAG 2.4.10

• Is there a semantic heading for each page section? Yes or no.
• Does each heading describe the content that follows? Yes or no.
• Are heading levels used to show structure? Yes or no.
• Are decorative visuals not used instead of headings? Yes or no.

If you fix those items you cover the practical parts of WCAG 2.4.10 Section Headings. Headings are a small change that improves navigation for many people. Make them descriptive, use real heading elements, and test with a screen reader.