Heading order and one main idea per level

Headings (<h1> … <h6>) create an outline of the page. That outline is used by:

• Screen reader users who jump from heading to heading.
• Search engines (as one signal among many).
• Future you, when you edit long pages.

AI tools sometimes pick heading levels based on how big the text should look in a design. That is CSS’s job, not the heading tag’s job. The tag’s job is structure.

Introduction

Headings are not about size first. They are about relationship: what belongs under what. When you keep that relationship clean, CSS can style levels differently without lying to assistive tech.

One main idea per level means: at each depth in the outline, you are answering one kind of question. Typically:

• <h1> — What is this page?
• <h2> — What are the major sections?
• <h3> — What are the subsections inside a section?

If you skip from <h1> to <h4> because “it looked smaller,” you break the outline—like skipping chapter numbers in a book.

Key concepts

One <h1> per page (usually)

Most simple static pages have one primary topic. That topic belongs in one <h1>. Site-wide logos or navigation are not usually the <h1>—the page topic is.

Exceptions exist in complex apps; for this course’s static sites, start with one <h1>.

Do not skip levels without reason

Bad pattern:

<h1>Workshop</h1>
<h4>Date and time</h4>

Better pattern:

<h1>Workshop</h1>
<h2>Date and time</h2>

If you need smaller visual text, use CSS (font-size, a class) on a proper heading level.

Heading order and Lighthouse

Automated checks (including Lighthouse accessibility) often flag order issues. Fixing them is not “only for audits”—it helps real people navigate.

Screen reader perspective (conceptual)

Screen reader software reads the page in order—often following the DOM tree and headings. When levels skip, users lose the mental map of how sections nest. Imagine hearing: “Heading level 1: Workshop,” then suddenly “Heading level 4: Date”—it sounds like you skipped chapters. Fixing levels restores that map.

Design systems and templates

If you use a template from AI, headings might be baked in wrong. Your job is to align headings with your content outline, not the template’s default demo text.

Example — fix the outline

Broken:

<h1>Our club</h1>
<h3>Meetings</h3>
<p>We meet on Saturdays.</p>
<h2>Contact</h2>

Problems: h3 appears before h2, which breaks the expected outline flow.

Repaired:

<h1>Our club</h1>
<h2>Meetings</h2>
<p>We meet on Saturdays.</p>
<h2>Contact</h2>

If “Meetings” needed sub-parts, you would add <h3> under that <h2>, not before any <h2> exists.

Long pages

For longer static pages (rare in early projects but common in docs), you might have multiple <h2> sections each with their own <h3> children. The rule stays: nest, do not skip. If you need more than three levels often, consider splitting into another HTML page for readability.

Connection to Lighthouse

Automated tools flag multiple h1 or order issues because those patterns correlate with real confusion. Fixing them is not “gaming Lighthouse”—it is aligning machine-detectable structure with human sense-making.

Compare two AI drafts (thinking exercise)

Imagine two drafts of the same page: Draft A uses h1 once and h2 for sections. Draft B uses h3 for the main title because the designer wanted “smaller text.” Which draft is easier to restyle with CSS later? Which is easier for a screen reader user? Write four sentences explaining your choice.

Headings inside <section> and <article>

When you wrap content in <section> or <article>, many accessibility guides expect a heading inside that wrapper—often starting at <h2> if the page already has an <h1> elsewhere. That pattern keeps each block self-describing: someone who jumps by landmark or section hears a title for that chunk. AI templates sometimes drop a section in with no inner heading, which makes the outline feel hollow. In review, ask: If this section were printed alone, what would its title be? Put that title in a heading at the right level.

Reusing components and duplicate outlines

Component libraries and AI snippets may paste the same heading pattern everywhere—for example, every card might ship with an <h3> even when the card is not a subsection of the previous <h2>. Visually it can look fine; structurally it can lie. When you reuse a card pattern, adjust heading levels to match where the card sits in this page’s outline, not where it sat in the demo. That is creative direction at the markup level: truth over convenience.

Collaboration and comments

If you work with a peer reviewer, add brief HTML comments above major sections (<!-- Main: services -->) only when it helps human navigation—not as a substitute for proper headings. Comments are invisible to most end users and are not a replacement for accessible structure. Use them to align people, use headings to align technology and meaning.

Quick self-check before you save

Before you close the editor, scan the file for every h1–h6 in order. Read only the heading tags as a list. Does that list sound like a sensible table of contents? If a heading feels like it belongs under another, nest it with the next level down instead of jumping. This habit takes seconds once you know what you are looking for—and it prevents small mistakes from becoming big accessibility debt.

Practice

Task A — Rewrite

Rewrite this outline with correct levels. You may rename headings slightly for clarity.

<h1>Services</h1>
<h4>Web design</h4>
<h4>Hosting</h4>

Task B — Explain

In four to six sentences, explain why a screen reader user might be confused by h1 then h4 with no h2/h3.

Key takeaways

• Headings = outline, not font sizes.
• Skip levels when styling—not when structuring.
• Clean outlines support accessibility and editing—and calmer Lighthouse scores.

What’s next

Next up: CSS — what to skim first