On each web page, is the information structured by the appropriate use of headings?
A screen reader user arriving on a long page has a valuable option: navigate from heading to heading with the H key. In a few seconds, they scan the document structure without listening to all the content. This only works if headings exist and are properly marked up.
This criterion requires three checks. Headings must be marked with <hx> elements (from <h1> to <h6>) or with role="heading" accompanied by aria-level. Their hierarchy must be consistent: no jump from <h1> directly to <h3> without an intermediate <h2>. And each heading must describe the section it introduces, not just fill the page layout.
Without heading structure, the page becomes an opaque block for blind people, deaf people browsing headlines to spot content of interest, and people with cognitive disabilities who need semantic landmarks. Three different profiles, same need: readable architecture.
The most common pitfall in audits: <h2> or <h3> placed for their visual rendering, without semantic intent. A "Download document" button marked as <h2> because it makes it larger: this is a classic mistake that breaks heading navigation and creates false landmarks in the page outline.
3 tests to ensure that the hierarchy of headings is consistent
Hierarchy of headings <hx>
- Identify all headings on the page:
<h1>to<h6>tags, and elements withrole="heading". - Reconstruct the document outline (using a tool like HeadingsMap or Web Developer → View Document Outline).
- Verify that the hierarchy is consistent: no unjustified level jumps (e.g., an
<h4>after an<h2>without an intermediate<h3>must be justified). - Test is valid if the structure reflects the logical organization of content.
Relevance of heading content
- Revisit the list of headings identified in test 9.1.1.
- For each heading, read its text: does it clearly describe the section that follows?
- A vague heading ("Learn more", "Section 1", "Click here") or too generic fails the test.
- Test is valid if each heading clearly announces the content of its section.
Semantic markup of headings
- For each heading identified in test 9.1.1, inspect the HTML code.
- The heading must use one of these two forms:
- A native tag:
<h1>,<h2>,<h3>,<h4>,<h5>or<h6>. - Or an element with
role="heading"ANDaria-level="x"(x being an integer).
- A native tag:
- Text visually styled as a heading via CSS, without these tags, fails the test.
- Test is valid if each heading uses one of the two mechanisms above.
Examples
❌ Non-compliant : Level jump and tag misused
<h1>Our services</h1>
<h3>RGAA training</h3>
<p>Learn accessibility criteria.</p>
<h2><a href="/contact">Contact us</a></h2>Two cumulative issues. The jump from <h1> to <h3> without <h2> breaks hierarchy: the screen reader announces "level 3 heading" right after "level 1 heading", disorienting the user. The <h2> around the "Contact us" link introduces no content section: it's an action link marked as a heading only for its visual rendering, creating a false landmark in the page outline.
✅ Compliant : Coherent hierarchy and descriptive headings
<h1>Our services</h1>
<h2>Training</h2>
<h3>RGAA training</h3>
<p>Learn accessibility criteria.</p>
<h3>WCAG training</h3>
<p>Master international standards.</p>
<h2>Accessibility audit</h2>
<p>Verification of your site's compliance.</p>The h1 → h2 → h3 hierarchy is continuous and logical. Each heading describes the section it introduces. A user navigating by headings immediately understands the content structure without listening to paragraphs.
✅ Compliant : ARIA heading on a custom component
<div role="heading" aria-level="2">Form accessibility</div>
<p>Fields must have visible and programmatic labels.</p>When a technical constraint requires a <div> instead of an <h2>, the role="heading" and aria-level="2" combination conveys the same semantics to assistive technologies. This form complies with test 9.1.3, but always prefer the native <h2> tag when possible.
Tips and pitfalls
⚠️ The <hx> used as a styling tool
Marking a link or button with <h2> to apply the visual style of a heading is the most frequent audit error. The screen reader announces a heading where the user expects a content section. Navigation by headings becomes misleading. If you need the style, apply a CSS class to the semantically correct tag (<a>, <button>) rather than misusing <hx>.
⚠️ Text visually styled as a heading but marked as <p> or <div>
A <p> in bold and large font, styled like a heading via CSS, is not a heading to assistive technologies. The screen reader reads it as an ordinary paragraph, without announcing it as a navigation point. Simple rule: if an element plays the role of a heading on the page, mark it as such.
💡 Audit the document outline in 10 seconds
In Firefox with the Web Developer extension, go to Information → View Document Outline. On Chrome, HeadingsMap displays the full hierarchy in a sidebar panel. If the outline looks like a chaotic list of mixed levels, criterion 9.1 is almost certainly failing.
⚠️ Skipping a level is not systematically non-compliant
The RGAA requires that hierarchy be "relevant", not strictly continuous. An <h4> after an <h2> can be justified if the block is embedded from a third-party component with its own internal hierarchy. On a fully controlled page, any unjustified skip should be corrected.
⚠️ Multiple <h1> on the same page
The recommendation of a single <h1> per page is a best practice, not a RGAA 4.1 requirement. What is required: consistent hierarchy and relevant headings. Multiple <h1> can be justified on a page composed of independent articles (feed, aggregator), where each <article> has its own main heading.
Frequently asked questions
Why avoid skipping heading levels according to RGAA?
Rarely justified. RGAA requires a relevant hierarchy. A jump from <h2> to <h4> without <h3> disorients screen reader users who expect to find an intermediate level. If the jump is imposed by an unmodifiable third-party component, document the reason in your audit. On a controlled page, correct it.
What is the mandatory role of <h1> in RGAA structure?
RGAA does not explicitly require it, but its absence will be flagged in virtually all audits. Without it, the main entry point of the page is missing, disorienting screen reader users upon arrival. In practice, always provide an <h1> that describes the page subject.
How do I audit RGAA criterion 9.1 headings on a SPA?
Check heading structure after each view change, not just on initial load. In a SPA, content being dynamically injected, headings can disappear or duplicate. Use the accessibility tree in DevTools or HeadingsMap after navigation to validate the actual DOM state. Test 9.1 covers the final render, not static source HTML.
What is the difference between <h2> and role="heading" aria-level="2" in RGAA?
Semantically equivalent for assistive technologies. In practice, always prefer <h2>: shorter, more robust, no extra attributes required. role="heading" with aria-level is reserved for cases where a component generates a non-heading element (a <div> or <span>) that is technically impossible to replace with a native tag.
What impact do CSS-hidden headings have on RGAA hierarchy?
Yes, if it remains accessible to assistive technologies. A heading hidden with the "visually hidden" technique (clip, position off-screen) is announced by screen readers and must therefore integrate coherently into the hierarchy. Conversely, display: none and visibility: hidden render the element invisible to all, including screen readers, and it no longer counts.