Heading Navigation

Proper heading structure lets screen-reader users move quickly between sections while preserving the page’s information hierarchy. Semantic headings also make the document easier to understand and navigate without relying on visual layout.

HTML headings from `h1` through `h6` communicate section hierarchy to browsers and assistive technologies. A heading should describe the section that follows it, rather than being chosen merely because its default visual size looks appropriate.

Screen readers commonly provide a heading navigation feature, sometimes called a heading rotor or heading list. Users can jump through headings, inspect their levels, and move directly to a section without reading every preceding element.

A page should generally have a logical hierarchy: the main page topic is commonly represented by an `h1`, major sections by `h2`, and subsections by deeper levels such as `h3`. Skipping a level can make the structural relationship harder to understand, although the presence of a particular heading level should reflect the document structure rather than visual styling requirements.

Heading elements should contain meaningful text and should not be used solely to make text appear large or bold. Visual appearance belongs in CSS, while heading elements provide semantic structure.

For reusable components, heading levels should be chosen according to the component's position in the surrounding document structure. A component should not automatically assume that its title must always be an `h2` or `h3` if it can appear in different hierarchical contexts.

Key points

• Use semantic `h1`–`h6` elements to express document hierarchy.
• Write headings that accurately describe the content of their sections.
• Screen readers can expose headings as a navigational list or rotor.
• Choose heading levels based on structure, not desired visual size.
• Use CSS for visual styling instead of substituting non-heading elements for headings.

Interview questions

Why are semantic headings important for accessibility?

Semantic headings communicate the structure of a page to browsers and assistive technologies. Screen-reader users can use heading navigation to jump between sections instead of reading the entire page sequentially. The heading text also tells the user what each section contains. CSS can then control the visual appearance independently of the semantic level.

How would you structure headings on a typical page?

I would identify the main topic of the page and represent it with an `h1`. Major sections would normally use `h2`, with subsections nested under them using `h3` or deeper levels as needed. I would choose levels according to the information hierarchy rather than the visual size I want. Each heading should clearly describe the content that follows it.

Should heading levels always increase one number at a time?

The important requirement is a meaningful hierarchy rather than blindly forcing every numeric level to appear. For example, an `h3` should represent a subsection within the relevant `h2` context. Skipping levels can make relationships less clear, so a consistent hierarchy is preferable. However, developers should model the actual document structure rather than adding headings solely to satisfy a numeric sequence.

How do screen readers use headings for navigation?

Many screen readers expose headings as a navigational structure, allowing users to move among headings or open a list of them. The user can often inspect both the heading text and its level. This makes well-structured headings useful as an index of the page. If headings are missing, vague, or structurally misleading, that navigation mechanism becomes less useful.

How should a frontend component handle its heading level when reused in different contexts?

The component should avoid assuming that its title always belongs to one fixed heading level if its placement varies. One approach is to let the consuming context determine the appropriate semantic level while the component controls presentation separately. The implementation should preserve meaningful heading relationships in each rendered context. This prevents component reuse from accidentally creating an inconsistent document outline.