Free WCAG Heading Checker

What is a WCAG heading checker?

A WCAG heading checker validates that the heading elements on a web page (h1, h2, h3, h4, h5, h6) form a logical hierarchy that screen readers and other assistive technologies can navigate. Headings are how blind and low-vision users skim a page: they use a screen reader shortcut to jump heading-to-heading, building a mental table of contents in seconds. If the headings are missing, out of order, or used decoratively, that navigation collapses. WCAG 2.2 Success Criterion 1.3.1 (Info and Relationships) and 2.4.6 (Headings and Labels) require headings to convey structure correctly.

The rules are simple to state and easy to violate. There should be exactly one h1 per page (the page title). Each subsequent heading should be at most one level deeper than its parent (an h2 can be followed by another h2 or by an h3, but not directly by an h4). Headings should not be empty. Heading levels should describe the document structure, not the visual size (do not use h4 just because you want smaller text). Most accessibility audits flag heading-hierarchy issues as the first thing to fix because they are common, easy to verify, and high-impact for screen reader users.

This tool parses HTML you paste in (no upload, no server round-trip), walks the heading elements in document order, and reports the issues: missing h1, multiple h1s, skipped levels, empty headings, and an outline of the page structure. The output is plain text describing each problem. Run it on any page during development, before launch, or as part of a regular accessibility audit cycle. The output is plain-language, not a numeric score; the goal is to give you specific issues to fix, not a passing grade to chase.

What is inside the tool

The top of the page is a textarea where you paste your HTML. You can paste a complete document (DOCTYPE, html, head, body) or a fragment (just the body content). The tool extracts all h1 through h6 elements in document order using a standard browser DOMParser, so the parsing matches what a real browser would do. The textarea handles input of any size; very large documents (tens of thousands of lines) work but take a fraction of a second longer to parse.

Click Check Headings and the results appear below. The first section is the heading outline: every heading in order, indented by level, so you can read the structure as a table of contents. The second section is the issues list: each problem with its specific location, what is wrong, and a brief explanation of why it matters. Issues are categorised by severity: errors (must fix for WCAG compliance) and warnings (best practice but not strict failures).

The output stays in the browser; nothing is uploaded. You can paste the same HTML many times with edits in between to iterate on fixes. The tool intentionally does not check anything outside heading structure (it does not verify alt text, contrast, focus order, ARIA, or any other WCAG criterion). For those, use this tool alongside a comprehensive audit tool like axe DevTools, Lighthouse, or WAVE.

History and background

HTML headings since the beginning (1991)

Tim Berners-Lee introduced HTML in 1991 with h1 through h6 elements as part of the original 18 tags. The original semantic intent was always document structure, not visual styling. The Web's hierarchy of headings comes from a much older tradition: print documents (books, papers, government reports) have used numbered section levels for centuries to convey structure. HTML inherited that model directly. Despite 35 years of stable semantics, heading misuse is one of the most common accessibility bugs on the modern web because designers often style by visual size first and check structure second.

Screen readers learn to navigate by heading (1996 onwards)

JAWS (Job Access With Speech) was released by Henter-Joyce in 1989 and added Web-page heading navigation as the Web grew popular through the late 1990s. Pressing the H key in JAWS jumps to the next heading; numbered keys 1 through 6 jump to that specific heading level. Every major screen reader since (NVDA in 2006, VoiceOver in 2005, TalkBack on Android) has copied this shortcut. WebAIM's annual Screen Reader User Survey consistently finds that 67 to 70 percent of screen reader users navigate by headings as their primary method for understanding a page. Broken heading hierarchy is therefore not a cosmetic issue.

WCAG 1.0 and the rise of accessibility standards (1999)

The Web Content Accessibility Guidelines 1.0 were published by W3C in May 1999, the first international standard for Web accessibility. WCAG 1.0 explicitly required headings to be used for document structure (Checkpoint 3.5). WCAG 2.0 (2008) refined this into Success Criterion 1.3.1 (Info and Relationships, Level A) and 2.4.6 (Headings and Labels, Level AA). WCAG 2.1 (2018) and 2.2 (2023) kept these criteria unchanged because the underlying requirement is sound. Most accessibility laws around the world (ADA in the US, EAA in Europe, AODA in Ontario) now cite WCAG 2.1 AA as the legal baseline.

HTML5 sectioning and the document outline (2014)

HTML5 (W3C Recommendation 2014) introduced sectioning elements (article, section, nav, aside) and an outline algorithm that was supposed to derive heading hierarchy from nesting depth. The algorithm was never implemented in any browser or screen reader and was formally deprecated in 2022. The practical guidance is: use explicit heading levels (h1 through h6) and treat sectioning elements as semantic grouping, not as a substitute for heading depth. The HTML Living Standard now states clearly that heading levels must be set explicitly.

ARIA roles and aria-level (2014 onwards)

