January 19, 2021 · reala11y team

Why Heading Order Matters for Screen Readers

Skipped heading levels break screen-reader navigation. Here's why H1–H6 order matters and how to fix a broken outline in WordPress.

Screen reader users rarely read a web page top to bottom. They navigate it the way a sighted visitor scans it — by jumping between landmarks. One of the most-used shortcuts in NVDA, JAWS, and VoiceOver is “jump to next heading.” When your headings are in a sensible order, that shortcut turns a long page into a usable table of contents. When they are not, it turns it into a maze.

If your WordPress theme or content has a broken heading outline, you are quietly making that maze harder for the people most dependent on structure.

What “heading order” actually means

WCAG 2.2 (a W3C Recommendation since 5 October 2023) treats headings as part of information and relationships — success criterion 1.3.1. The rule is not “use headings.” It is “use them to express the real structure of the page, in code, not just visually.”

In practice that means:

• Exactly one <h1> that names the page (in WordPress, usually the post or page title).
• Heading levels that descend by one at a time — an <h2> section, then <h3> subsections under it.
• No skipped levels: an <h2> followed directly by an <h4> is a gap a screen reader announces as missing structure.
• Headings used for structure, never because the theme renders <h3> at a font size you happen to like.

A screen reader exposes this outline as a list. A heading that jumps from level 2 to level 4 reads as “heading level 4” with nothing at level 3 — the listener has no idea whether they missed a section.

Why it matters more than it looks

Visually, a skipped level is invisible. The page looks fine. That is exactly why broken outlines survive for years: nobody sees the problem, so nobody fixes it.

But for a screen reader user, the heading list is the page map. A broken outline costs them:

• Orientation — “Where am I in this document?” becomes guesswork.
• Speed — they can no longer trust heading navigation, so they fall back to reading linearly.
• Confidence — repeated structural surprises train people to distrust your site.

This is also one of the more common issues automated tools can reliably catch. Heading-order problems are deterministic and visible in the markup, which is why a scanner is genuinely useful here — more so than for judgment calls like whether alt text is good.

How broken outlines happen in WordPress

A few usual suspects:

• Theme templates that wrap a site title or widget heading in <h1> or <h2>, competing with your post title.
• Page builders (Elementor, Divi, and friends) that expose a heading dropdown and let editors pick any level for visual reasons.
• Pasted content from Word or Google Docs that carries its own heading levels.
• Block patterns that ship with an <h3> as the first heading, skipping <h2> entirely.

The common thread: heading level gets chosen for appearance, not meaning.

How to fix a broken outline

1. See the current outline

Before changing anything, look at the real structure. A headings-list browser extension, your screen reader’s element list, or a scanner that reports heading order will all show you the actual hierarchy your markup produces — not the one you assume it has.

2. Fix the meaning, then the style

Decide the correct level for each heading based on where it sits in the document. Then, if a correctly-leveled heading looks wrong, change its appearance with CSS or a block style — never demote the heading level to get a smaller font.

In the block editor you can change a heading’s level without touching its text: select the block and use the H1–H6 control in the toolbar.

3. Keep one H1

Confirm your template renders exactly one <h1> per view. If both the site title and the post title are <h1>, that is a template decision — fix it in the theme, not in every post.

4. Re-scan and confirm

After editing, run the page through your checker again. A clean outline should descend one level at a time with no gaps.

This is the kind of code-level issue reala11y is built to surface. Its scanner flags heading-hierarchy problems (rule R004, mapped to WCAG 1.3.1) and empty headings (R020) directly in the editor, so you fix the markup at the source rather than papering over it. It is not an overlay widget — there is no floating script reordering things for visitors. You can read more about that approach on how it works, and the underlying criterion is covered in our WCAG 2.2 guide.

The honest takeaway

Heading order is one of the few accessibility issues that is both high-impact for screen reader users and reliably machine-detectable — so it is worth fixing well. But detecting a clean outline is not the same as a usable one: a scanner can confirm your levels descend correctly, yet it cannot tell you whether each heading actually describes the section beneath it. That part is human work.

Automated tooling, including ours, typically surfaces 30–40% of WCAG issues by criteria. Fix the heading outline, then read the page the way a screen reader user would — and you will catch what no tool can.