Open a random WordPress post and check its heading structure — chances are you’ll find an H2 skipped straight to an H4, or a page title formatted as an H3 because “it looked right” in the visual editor. It’s one of the most common accessibility mistakes on the web, and it’s also one of the easiest to explain: headings aren’t a font-size tool. They’re a table of contents that screen reader users rely on to understand and move through your page.
Sighted visitors skim a page visually — bold text, bigger fonts, and whitespace tell them where sections start and stop. Screen reader users don’t get that visual shortcut unless the underlying HTML gives them one. Heading hierarchy is how you give it to them.
Why Heading Structure Matters More Than It Looks
Screen readers let users pull up a list of every heading on a page and jump directly to the one they want, the same way you’d use a table of contents in a book. NVDA, JAWS, and VoiceOver all support this with a single keystroke. WebAIM’s survey research has consistently found that navigating by headings is one of the top ways screen reader users get around long pages — often preferred over scrolling or reading top to bottom.
That only works if your headings form a logical outline. If a page jumps from H2 to H4 with no H3 in between, screen reader users hear a gap and have to guess whether they skipped something or whether the site is just built inconsistently. If every heading on the page is an H2 regardless of importance, the “outline” is flat and tells them nothing about which sections are subsections of which.
This isn’t a minor inconvenience. WCAG 2.2’s Success Criterion 1.3.1 (Info and Relationships) requires that structural relationships conveyed visually — like “this is a subsection of that section” — also be conveyed programmatically. A heading that’s visually styled to look like a subsection but marked up as an H2 fails that criterion, even if a sighted user would never notice the problem.
The Rules, Simplified
You don’t need to memorize a spec to get this right. Three rules cover almost every real-world case:
- Use one H1 per page. It should describe what the page is about — usually your post or page title. Most WordPress themes already output the title as an H1 automatically, so you generally shouldn’t add a second one in your content.
- Don’t skip levels going down. An H2 can be followed by an H3, but not by an H4. If you want a heading to feel “smaller,” use CSS to style it — don’t jump levels to fake a visual effect.
- Nest by meaning, not by appearance. An H3 should be a subsection of the H2 above it, not just “a heading I wanted to look a certain size.” If a section isn’t logically a subsection of what came before it, it probably needs to be its own H2.
Going back up levels is fine — you can follow an H3 with a new H2 to start the next major section. The rule that trips people up is only about skipping levels on the way down.
Where This Breaks in WordPress Specifically
A few patterns show up over and over on WordPress sites, and most of them come from treating headings as a styling shortcut instead of a structural one.
Widgets and page builders styled by size, not level
Page builders make it trivially easy to drop in a heading block and just pick whatever level renders at the font size you want. That’s how a page ends up with an H2 for the hero title, an H5 for a pull quote below it because it “needed to be small,” and an H3 for the section after that. The visual hierarchy looks fine; the actual document outline is a mess.
Theme templates that hardcode heading levels
Some themes hardcode widget titles, related-post headings, or sidebar section titles as a fixed level — say, always H3 — regardless of where they land in the page’s outline. If your main content already uses H2s and H3s for its own structure, a sidebar widget that also outputs H3s can make the two structures collide and confuse the overall hierarchy.
Multiple H1s from theme plus content
This happens most often when a theme already renders the post title as an H1, and then the content itself includes a heading block set to “Heading 1” at the top, because a writer assumed that’s how you mark the “main” heading of the post. The result is two H1s on one page — not strictly forbidden by WCAG, but it undermines the “one H1 = this page’s main topic” convention that assistive tech and SEO tools both rely on.
How to Check Your Own Site
You don’t need a screen reader to audit heading structure, though it helps to spot-check with one eventually. A few faster methods:
- Use your browser’s accessibility tree or an outline extension. Tools like the HeadingsMap browser extension generate a visual outline of every heading on a page, in order, so skipped levels and duplicate H1s jump out immediately.
- Scan your key templates, not just individual posts. Check your homepage, a blog post, a product or service page, and any template with a sidebar or widgets — heading problems are often structural and repeat across every page using that template.
- Look at heading blocks in the WordPress editor. The block editor’s list view shows heading levels in outline form; scanning it before you publish catches a skipped level in seconds.
- Run an automated scan. Automated tools can reliably flag skipped heading levels and multiple H1s, though they can’t tell you whether a heading’s wording actually makes sense out of context — that part still needs a human read-through.
That last point matters: automated tools are good at catching structural violations — wrong levels, missing headings, duplicate H1s — but they can’t judge whether “Learn More” is a meaningful heading on its own. A screen reader user jumping straight to that heading via the headings list has no idea what it’s “more” about. Headings should make sense read in isolation, not just in the flow of the page around them.
Take Action
Heading structure is exactly the kind of issue that’s invisible until someone points it out — and exactly the kind of issue an overlay widget can’t fix, because it lives in your actual markup, not in a script bolted on after the fact. LEWCA’s WCAG scanner checks your WordPress site for skipped heading levels, duplicate H1s, and other structural problems, and flags the real code that needs to change. Pro adds AI-assisted fixes and scheduled scans so issues like this get caught before they pile up across dozens of pages. No tool can guarantee full compliance — but finding and fixing the actual problems in your markup is a lot more durable than masking them. See pricing or download LEWCA to get started.