Headings

COMPONENT GUIDE

Explore behaviors before defining the interface.

Quick guide for designers

Always consider the context of the application, even when the guidance follows a standard pattern. Interaction design documents intent. Behavior must be verified in the implementation.

When to use

Use to organize sections and show the actual content hierarchy.

What to draw

Show a clear sequence of levels without choosing a level solely for visual size.

How it behaves

Static headings are not controls. Associated links and buttons retain their own behaviors.

What to document in Figma

Annotate each heading’s level and the logical section sequence for reading and navigation.

How to review

Check whether the purpose and states are clear on small and large screens and with zoom. Verify documented behavior in the implementation, including keyboard and screen reader use where applicable.

Full guidance

Interaction Design

Questions to ask when designing components of type Headings.

Important:
Depending on the context in which you build your components, there may be further questions, and some listed here may not be necessary. Assess each case individually.

Designing for "no interaction"

Before navigating the content, can you perceive the page's visual hierarchy?
Does the main heading clearly describe the page or section?
Do subheadings group related content predictably?

Designing for mouse use (any pointing device)

When headings contain links or actions, do actionable components provide visual feedback?
Does the clickable area avoid turning the entire heading into an unclear action?
Does interaction preserve the readability of the hierarchy?

Designing for gesture use

Do headings remain readable on small screens?
Do line breaks preserve meaning and hierarchy?
Do headings with actions have sufficient touch areas?

Designing for keyboard use (any non-pointing device)

Do interactive components inside headings have visible focus?
Does focus order avoid skipping the content hierarchy?
Are static headings kept from receiving focus unnecessarily?

Designing for screen reader use

Can you navigate headings using screen reader shortcuts?
Is the order of heading levels consistent?
Does heading text communicate the section's topic without relying solely on visual style?

Interaction methods

Possible interaction methods for components of type Headings.

Important:
Only the main methods are listed here. Custom components require further study.

Mouse interaction (any pointing device)

Static headings require no interaction.
Links inside headings should behave as links.
Buttons near headings should have clear accessible names.

Keyboard interaction (any non-pointing device)

Static headings do not enter the focus order.
Links or buttons associated with a heading should receive visible focus.
Navigation order should preserve the logical content sequence.

Keyboard (or gesture) interaction + screen reader

Use levels h1 through h6 according to the actual hierarchy.
Avoid skipping levels without a structural reason.
Do not use headings solely for visual appearance.

Gherkin

BDD (Behavior-Driven Development) methodology focusing on three pillars: User Stories, Acceptance Criteria, and Gherkin Syntax (Given, When, Then).

Scenario: Given that I am on a page containing headings

Keyboard navigation

WHEN I navigate a page using the keyboard
I SEE interactive components near headings following the logical order
THEN, when I activate a link or button associated with a heading
I SEE the corresponding action take place

Desktop screen reader

When I use a screen reader on a computer (NVDA, JAWS, VoiceOver) and navigate the component
- I HEAR the headings and their structural levels.
- I can navigate headings using screen reader shortcuts.
- I HEAR a consistent order of sections and subsections.
THEN, when I interact with the component, when applicable
I HEAR or perceive that the corresponding information, state, content, or action is available.

Mobile screen reader

WHEN I use a screen reader on a phone (TalkBack, VoiceOver) and swipe to navigate the component, the following happens:
- I HEAR the headings and their structural levels.
- I can navigate headings using screen reader features.
- I HEAR a consistent order of sections and subsections.
THEN, when I interact with the component, when applicable
I HEAR or perceive that the corresponding information, state, content, or action is available.

Considerations

Considerations for components of type Headings.

Choose heading levels based on content hierarchy rather than visual size.
Avoid using multiple h1 without a well-defined page structure.
Do not replace headings with bold text when they structure content.

References

Additional references for components of type Headings.

Important:
Most references are on the course platform alongside the lessons cited in this material.

Disclaimer:
The links listed here are a curated collection of references where you can find implemented components, rather than recommendations. There is no unified implementation format and no guarantee that these links follow every design pattern. Direct questions to the teams responsible for the linked materials. Before copying a model, remember that all materials are constantly updated and that patterns, particularly proprietary ones, may change.