Accessibility and Inclusive Content

Heading Structure Audit

Verify that page headings expose a meaningful hierarchy, label sections accurately, support navigation, and match visual relationships in the content.

Free editable Markdown · Accessibility testers, editors, and web teams · Updated July 30, 2026

Download Markdown

Accessible HTML preview

Blank template

The downloaded file contains the same fields in editable Markdown.

Page outline

Page URL and version: [Location/build]
Primary page subject: [One sentence]
Application shell heading: [If relevant]
Heading order source: [DOM inspection/tool/manual]
Assistive technology tested: [Name/version or Not tested]
Viewport/state: [Desktop, mobile, expanded, logged in]
Audit owner and date: [Name; YYYY-MM-DD]

Heading record

Sequence: [1, 2, 3]
Visible text: [Exact heading]
Semantic level: [H1–H6 or none]
Visual role: [Page title, section, subsection, card, decorative]
Content governed: [What follows]
Parent heading: [Expected relationship]
Issue: [Missing, vague, duplicate, wrong level, order, hidden]
Revision: [Text, level, component, or removal]

Audit checks

Main page subject is exposed as a meaningful heading.
Visual and semantic hierarchies describe the same relationships.
Heading levels represent nesting rather than font size.
Labels remain useful in a headings-only list.
Decorative text is not announced as a heading.
Dynamic components preserve logical order and state.
Keyboard and assistive navigation were tested where available.
Shared-component defects have regression coverage and ownership.

How to use this template

Capture the page purpose and extract every semantic heading in rendered DOM order.
Compare visual hierarchy, reading order, heading levels, and associated sections.
Review heading wording for specificity, uniqueness, and meaning out of context.
Test navigation with keyboard and relevant assistive technology, including dynamic components.
Fix page and component issues, then retest and assign regression ownership.

Extract the actual outline

List headings in DOM order with their level, visible text, component, and associated content. Compare this sequence with what a sighted reader perceives. A large styled sentence is not a heading unless marked semantically, while a semantic heading should label a section rather than serve as decorative typography. Identify the page's main subject and whether the heading structure begins at a sensible level for the application shell. Evaluate embedded widgets and repeated cards as part of the complete document.

Test labels and nesting

Read only the headings and ask whether the page purpose, major sections, and relationships remain understandable. Replace vague labels such as “More,” “Details,” or repeated “Learn more” headings with specific section names. Heading levels should represent hierarchy, not font size; a subsection belongs beneath its parent even if design calls for smaller styling. Avoid skipping levels when it obscures relationships, but do not invent empty headings solely to create a perfect numeric sequence.

Verify navigation in context

Use keyboard and assistive technology to navigate headings, checking announced text, order, hidden duplicates, and dynamic updates. Ensure modal, accordion, tab, and single-page application behavior exposes meaningful structure without cluttering the outline with inaccessible or collapsed content unexpectedly. After editing, review visual styles separately so semantic levels do not dictate undesirable design. Add regression checks to shared components when one defect affects many pages.

See the fields in context

Fictional example: gardening course page

Moss School is an invented site and the outlined defects are illustrative.

Finding: Every fictional course card uses an H2, while the card group itself has no heading and follows another H3.
Reader impact: The headings-only list makes each course appear unrelated to the “Autumn courses” section.
Revision: Add an H2 “Autumn gardening courses” and mark course titles H3 within the list.
Styling decision: Preserve existing card title size through CSS rather than choosing levels for appearance.
Retest: DOM outline, keyboard route, and screen-reader headings list now communicate the group relationship.

Frequently asked questions

Must every page have exactly one H1?

Use a clear main page heading and follow the conventions appropriate to your framework and document. The essential goal is an understandable, consistent hierarchy.

Is skipping a heading level always a failure?

It can obscure hierarchy and should be reviewed. Judge the actual relationship and applicable accessibility requirements rather than adding meaningless headings.

Can headings be visually hidden?

Sometimes a meaningful heading can support structure without a visual label, but hidden content must use an accessible technique and should be justified by the design.

Should card titles be headings?

Use headings when cards represent sections or navigable items in the content hierarchy. Do not mark every prominent label as a heading automatically.