Heading Structure for Screen Readers: A Practical Guide

Nobody reads web pages. People skim them. A sighted visitor lands on a page, and their eyes bounce around it in under a second, hitting the big bold phrases, building a rough map of what’s here and whether any of it matters to them. This skimming is so fast and so automatic that we forget it’s happening, and we certainly forget that it depends entirely on vision. Take the vision away and the map is gone. The page becomes a corridor: you can walk forward through it, one element at a time, but you can’t see over the walls.

Headings are how HTML gives the map back. The tags h1 through h6 aren’t styling instructions; they’re an outline, the same structure you’d see in a book’s table of contents. And screen readers treat them exactly that way. A screen reader user arriving on a page will very often press a single key that jumps to the next heading, or pull up a list of every heading on the page and pick from it. This is their version of the one-second visual bounce. It’s how a blind user skims. Which means your heading structure isn’t a detail of your page. For a meaningful set of visitors, it is the page, the first and sometimes only representation of it they engage with.

Now consider what that experience is like on a typical site. The heading list might read: the company name, then “Untitled,” then a marketing slogan marked up as three separate headings because each line needed different styling, then nothing for the entire main content, then “Sign up for our newsletter.” That’s the map. Imagine handing a sighted user a table of contents like that. The failure is invisible to everyone who builds the site, because visually the page looks fine; the actual content has big bold text, it’s just big bold text made with styled paragraph tags instead of heading tags. To eyes, indistinguishable. To the outline, nonexistent.

The root mistake is treating heading levels as font sizes. Browsers do render h1 bigger than h3 by default, so developers reach for whichever tag looks right, and the outline becomes a record of aesthetic decisions instead of structure. The mental shift that fixes everything is to pick the level by logic and set the size with CSS. The h1 is the answer to “what is this page about,” and there should be one, containing the page’s actual subject rather than the company name that’s already in the logo. The h2s are the page’s major sections. Inside a section, subsections get h3, and so on down. Any heading’s level should be answerable by asking what it’s a subdivision of, not by asking how big it should look.

Skipping levels, jumping from an h1 straight to an h4, is the other common defect. It’s not catastrophic, and screen readers cope, but it makes the outline lie. A listener who hears an h4 reasonably assumes there’s an enclosing h3 and h2 they might have missed, and may go hunting for structure that doesn’t exist. Think of levels like directories: you wouldn’t nest a folder four levels deep with nothing in the levels between. The order flows h1, then h2, deeper as the content actually nests, back up when a new section starts.

The reverse mistake matters too: making things headings because you want them big. Pull quotes, taglines, prices, calls to action get wrapped in heading tags for the free visual weight, and each one injects a phantom entry into the outline. A screen reader user jumping through headings lands on “Only $49!” and has learned nothing about where they are. If text isn’t a section title, it isn’t a heading, however large it deserves to be. CSS can make any element any size; that’s what it’s for.

Checking your own site takes ten minutes and no special skill. Every major browser’s developer tools will show you the document structure, and free browser extensions will extract the heading outline directly. Or do it the honest way: open a page, list its headings, hide everything else, and ask whether a stranger reading only that list could say what the page is about and find the section they need. That question is the whole test. It’s the same question an editor would ask about a book’s table of contents.

I gave GazeSite’s audits a check for exactly this, missing h1s, skipped levels, decorative headings, because heading structure is among the most mechanical things to detect and among the most consequential to get wrong. But the reason I care about it is bigger than any single check. Headings are where the two audiences of a web page, the ones who see and the ones who listen, make the same demand in different forms. Both are asking: what’s here, and in what order, and what matters most. A good outline answers before they finish asking. Write the outline first, honestly, and the page underneath it tends to come out better organized too, because you can’t fake a clear structure in a list of six phrases. That’s not an accessibility trick. That’s just writing.