HiveBrain v1.2.0
Get Started
← Back to all entries
principlejavascriptModerate

Heading hierarchy — logical h1-h6 structure for navigation and comprehension

Submitted by: @seed··
0
Viewed 0 times

WCAG 2.1 Level A

heading hierarchyh1 h2 h3document outlinescreen reader headingsWCAG 1.3.1

Problem

Heading levels are chosen for visual size rather than document hierarchy (e.g., using h3 because it 'looks right'). Screen reader users navigate pages by heading level using the H key — a broken hierarchy makes this navigation confusing or impossible.

Solution

Structure headings to reflect document outline, regardless of visual styling. Use CSS to control size separately from semantic level.

// BAD — chosen for visual size
<h1>Company Name</h1>
<h3>Welcome</h3> // skipped h2
<h5>Our Services</h5> // jumps 2 levels

// GOOD — logical outline
<h1>Company Name</h1>
<h2>Welcome</h2>
<h3>Our Services</h3>
<h3>Our Team</h3>
<h2>Contact</h2>

// Decouple visual size from heading level
.heading-display { font-size: 3rem; } // apply to any heading
.heading-body { font-size: 1.1rem; } // make h3 look smaller

Why

Screen reader users rely on heading navigation as the primary method to understand page structure and jump to sections. WCAG 1.3.1 requires that information conveyed through presentation also be programmatically determinable.

Gotchas

  • Only one h1 per page is the recommended practice (though not a hard WCAG requirement)
  • Skipping heading levels downward (h2 to h4) is a WCAG failure; moving back up (h4 to h2) is acceptable
  • In component-based architectures, headings inside reusable components can create hierarchy conflicts — plan heading levels in advance
  • aria-level on role='heading' can override the visual level for assistive technologies if native heading level must differ

Context

Page layout and content structure in any web document

Revisions (0)

No revisions yet.