Heading Structure Analyser
Visualise H1–H6 hierarchy, detect skipped levels, flag missing H1s, and score your document outline.
- 1Choose your input method — Select 'Scan URL' to fetch a live page (enter the full URL including https://), or 'Paste HTML' to analyse a snippet directly.
- 2Run the scan — Click 'Analyse'. The tool fetches the page via a proxy and extracts all heading tags (H1–H6).
- 3Read the tree — The indented hierarchy shows your heading structure. Red flags indicate problems: missing H1, skipped levels (e.g. H2 → H4), or empty headings.
- 4Fix the issues — Each flagged heading shows the specific problem. Ensure you have exactly one H1 per page, and that levels increase by one at a time without skipping.
Need Batch Analysis?
Pro: scan up to 50 URLs simultaneously and export a full CSV audit report.
Why heading structure is a legal requirement
SC 1.3.1 — Info and Relationships
Level A — most fundamental requirement
What it requires
The visual heading hierarchy must be conveyed programmatically — meaning it must exist in the HTML, not just look like a heading through CSS.
This is a Level A criterion, the most basic tier of WCAG compliance. It is required by every accessibility law globally, including the EAA, ADA, and Section 508. 'Programmatically conveyed' means using real <h1>–<h6> elements, not <div> or <span> styled to look like headings. A screen reader cannot detect visual styling — it reads the HTML structure. If your heading hierarchy exists only visually, it is invisible to assistive technology.
Real-world impact
A marketing team might style a <div> in a large bold font to look like a heading. Sighted users see a heading. Screen reader users hear a paragraph. They cannot navigate to it using heading keys and do not know a new section has started. This is one of the most common accessibility failures found in EAA and WCAG audits.
SC 2.4.6 — Headings and Labels
Level AA — required by EAA, ADA, Section 508
What it requires
Headings must describe the topic or purpose of the content that follows them — they cannot be vague, empty, or misleading.
SC 2.4.6 goes beyond just having headings in the right HTML elements — it requires them to be meaningful. A heading that says 'Section 1' or contains only punctuation fails this criterion even if the element is technically an <h2>. The heading must tell a user navigating by headings what they will find if they read further. This is the criterion that catches empty headings, symbol-only headings, and headings that do not describe their section.
Real-world impact
A screen reader user navigating by headings is building a mental map of the page — like skimming a table of contents. If every heading says 'Read more' or 'Section', the map is useless. They have to read the full content of every section sequentially, which is exactly the barrier that heading navigation is designed to remove. EAA auditors will cite SC 2.4.6 when headings are present but not descriptive.
SC 2.4.10 — Section Headings
Level AAA — best practice, not required by most laws
What it requires
Section headings should be used to organise content — meaning content-heavy pages should use headings to break up and label sections.
This AAA criterion is not required by the EAA or ADA, but it represents the ideal. It means that even if headings are technically correct, a page that presents a wall of text without any heading structure is harder to navigate. Best practice for any content-heavy page is to use headings to divide content into labelled sections, so that users can orient themselves and jump to what they need.
Real-world impact
A legal terms page with 5,000 words and no sub-headings is technically compliant at AA, but extremely difficult to navigate for screen reader users and users with cognitive disabilities. Adding H2 and H3 headings to organise sections (Delivery, Returns, Privacy) lets users jump directly to the relevant section rather than reading everything.
Important Legal Disclaimer
This tool is a self-assessment aid only and does not constitute legal advice or a formally certified compliance assessment. Outputs — including reports, scores, checklists, and accessibility statements — are for internal use and should be reviewed by a qualified legal representative or independent accessibility auditor before being relied upon for regulatory, procurement, or public-disclosure purposes. All assessment risk lies with the internal assessor. accessibilityref, its developers, and staff accept zero liability for losses arising from use of or reliance on these outputs. Always verify against official sources: the W3C WCAG 2.2 Recommendation, the European Accessibility Act (Directive 2019/882), and your national enforcement authority.