WAI-ARIA 1.1 (W3C Recommendation 2017) provides role="heading" with aria-level="N" as an alternative way to mark headings, useful when you cannot use the native h1-h6 elements (for example, in a framework component that needs to render different heading levels in different contexts). Screen readers treat role="heading" identically to the native element. Best practice is to use native elements where possible; use ARIA only when the native semantics are unavailable. This tool checks both native heading elements and elements with role="heading".

Accessibility lawsuits and the business case (2017 onwards)

Domino's Pizza v. Robles (US Supreme Court 2019) established that the Americans with Disabilities Act (ADA, 1990) applies to commercial websites. Hundreds of similar lawsuits have followed each year (over 4,000 ADA web suits filed in 2024 alone). The European Accessibility Act (EAA, in force June 2025) makes WCAG-equivalent accessibility a legal requirement for most consumer-facing websites across the EU. Failed heading structure is one of the easiest issues for plaintiffs to identify and document, which makes basic heading checks a high-leverage compliance step.

Practical workflows

Pre-launch check on new pages and templates

Before any new page or template ships, run the HTML through this checker. Heading-structure issues are the easiest accessibility bugs to introduce (especially in CMS-driven content where editors choose heading levels based on visual size) and the easiest to fix. Catching them before launch is much cheaper than after, when fixes require coordination with content owners. For agencies, build this check into the QA checklist; for in-house teams, run it as part of code review or before merging to main.

Auditing an existing site for accessibility compliance

For an accessibility audit (pre-litigation, EAA compliance, contract requirement), step through the most-trafficked pages and run each one's HTML through this checker. Document the findings: which pages have heading issues, what type, how to fix. Combine with axe DevTools or Lighthouse for the other WCAG criteria. The heading-structure findings are usually the easiest to remediate and form a solid quick-win section of the audit report.

CMS editor training and templating

CMS-driven content (WordPress, Drupal, Contentful, Sanity) often gives editors a heading dropdown with H1 through H6 options. Editors who do not know the rules choose levels by visual size. Demo this checker to editors so they can see what their heading choices produce. For templates, run the rendered output through the checker after each design change to confirm the editor's heading choices still produce valid hierarchy. Many CMS plugins exist that warn editors at write-time; this tool serves the verification step.

Validating email templates and HTML newsletters

HTML emails read by screen readers should follow the same heading hierarchy as web pages. Run your email template's HTML through this checker before sending to a large list. Common email-template issues: multiple h1s (when each section has its own headline), missing h1 (when the layout starts with h2 directly), and decorative h4s used purely for small headings. Fix these before sending; assistive-tech users on your list will notice.

Validating PDF-to-HTML conversions

When you convert PDFs to HTML for accessibility (so they can be read by screen readers with heading navigation), the converter has to map PDF structure tags to HTML heading levels. The result is often broken: PDFs without proper tagging produce flat HTML with no headings at all, and even tagged PDFs sometimes produce all-h1 or all-h2 output. Run the converted HTML through this checker to spot the issue before publishing the converted page.

Onboarding new developers and designers

Junior front-end developers and designers benefit from seeing concrete examples of broken heading hierarchy and the resulting screen reader experience. Pair this tool with a screen reader demo (NVDA on Windows is free, VoiceOver on Mac is built-in) to show how headings drive screen reader navigation. The connection between abstract heading rules and concrete user experience is often what makes the lesson stick.

Common pitfalls

Choosing heading level by visual size

The most common mistake: using an h4 because you want smaller text, or skipping from h2 to h4 because there is no h3 sized correctly in the design. Heading levels are structural, not visual; use CSS to control the size and use the level that matches the document hierarchy. If your design system does not have a visual style for every needed level, add one (or override with class names) rather than picking the wrong level.

Multiple h1s per page

A page should have exactly one h1 representing the page title. Common bugs: a site logo wrapped in h1 plus an article title also in h1 (two h1s), a homepage with each hero section using h1 (multiple h1s), or no h1 at all because the layout starts with h2. The fix is structural: pick the most important content on the page as the single h1 and demote everything else to h2 or below. Tools like axe and Lighthouse warn on multiple h1s for this reason.

Skipped heading levels

Going from h2 directly to h4 breaks the document outline. Screen reader users moving heading-to-heading expect each h4 to be nested under an h3, and the missing h3 confuses the structure. The fix is to insert the missing intermediate level or to demote the h4 to h3. Most common cause is copying design from a mockup where the visual hierarchy uses three sizes but the design system uses four heading levels; recheck after every component update.

Empty headings

An h2 with no text content (often because a JavaScript widget removed the text but kept the element) appears in the screen reader's heading list as an unlabelled heading, which is confusing and useless. Either populate the heading with text, or remove the heading element entirely. This is common in single-page apps where placeholder elements are rendered before data loads; render the heading only when there is content to put in it.

Headings inside non-semantic wrappers

A heading wrapped in a div with role="presentation" or aria-hidden="true" is removed from the accessibility tree, which can hide an otherwise-correct heading from screen readers. Audit the parent elements of every heading to make sure they do not strip the heading from the accessibility tree. CSS display:none and visibility:hidden also remove the heading; only use these intentionally and never on content that should be screen-reader-visible.

