Headings as Navigation

Headings are often treated as visual punctuation — a way to break up text so the page does not look like a wall. This is correct but incomplete. Headings serve a more fundamental function: they are the table of contents that readers use to navigate a page before reading it. When headings fail to communicate what their section contains, readers cannot navigate. When headings communicate clearly, readers can skip to what they need, ignore what they do not, and understand the structure of the content without reading it in full.

Headings as a content outline

Every document with headings contains an implicit outline: the sequence of headings, read without the body text, should tell the story of the document. If the headings alone do not communicate what the document covers, the headings are not doing their job.

This test exposes common heading failures. A heading that says “Introduction” communicates nothing about what the introduction covers. A heading that says “Getting started with spacing in Tailwind CSS” communicates exactly what the section contains. The first is a label; the second is a navigation aid.

Run the heading-only test on any document you write: read only the headings. If the outline is unclear or uninformative, rewrite the headings before editing the body text.

The heading hierarchy

HTML provides six levels of heading (H1–H6), though most documents use only three or four. The hierarchy has two functions: visual and semantic.

The visual function is to create a size gradient that signals importance: H1 is largest, H2 smaller, H3 smaller still. This gradient communicates document structure before the reader has read anything.

The semantic function is to allow screen readers, search engines, and other parsers to understand the document’s structure. A screen reader user navigating a long document will jump between headings using keyboard shortcuts — the same way a sighted reader scans the heading structure visually. This means heading hierarchy matters for accessibility, not just visual design.

The practical implication: do not skip heading levels for visual effect. Do not use H3 because it looks the right size if H2 has not been used yet. The hierarchy must be logical, not just visual.

Writing headings that work

A strong heading is:

Specific. “Error handling” is vague. “Writing error messages that help users recover” is specific.

Consistent in grammatical form within a level. If your H2s are noun phrases (“Error handling”, “Button labels”), do not introduce a gerund phrase (“Writing error messages”). Mix only deliberately.

Front-loaded with the key term. Readers scan the beginnings of headings just as they scan the beginnings of sentences. “Understanding how the grid system affects alignment” buries “grid system” in the middle. “Grid system: how it affects alignment” front-loads it.

Not cleverly vague. “The big reveal” and “What we found” are not headings — they are teasers. They may work in editorial contexts where the reader is committed to reading. In most web content, they fail because the reader who is scanning cannot assess whether the section is relevant without reading it.

Heading density

How many headings are appropriate in a document depends on the content length and reading context. A short article of 600 words may need only one or two H2s. A technical tutorial of 3,000 words may need H2s every few hundred words with H3s for subsections.

The test is whether a reader who scans the headings can orient themselves. If the headings are so sparse that a reader scanning can jump over large sections without understanding what they are skipping, add headings. If they are so frequent that every paragraph has a heading, the document has too many sections — consider restructuring.

Next: what microcopy is — the smallest pieces of interface language, and why they carry disproportionate weight.