Headings, landmarks and screen readers

A screen reader user very often navigates a page by jumping between headings with a single keystroke, similar to how a sighted user visually scans a page for the section they want. This only works if headings are marked up as genuine document structure, not simply styled to look larger or bolder. It also needs that structure to follow a logical, nested order.

Why “it looks like a heading” is not the same as “it is a heading”

Text made large and bold using visual styling alone looks identical to a sighted user. That holds true even if it was never marked up as an actual heading element in the underlying code. But it is invisible to a screen reader’s heading-navigation feature. It reads as plain paragraph text, indistinguishable from anything else on the page. This is one of the most common accessibility failures on ordinary business sites. It is a visually correct result that silently fails the structural requirement underneath.

The correct heading order and heading level structure, and why skipping heading levels breaks it

Headings are meant to nest logically: one top-level heading per page, with subsections underneath it in order, without skipping levels. A heading two levels down should not appear before its parent one level up exists. Skipping levels for purely visual reasons — choosing a smaller heading tag just because it “looks right” — breaks the logical outline a screen reader user relies on to understand how the page is organised.

What a landmark region and screen reader sections are, and why they matter

Beyond headings, HTML supports landmark regions. This is semantic markup identifying a page’s header, main content area, navigation, and footer as distinct, named sections. A screen reader can announce these regions and let a user jump directly to, say, the main content. That skips repeated navigation menus that would otherwise need tabbing through on every single page. A site built entirely from generic, unstructured markup, with no landmark regions, forces a screen reader user to navigate linearly through everything, every time.

How to check your own site’s heading structure and accessibility with WAVE

Most browsers have a free extension or built-in tool — WAVE is a widely used one — that lists a page’s heading structure as an outline, independent of visual styling. This reveals immediately whether headings are nested logically, or whether levels have been skipped or used purely for visual sizing. This check does not need specialist accessibility knowledge. It needs someone to look at the outline the tool produces and ask whether it reads as a sensible table of contents for the page.

Why this is also a content and copywriting decision, not purely a technical one

Deciding what should be a heading, at what level, and in what order, is fundamentally an editorial decision about how a page’s content is organised. The technical markup simply needs to reflect that structure honestly, not be chosen for visual effect. This is why heading discipline sits naturally with whoever writes a page’s content, covered more broadly on who writes the words. It should not be treated purely as a developer’s implementation detail, applied after the copy already exists.

The most common specific failures: empty headings and document structure

Multiple <h1> elements on one page, when there should generally be exactly one representing the page’s main topic. Heading levels chosen for font size rather than document structure — a large <h2> used purely because a smaller font looked wrong, regardless of whether it’s a genuine subsection. And decorative text styled to look like a heading with no heading markup at all, which is the inverse failure — visually a heading, structurally invisible.

What to ask a supplier

Ask whether page templates use a single logical heading structure, reviewed with an outline tool rather than assumed correct because it looks right visually, and whether the main content area, navigation and footer are marked up as landmark regions rather than generic, unlabelled containers.

Page titles, a related but distinct signal

Beyond headings within a page, the page’s <title> element — what appears in a browser tab and in search results — is announced first by a screen reader when a new page loads. A vague, repeated or missing page title leaves a screen reader user without the immediate context a sighted user gets from the surrounding site design. Every page needs a distinct, descriptive title. That is a separate requirement from the on-page heading structure, but it serves the same purpose: orienting a visitor quickly.

Why tables need their own structural markup, distinct from headings

A data table conveying genuine tabular information — not used purely for visual layout — needs its own semantic markup identifying column and row headers. That lets a screen reader announce which header a given cell relates to, as a user navigates through it. A table built without this structure, using only visual formatting to suggest columns and rows, is unusable in the same practical sense a heading styled only visually is unusable for heading navigation.

How this affects single-page applications and dynamically loaded content

Modern sites that load new content into a page without a full page reload — a common pattern for interactive web applications — need to manage focus and heading announcements deliberately when content changes. A screen reader has no natural cue that new content has appeared, without a full page load to trigger re-reading. This is a more advanced technical point than a standard content site typically needs to address. But it is a genuine, often-missed requirement for more interactive builds.

What to do next

Run a heading-outline check on your own key pages and compare it against what a sensible table of contents for that page would look like — mismatches are usually fixable without a redesign. Where this discipline fits into a copywriting engagement is set out on website copywriting.