In HTML, what decides whether a piece of text should be an <h2> or an <h3>, and why is "it renders at the size the design wants" the wrong reason to choose one?
answer
- outline, not typography
- rank means nesting depth
- CSS moves size, never meaning
- one step deeper at a time
- styled div never reaches the heading list
basics
~20 sHeading rank encodes document structure: an h2 is a top-level section, an h3 a subsection of the h2 above it. Visual size is CSS's job, so choose the rank the outline needs and restyle it.
solid answer
~40 sThe `h1`–`h6` elements are a structural claim, not a type scale. Rank says how deeply a heading is nested in the document's outline: an `h3` announces "subsection of the preceding `h2`". So I pick the level from where the content sits in the hierarchy, then set whatever size the design asks for in CSS — changing `font-size` never changes what a browser or screen reader reports. That also means I don't skip levels on the way down: going straight from `h2` to `h4` implies a missing intermediate section, and a screen reader user stepping through headings hears a gap they have to reason about. Skipping *upwards* is normal, because closing a subsection and starting the next top-level one is exactly an `h4` followed by an `h2`.
go deeper
Be ready to say plainly that h1-h6 describe structure and CSS controls appearance, and to pick the next level down for a subsection rather than the one that looks right.
Explain the mechanics: the tag name becomes the level in the accessibility tree, so styling cannot change it, and describe why descending jumps break the outline while ascending jumps do not.
Show that you audit real pages — read the heading sequence alone and judge whether it works as a table of contents, and know that skipped levels are a tooling best-practice flag rather than a hard WCAG failure.
Own the tradeoff between design-system components with fixed visual titles and pages that need varying ranks, and set a convention that keeps level a property of position in the document rather than of the component.
## What a heading rank actually asserts HTML has six heading elements, `h1` through `h6`. Their number is a *rank*: it places the heading in the document's implied tree. `h1` is the top of that tree, and every heading of lower rank is treated as belonging to the nearest preceding heading of higher rank. So this markup: ```html <h1>Espresso machines</h1> <h2>Choosing a grinder</h2> <h3>Burr vs blade</h3> <h3>Stepped vs stepless</h3> <h2>Maintenance</h2> ``` says: one page topic, two sections, and the first section has two subsections. Nothing about that meaning comes from how the text looks. Browsers expose each heading to the accessibility tree with a *level* taken straight from the tag name, and assistive technology reads that number out ("heading level 3, Burr vs blade"). ## Why the design's type scale is the wrong input Every browser's user-agent stylesheet gives `h1`–`h6` decreasing default sizes, which is where the habit comes from: the heading you need happens to be small, `h4` looks small, so `h4` it is. That is choosing a semantic level from a default stylesheet you are about to override anyway. The two concerns are fully separable. Rank travels to the accessibility tree; size travels to the screen. If a top-level section title has to render at 14px, it is still an `h2`, and you write a CSS rule that sizes it — the announced level does not move. The inverse trap is the same mistake wearing a suit: marking a big piece of decorative copy as `h1` because it is the largest text in the hero. ## Not skipping levels The rule people repeat is "never skip heading levels", and it is worth stating precisely, because it is directional: - **Going deeper, increase by one.** After an `h2`, the next deeper heading is `h3`. An `h2` followed immediately by an `h4` implies a section that does not exist, and leaves anyone reconstructing the outline guessing whether markup is missing or the author was picking by size. - **Coming back up, jump freely.** An `h4` followed by an `h2` is correct and common — it simply closes the deep subsection and starts the next top-level one. Skipping downwards is not, on its own, a formal WCAG failure; the relevant success criterion, 1.3.1 Info and Relationships, is about structure being programmatically determinable, and 2.4.6 Headings and Labels is about headings being descriptive. It *is* flagged by automated tooling as a best-practice violation — axe-core ships a `heading-order` rule for exactly this — and it is the kind of detail an interviewer uses to check whether you have actually worked with the accessibility tree or only read the tag list. ## What you lose by reaching for a styled div The other half of the same question is text that is visually a heading but marked up as `<div class="title">` or `<p><b>…</b></p>`. A screen reader has no way to know it is a heading, so it never appears in the heading list, the H shortcut key skips over it, and a page that looks well-organised presents as a wall of undifferentiated text. Bold styling is not a semantic; the element is. ```html <!-- looks like a heading, is not one --> <div class="section-title">Maintenance</div> <!-- is one, and can be styled identically --> <h2 class="section-title">Maintenance</h2> ``` ## A practical way to check your own page Strip the CSS — or read only the heading text in order — and see whether what remains reads like a table of contents for the page. If the sequence of headings makes sense on its own and each level-*n* heading genuinely belongs under the last level-*(n-1)* one, the hierarchy is right. If the list contains items that are not sections, or is missing sections you can clearly see on screen, the markup is wrong regardless of how good the page looks. One more consequence worth internalising: because rank is structural, the same visual component can legitimately be an `h2` on one page and an `h3` on another. The heading level is a property of the position in the document, not of the component's design.
- Is skipping from an h2 straight to an h4 an actual accessibility conformance failure?Not strictly. WCAG 1.3.1 requires that structure be programmatically determinable and 2.4.6 requires descriptive headings; neither text says levels must increase by exactly one. But automated checkers such as axe-core flag it under a best-practice `heading-order` rule, and it degrades the outline a screen reader user reconstructs, so treat it as a defect even though it will not fail a strict audit.
- Why is going from an h4 back up to an h2 fine when going from h2 down to h4 is not?Because rank nesting only needs to be unambiguous on the way in. An `h4` after an `h2` claims a level-3 section that was never opened. An `h2` after an `h4` simply closes every open subsection and starts a new top-level one, which is exactly what the outline should express.
- A component in your library renders its title at a fixed size. How do you keep the level correct across pages?Do not tie the level to the component's look. Let the level be a parameter the page supplies, keep the visual size in CSS, and default to something sane. The identical-looking title can then be an `h2` on one page and an `h3` where the component sits inside a deeper section.
saying these in an interview costs you the question
- Chooses the heading level by how large the text renders
- Uses h4 because h2 is visually too big
- Thinks font-size in CSS changes the announced heading level
- Marks section titles as bold divs because they get styled anyway
- Claims heading levels only matter for search engine ranking