Using ARIA when native HTML would do

Adding role="heading" aria-level="2" to a div instead of using an h2 element works for accessibility but is unnecessary complexity. Native h1-h6 elements get heading semantics for free, render correctly in default browser styles, and survive screen reader bugs better than ARIA overrides. The first rule of ARIA (per WAI-ARIA Authoring Practices) is: do not use ARIA when native HTML provides the same semantics. Use native heading elements unless a framework constraint genuinely forces ARIA.

Privacy and data handling

The HTML you paste stays in your browser throughout the check. The DOMParser that extracts the headings runs in JavaScript on your machine; the results are rendered in the page below the textarea. There is no upload step, no remote processing, and no telemetry about what HTML you pasted. This matters because the HTML you most want to check (pre-launch templates, client sites under NDA, internal admin pages) is exactly what you should not paste into a third-party SaaS validator.

Once the page is loaded, the tool works offline. You can disconnect from the internet, paste HTML, run the check, and review the results without your markup ever touching another machine. Most cloud accessibility checkers (PowerMapper, Tenon, Site Improve) require uploading the page URL or HTML; for confidential pages that is precisely the failure mode to avoid.

When not to use this tool

For full WCAG audits (use a comprehensive tool)

Heading structure is one of dozens of WCAG criteria. For a complete audit, use axe DevTools (free Chrome/Firefox extension from Deque), Lighthouse (built into Chrome), WAVE (WebAIM's free tool), or a paid solution like Tenon or PowerMapper. These check colour contrast, alt text, ARIA usage, form labels, focus order, and many more. Run this tool alongside, not instead of, the comprehensive ones.

For dynamic content (test the rendered DOM)

If your headings are generated by JavaScript (React, Vue, Svelte, Angular), the static HTML source does not contain the final headings. You need to paste the rendered DOM after JavaScript runs. Use the browser DevTools: open the page, open DevTools, Elements tab, right-click the body or main, Copy outerHTML, then paste that into this checker. Or use a browser extension that walks the live DOM directly.

For automated CI/CD pipelines (use a Node library)

If you want heading checks to run automatically on every commit or pull request, integrate axe-core, Pa11y, or jest-axe into your test suite. They run heading checks (and many other WCAG checks) headlessly in CI. This browser tool is for interactive use during development and review, not for automation. Both have their place; use the browser tool for one-off audits and the CI library for continuous validation.

For PDF or Word document accessibility

PDFs and Word documents have their own accessibility tagging systems (PDF/UA, the Word heading styles). They do not use HTML headings, so this tool does not apply. For PDF accessibility, use Adobe Acrobat Pro's Accessibility Checker or PAC 2024 (free, PDF/UA-focused). For Word, use the built-in Accessibility Checker (Review tab). Convert to HTML first if you want to use this tool, but the conversion itself can introduce heading issues.

More questions

Is it ever OK to skip a heading level?

Not in straight document content. WCAG 2.2 SC 1.3.1 implies headings should form a hierarchical sequence. The one common case where it looks like a skip is the page outline starting at h1 then h2 inside the main content area, while a sidebar or navigation also has h2s; that is fine because both are siblings under the page's h1. The actual rule is: do not skip levels within a contiguous content flow. The checker flags only true skips.

What if my framework only supports one heading level?

Some component libraries render headings at a fixed level (always h2, regardless of nesting). The fix is to expose a level prop on the heading component (h2, h3, etc.) and have parents pass the appropriate value. Frameworks like React commonly do this; if yours does not, add an aria-level on the component and use role="heading" as a temporary workaround until you can refactor. Long-term, every reusable heading component should accept a level prop.

Does the tool check ARIA roles like role="heading"?

Yes. Any element with role="heading" and a valid aria-level attribute (1 through 6) is treated as a heading at the indicated level. Native h1-h6 elements are always preferred, but ARIA-marked headings are equally valid for screen readers and are checked alongside the native ones.

How important is heading hierarchy compared to other WCAG criteria?

Very. WebAIM's annual Screen Reader User Survey consistently finds that 67-70% of screen reader users navigate by headings as their primary way to understand a page. Bad headings effectively block one of the main accessibility navigation methods. In WebAIM's WebAIM Million annual analysis, heading issues are among the top five most common accessibility failures across the web. The combination of high user impact and easy detection makes them a top priority.

Should every page have an h1?

Yes, with rare exceptions. Every full HTML document should have exactly one h1 that represents the page title. The exception is fragments that are explicitly inserted into a larger page (an email signature, a widget embedded in another page); the host page provides the h1 and the fragment starts at h2 or lower. For standalone pages, missing h1 is a clear accessibility failure.

Can I trust this tool for legal compliance audits?

For heading-structure specifically, yes: the rules are precise and the tool implements them accurately. For overall WCAG compliance, no single automated tool is sufficient; manual testing with assistive technology, expert review, and user testing with disabled users are required for legal-grade audits. Use this tool as one of several inputs to your audit, not as the sole source of truth for compliance.