use UI

Stepper

Also called wizard, progress steps, multi-step form, step indicator

An ordered indicator of the steps in a process, showing which are done, which is current, and which are still ahead.

Example

Step 2 of 4: Shipping

Where the parcel goes and how fast it gets there.

Every step's state exists as text, not just as a colour — a filled circle says nothing to a screen reader. Steps ahead stay visible but aria-disabled, so the shape of the process is knowable before committing to it. The count is written out in the panel heading, which is the part that survives on a narrow screen.

When to use it

  • A task genuinely has to be split — checkout, onboarding, anything where later steps depend on earlier answers.
  • The user needs to know the size of the commitment before starting. “Step 1 of 3” is the whole point.
  • Steps can be returned to, and seeing the earlier ones makes going back obvious rather than a guess.
  • The order is real. If steps can be done in any sequence, they are sections, not steps.

When not to

  • The form is short enough to show at once. Splitting eight fields across three screens adds clicks and nothing else.
  • The number of steps is unknown or changes as you go — a stepper that grows breaks the promise it made.
  • There are only two steps. That is a form and a confirmation, not a process worth charting.
  • You want to show hierarchy rather than sequence. That is a breadcrumb.

Trade-offs

  • Sets expectations up front, which measurably reduces abandonment on long forms.
  • Lets the user return to an earlier step without losing what they entered.
  • Splits validation into pieces small enough to fix one at a time.
  • Encourages splitting forms that did not need splitting.
  • Each step is a page transition, and state has to survive all of them.
  • Easy to build so that going back is possible but going forward again is not, which strands people mid-process.
  • Takes real horizontal space; on mobile it usually degrades to “Step 2 of 4” text, which is most of the value anyway.

Accessibility

What this pattern needs in order to work for everyone.

Keyboard
  • If steps are clickable, they are buttons or links and Tab must reach them. If they are only an indicator, they should not be focusable at all.
  • Never make a step focusable but inert — a tab stop that does nothing when activated reads as broken.
  • Steps ahead of the current one are usually unavailable: mark them `aria-disabled` rather than removing them, so the shape of the process stays visible.
Roles and state
  • Mark the current step with `aria-current="step"` — this is the one place that value is correct.
  • Use an ordered list so the count and position are announced without you writing them out.
  • Each step's state must exist as text, not just colour: “completed”, “current”, “not started”. A green circle says nothing to a screen reader.
  • If the steps navigate, wrap them in `<nav>` with a label; if they only report progress, they are not navigation and should not claim to be.
Focus
On moving to a new step, put focus on the new step's heading — not back to the top of the document, and not on the first field. The user needs to hear which step they landed on before being dropped into an input.

In the wild

  • Stripe Checkout — Short, honest step count shown before the first field — the commitment is stated up front.
  • GOV.UK — One question per page, with the progress stated in text rather than drawn as a diagram.

Compared with

Side-by-side breakdowns of patterns that solve a similar problem.