Stepper
Steppers let users nudge a numeric value by a fixed step, typically for small ranges where free-form typing would feel heavy.
Ready to use
The Stepper is a multi-step form header featuring progress navigation and a back action. It visually communicates a user’s position within a linear, multi-step process, so users understand how many steps remain, which step is currently active, and which have already been completed. The component is designed to stay sticky at the top of the viewport as users progress through a flow, providing constant orientation across mobile, tablet, and desktop.
Anatomy
Section titled “Anatomy”- Stepper
- Step
- Check
- Progression indicator
- Number
- Label
When to use it
Section titled “When to use it”Use the Stepper when:
- A process is too complex for a single view — for instance, more than 5–6 fields that need logical grouping.
- The flow is a high-value transaction (checkout, insurance, legal form) where the user needs constant reassurance of their progress.
- The journey is linear and the user must be guided through a specific sequence.
Avoid the Stepper when:
- The task can be completed in a single page view.
- The process is non-linear and users need to jump back and forth between sections.
- The flow has fewer than two steps.
- The component would sit inside an overlay or modal where space is limited — it makes the UI feel packed.
Properties
Section titled “Properties”State
Two visual modes: Rested for the standard top-of-page placement, and Scroll which adds an elevation drop shadow once the user scrolls past the header. The Scroll mode keeps the stepper anchored to the top of the viewport without losing its visual separation from the content beneath.
Device adaptation
The same component reshapes per breakpoint. Mobile shows only the current step’s label; tablet and desktop expose every label. The title and indicator scale up at desktop sizes to match the broader layout.
Step indicator
Each step renders as a circle that takes the Incomplete, Current, or Completed state. Completed steps fill and show a check; current steps use a heavier border; incomplete steps stay outlined and quiet.
Progression indicator
The connector line between steps. It fills to show the completed segments of the journey and stays quiet for the steps still ahead, so overall progress reads at a glance.
Back button
A boolean that controls whether the back action appears. Default true from step 2 onward — keep it as the first focusable element so keyboard users return to the previous step without scanning past the progress.
Platform considerations
Section titled “Platform considerations”Desktop
The full step list is visible. Titles use the larger Title/Desktop/7 size and labels sit beneath each indicator.
Tablet
All step labels are visible. The title shrinks one step to Title/Desktop/8 so the header keeps its rhythm at narrower widths.
Mobile
Only the current step’s label is shown to keep labels readable for longer translations. All other indicators stay visible without their labels so users still see the journey shape.
Best practices
Section titled “Best practices”The stepper carries trust — keep it predictable and never lose user data inside it.
Do
Use it when a process needs more than 5–6 grouped fields, lean on it for high-value transactions where the user benefits from constant orientation, build it for linear journeys where the sequence matters, persist entered data on Back (never clear a form field during a Back action), and keep the header sticky with its scroll-state shadow for constant orientation.
Don't
Don’t use the stepper for single-page tasks, don’t use it for non-linear flows where users jump between sections, don’t use it for journeys with fewer than two steps, and don’t place it inside overlays or modals where space is limited.
Content guidelines
Section titled “Content guidelines”The title sits at the top of every step, so write it as a short, identifying phrase (“Your details”, “Payment”, “Review”) rather than a sentence. Step labels should be one or two words and stay parallel across the journey so the progression reads coherently. Reinforce each indicator with a screen-reader-only “Step N of M: label” so assistive tech announces position alongside the visible glyph. Keep wording stable between Rested and Scroll states — the same words should read the same way whether the user has scrolled or not.
Styles
Section titled “Styles”<div class="tng-stepper"> <div class="tng-stepper-step">1</div> <div class="tng-stepper-divider"></div> <div class="tng-stepper-step">2</div></div>Elements
Section titled “Elements”States
Section titled “States”<button class="tng-stepper-step is-completed"> <span class="sr-only">1</span> <i class="tng-icon icon-check" aria-label="Completed"></i></button><button class="tng-stepper-step is-active">2</button><button class="tng-stepper-step">3</button><button class="tng-stepper-step is-active"> <span>1</span> <p class="tng-stepper-step-label">Step Title</p></button>Divider
Section titled “Divider”States
Section titled “States”<div class="tng-stepper-divider"></div><div class="tng-stepper-divider is-completed"></div>Module
Section titled “Module”<div class="tng-stepper"> <button class="tng-stepper-step is-completed"> <span class="sr-only">1</span> <i class="tng-icon icon-check" aria-label="Completed"></i> <p class="tng-stepper-step-label"> <span class="tng-overflow-multiline-ellipsis"> Step Title 1 </span> </p> </button> <div class="tng-stepper-divider"></div> <button class="tng-stepper-step is-active"> <span>2</span> <p class="tng-stepper-step-label"> <span class="tng-overflow-multiline-ellipsis"> Dealer, Time & Date </span> </p> </button> <div class="tng-stepper-divider"></div> <button class="tng-stepper-step"> <span>3</span> <p class="tng-stepper-step-label"> <span class="tng-overflow-multiline-ellipsis"> Step Title 3 </span> </p> </button> <div class="tng-stepper-divider"></div> <button class="tng-stepper-step"> <span>4</span> <p class="tng-stepper-step-label"> <span class="tng-overflow-multiline-ellipsis"> Step Title 4 </span> </p> </button></div>The stepper communicates a user’s position within a linear, multi-step flow. It has no dedicated WAI-ARIA APG widget pattern; it is built from native step buttons, and the step in progress is flagged with aria-current="step" — the same convention the WAI-ARIA APG Breadcrumb pattern uses to mark the current location — and it meets WCAG 2.1 AA. An accessible stepper announces which step is active, which are already complete, and where each one sits in the sequence, so a user knows how far they have come and how far is left whether they are looking at it, listening to it, or tabbing through it.
For designers
Section titled “For designers”- Every step state — incomplete, current, and completed — must maintain accessible contrast on every supported surface. Source: WCAG 1.4.3 Contrast (Minimum).
- Progress must never be conveyed by colour or fill alone — pair each state with a shape cue, so the current step carries a heavier border and the completed step a check glyph. Source: WCAG 1.4.1 Use of Color.
- Focus styles must stay visible, meet contrast requirements on every supported surface, and be clearly distinguishable from hover. Source: WCAG 2.4.7 Focus Visible.
- Use semantic colour tokens (e.g.
foreground/neutral/default) rather than fixed values, so the component adapts correctly across themes and surfaces.
For developers
Section titled “For developers”Build each step as a native <button> so it is focusable and keyboard-operable without extra scripting — you get Enter / Space activation and the standard focus ring for free — and expose the set as a labelled group (e.g. a <nav> landmark) so assistive-technology users can find and skip the progress region. Everything each step must announce — its role, its accessible name, and whether it is the current or a completed step — is in the Labelling elements section below.
Keyboard interaction
Section titled “Keyboard interaction”| Key | Action |
|---|---|
| Tab / Shift + Tab | Move to the next / previous step, or the back action |
| Enter / Space | Activate the focused step |
Each step button must be large enough to operate comfortably — at least 24 × 24 px. Source: WCAG 2.5.8 Target Size (Minimum).
Labelling elements
Section titled “Labelling elements”Give every element the role, name, and state assistive technology needs.
Step
A native <button>. Its accessible name comes from the visible step number and label — enrich it with a screen-reader-only “Step N of M” so position is announced, e.g. “Step 2 of 4: Details”. Mark the step in progress with aria-current="step" so assistive tech knows exactly where the user is, and leave it off every other step.
Completed indicator
The check glyph that replaces the number on a finished step needs a text alternative — aria-label="Completed" — with the step number kept in a visually hidden <span class="sr-only">, so the completed state is announced rather than left to the fill colour.
Progression divider
The connector line between steps is purely decorative. Keep it out of the accessibility tree (aria-hidden / presentational) so it adds no noise — progress is already carried by each step’s own state.
Source: WCAG 4.1.2 Name, Role, Value.