Wizard / Stepper

You’re booking a holiday apartment. Step 1, guests. Step 2, your address. Step 3, payment. You notice a typo in the address and press Back. The address form is empty. You type it all again, press Continue… and the payment step is empty too. Then the phone rings, you come back, refresh the page, and you’re on step 1 with nothing filled in.

A wizard turns one long, scary form into a few short ones. It also adds navigation and memory: which step am I on, what did I already enter, where does Back go? Every one of those is a place where a user’s work can quietly disappear.

What is it?

A wizard (also called a multi-step form or stepper) splits a long task into an ordered series of steps, one screen or section at a time, with a step indicator showing where you are: Contact › Shipping › Payment › Review. You’ll meet wizards in checkouts, bookings, sign-ups, loan and insurance applications, onboarding, and setup flows (“connect your smartwatch”).

Anatomy

Linear or non-linear?

Type	How it works	Good for
Linear	Steps in a fixed order. You can’t open step 3 before step 2 is valid. Completed steps can be revisited.	Checkouts, payments, anything where later steps depend on earlier ones
Non-linear	Every step can be opened at any time, in any order. The final step checks that everything is complete.	Profiles, settings, long applications users fill in over several days

The indicator must make the rule visible: in a linear wizard, upcoming steps look (and are) not clickable; in a non-linear one, every step looks clickable and shows whether it’s done.

Designs & variants

Press Next step and Back under each example:

1. Contact
2. 2Shipping
3. 3Payment
4. 4Review

Shipping

BackNext step

1. Contact· edit

2. 2

   Shipping
3. 3

   Payment

4. 4

   Review

BackNext step

ContactCheckout

Step 2 of 4

Shipping

BackNext step

1. Cart
2. Shipping
3. Payment
4. Review

Shipping

BackNext step

• Material steppers: Material Design (version 2) defined horizontal, vertical and mobile steppers. Material 3 no longer includes a stepper, but web libraries like MUI, Angular Material and Vuetify still ship one, so you’ll see that look everywhere.
• No native stepper on iOS or Android. Apps usually show one screen per step with a progress bar or “Step 2 of 4”, and use the navigation bar back button.
• Optional steps are labelled “Optional” and can be skipped. Error states mark a step with a red icon when it needs attention.
• Progress without labels (dots or a bar) is common in onboarding. It shows how far, but not what’s next.

When to use it

• The form is long (more than one screen of fields) and falls naturally into groups: who, where, how to pay.
• Later steps depend on earlier ones: shipping options depend on the address, payment options on the country.
• Users benefit from a review before committing: orders, bookings, applications, transfers.
• The task takes a while and users may pause and come back: then steps and drafts help a lot.

Good and bad uses

How good wizards behave

Validation happens per step

Each step checks its own fields when the user presses Continue, with clear error messagesError messageText that tells the user something went wrong and, ideally, how to fix it.Open in glossary → next to the fields, and doesn’t move on until they’re fixed. Don’t wait until the last step to say “ZIP code is invalid” without saying where. Also don’t validate the whole wizard on step 1 (“Payment method is required” before the user has seen payment). See text field for field-level input validationInput validationChecking that what the user typed is acceptable before the app uses it.Open in glossary →.

Back keeps everything

Back goes to the previous step with all its data still there. That includes choices like radio buttons and checkboxes, not just text. Going back and forward several times must never lose, duplicate or reset anything. This is state persistenceState persistenceWhether the app remembers what the user did after navigating away, rotating, or restarting.Open in glossary →, and it’s the first thing to test in any wizard.

Progress is saved

Users get interrupted: a phone call, a lost connection, a closed tab. Good wizards save a draft (in the browser, on the server, or both) so a refresh or a return visit lands on the same step with the same data, sometimes with a message like “Welcome back, you were on step 3”. Ask how long a draft lives, whether it follows the user to another device, and what’s not saved on purpose (card numbers and passwords usually aren’t).

On mobile, the same idea is state restorationState restorationBringing the user back to the same screen and data after the OS closed the app in the background.Open in glossary →: the OS can kill an app in the background, and the user should come back to the same step.

Every step has an address (web)

On the web, each step should change the URL: /checkout/shipping, /checkout/payment. Then the browser Back button goes to the previous step (not out of the checkout), Refresh stays on the step, and support can send a deep linkDeep linkA link that opens a specific screen inside an app instead of just its home screen.Open in glossary → to a specific step. Test what happens when you open a later step’s URL directly in a linear wizard: you should land on the first incomplete step, not on a half-broken payment page.

On Android, the system Back gesture or button should go to the previous step too. On iOS, the swipe from the left edge does the same in a navigation stack. If Back closes the whole flow, the user at least deserves a “Leave checkout? Your progress is saved” message.

Editing from the review page

The review step shows everything with Edit links. Edit opens that step, and saving should return to Review (“Save and return to review”), keeping every other step as it was. Walking the user through all later steps again, or worse, clearing them, is a common bug. One exception: if the change really affects later steps (a new country changes the shipping options), the wizard should say so and ask only for what changed.

Errors send the user to the right step

When the server rejects the order at the end (address can’t be delivered, card declined), the user should land on the step that needs fixing, with the error shown on the field, and their other data intact. A generic “Something went wrong” on the review page, or a restart from step 1, are both bugs.

The indicator never lies

The highlighted step, the “Step 2 of 4” text, the page title and the form on screen must always agree: after Continue, Back, browser Back, Edit, refresh and deep links.

Common bugs

#	Bug	What you see	Typical severity
1	Back loses data	The previous step’s fields are empty after going back	High
2	Browser/system Back leaves the flow	One Back press and you’re out of the checkout	High
3	Indicator out of sync	“Step 3” is highlighted while step 2 is shown	Medium
4	Skipping required steps	Clicking the indicator opens Payment without a valid address	High
5	Edit from Review wipes later steps	After editing Shipping, Payment is empty again	Medium–High
6	No draft	Refresh or app restart goes back to step 1, empty	Medium–High
7	Errors on the wrong step	Server error shows on Review, the field to fix isn’t highlighted	Medium
8	Double submit	Pressing Place order twice creates two orders	Critical
9	Stale later steps	Changing the country keeps a shipping method that’s no longer available	Medium
10	Indicator doesn’t fit	Labels overlap or overflow on a 360 px screen	Low–Medium

Stress-test it

A correct checkout wizard. Use Fill this step with test data to move fast. Try the browser Back, Forward and Reload buttons on every step, switch between Linear and Non-linear, and set the Server answer to Bad ZIP or Declined before you press Place order. Switch Layout to Phone to see a compact indicator, and watch what a screen reader hears.

Navigation

LinearNon-linear

Layout

DesktopPhone

Server answer on Place order

OKBad ZIPDeclined

Linear: steps you haven’t reached are locked in the indicator. Completed steps can be revisited.

shop.example.com/checkout/contact

Contact details

We'll send your receipt and delivery updates here.

Email

Phone (optional)

Continue to shipping

Fill this step with test data Restart

Screen reader hears

1. Step 1 of 4: Contact

Find the bug

This checkout has six bugs. The ticket’s acceptance criteria are in the panel below it. Explore like a tester:

• Fill the steps and go all the way to Review. Then go Back step by step.
• Use the browser Back and Forward buttons on step 2 or 3.
• On step 1, click Payment in the indicator.
• On Review, press Edit next to Contact or Shipping, then continue.
• On step 3, press Reload.

🐞 Bug hunt: Checkout wizard

This demo has 6 hidden bugs. Explore it like a tester, then check your findings.

Found0/6

shop.example.com/checkout

Checkout · Step 1 of 4: Contact

Contact details

We'll send your receipt and delivery updates here.

Email

Phone (optional)

Continue to shipping

Tester tools

Restart

Fill this step with test data

Acceptance criteria (from the ticket)

• Steps are completed in order. Only completed steps can be opened from the indicator.
• The indicator always shows the step on screen.
• Back (in the app or the browser) goes to the previous step and keeps what the user entered.
• Edit on Review opens that step, and saving returns to Review with everything else kept.
• The checkout is saved as a draft: a refresh returns to the same step with the data.

Network

• Requests appear here…

1. 1

   Hint: Fill Shipping, continue to Payment, then press the Back button under the form.

   Back clears the previous step

   The Shipping form comes back empty: street, city and ZIP are gone, and the delivery speed is reset to Standard. The same happens from every step. Back must return to the previous step with everything the user entered.

   Reveal answer✓ I found this
2. 2

   Hint: On step 2 or 3, press the browser Back button. Then press Forward.

   Browser Back leaves the whole checkout

   The address bar always says /checkout, so the browser history has only one entry for the whole wizard. Browser Back goes straight to the cart, and Forward starts the checkout again from step 1 with empty fields. Expected: each step has its own URL (/checkout/shipping) and browser Back goes to the previous step.

   Reveal answer✓ I found this
3. 3

   Hint: Go to Payment, then press Back. Compare the indicator and the text above it with the form.

   The indicator shows the wrong step

   The indicator and the “Step 3 of 4: Payment” text show the furthest step reached, not the current one. After going back, the Shipping form is shown with Payment highlighted. It also happens after Edit on Review. Screen reader users get the wrong position too.

   Reveal answer✓ I found this
4. 4

   Hint: On step 1, click Payment or Review in the indicator.

   You can jump to Payment without completing Shipping

   Every step in the indicator is clickable, even ones not reached yet. You can open Payment and Review with no address and even place an order with no shipping address (look at the confirmation and the POST in the Network log). The ticket says steps are completed in order; upcoming steps must not be clickable, and Place order must re-check every step.

   Reveal answer✓ I found this
5. 5

   Hint: Complete all steps. On Review, press Edit next to Shipping, then Continue.

   Editing from Review wipes the later steps

   After saving Shipping, you land on Payment instead of Review, and the payment method you chose is gone. Edit Contact and both Shipping and Payment are cleared. Expected: “Save and return to review”, with every other step kept.

   Reveal answer✓ I found this
6. 6

   Hint: Fill steps 1 and 2, then press Reload on step 3.

   Refresh restarts the checkout with nothing saved

   The checkout restarts on step 1 with all fields empty. No draft is saved, and the step isn’t in the URL either. Users who refresh, lose the connection or come back later must type everything again, and many won’t. Expected: the same step with the same data.

   Reveal answer✓ I found this

How to test it

Checklist

Wizard test checklist

0 of 13 checked

Copy

• Each step validates its own fields on Continue, with errors next to the right fields
• In-app Back keeps every value on every step (text, radios, checkboxes, dropdowns)
• Browser Back (web) or system Back / swipe back (mobile) goes to the previous step, not out of the flow
• Each step has its own URL; Refresh and Forward keep the step; a direct link to a later step lands on the first incomplete step
• The indicator, "Step X of Y" text and page title always match the step on screen
• Linear: upcoming steps cannot be opened from the indicator; completed steps can
• Edit from Review returns to Review and keeps all other steps
• Changing an earlier answer that affects later steps (country, date) updates or re-asks only what changed
• A draft survives refresh, closing the tab or the app being killed, and sensitive data is not stored in it
• Server errors at the end send the user to the right step with the error on the field
• Place order / Submit cannot be triggered twice
• Indicator fits at 360 px (compact version or wrapping), labels are not cut off in a confusing way
• Screen reader hears "Step 2 of 4: Shipping" on each step; focus moves to the step heading

Example test cases

Tools

• The address bar and DevTools › Application (see DevTools for testers and cookies, sessions and storage): watch the URL change per step, and find the draft in Local Storage, Session Storage or a server request. Check no card number or CVC is stored there.
• DevTools › Network: see when each step is saved, and that Place order sends one request even if you double-click.
• Android: Developer options › Don’t keep activities to test the draft after the OS kills the app; test the system Back gesture on every step.
• iOS: swipe back from the left edge on every step; background the app for a while and return.
• Screen readers: VoiceOver, TalkBack or NVDA to hear the step changes.

Accessibility

• Announce the step. When a new step opens, move focus to its heading (“Step 2 of 4: Shipping”) or announce it in a live region. Otherwise a screen readerScreen readerSoftware that reads the screen aloud for blind and low-vision users, like VoiceOver or TalkBack.Open in glossary → user doesn’t know anything changed after pressing Continue.
• Mark the current step. Say each step’s state in text (“Contact, completed”). A check mark or color alone is not enough (WCAG 1.4.1 Use of Color, Level A).
  Dev note

  In the indicator use a list, with aria-current="step" on the current one.
• Errors. Link error messages to their fields, move focus to the first invalid field or an error summary, and don’t rely on red alone. See ARIAARIAHTML attributes that tell assistive technology what custom elements are and what state they're in.Open in glossary → and text field.
  Dev note

  Errors are linked with aria-describedby.
• KeyboardKeyboard navigationUsing a website with only the keyboard: Tab to move, Enter or Space to activate, Esc to close.Open in glossary →. Every field, the indicator links and Back / Continue reachable with Tab in a logical focus orderFocus orderThe order in which the Tab key moves through interactive elements.Open in glossary →. Enter in a field shouldn’t accidentally submit the whole order.
• Time limits. If the wizard times out (common in banking and ticket sales), warn the user and let them extend it (WCAG 2.2.1 Timing Adjustable, Level A).
• Don’t make them type it twice. WCAG 3.3.7 Redundant Entry (Level A) asks that information already entered in the same process is filled in or selectable, for example “Billing address same as shipping”. A Back button that clears fields fails users here too.
• Touch targetsTouch targetThe area of the screen that responds to a tap, which should be large enough for a finger.Open in glossary →. At least 44×44 pt on iOS and 48×48 dp on Android. On the web, WCAG 2.5.8 (AA) asks for at least 24×24 CSS px; 44×44 px (2.5.5, AAA) is the comfortable target. Small step circles in the indicator are a typical failure.

Mobile vs web

iOSAndroidWeb

• No stepper component: each step is usually a screen pushed onto a navigation stack, with “Step 2 of 4” or a progress bar. The back button and the left-edge swipe must go to the previous step with data kept.
• A modal flow (sheet) may have Cancel instead of Back: does it ask “Discard your changes?” before throwing away a half-filled booking?
• Background the app on step 3 and come back later, and test Dynamic Type at the largest size: does the indicator still fit?

• No native stepper either: steps are usually screens or fragments. The system Back gesture/button must go to the previous step; if it closes the flow, it should confirm first.
• Test rotation and process death (Don’t keep activities): same step, same data afterwards.
• Check the keyboard (IME) doesn’t cover the Continue button on small screens, and that predictive back shows the previous step, not the screen before the wizard.

• Each step should have its own URL: test Back, Forward, Refresh, bookmarks and opening a later step directly.
• Test the draft: refresh, close the tab, open the site in a second tab (do the two tabs fight?), log in on another device.
• Check the responsive layout: at 360 px the horizontal indicator should switch to a compact or vertical version.
• Double submit: double-click Place order and check only one order is created.

Check your understanding

Quick quiz

0/6 answered · 0 correct

1. 1.A user on step 3 of a checkout presses Back. What should they see?

   AStep 2, empty, so they can check itBStep 2 with everything they enteredCStep 1DThe cart

2. 2.On a web checkout, the browser Back button on the Payment step takes the user to the cart. What is the most likely cause?

   AThe steps don't have their own URLsBThe cart is cachedCThe payment provider is slowDCorrect behavior

3. 3.In a linear wizard, the user is on step 1. What should happen when they click "Payment" (step 3) in the indicator?

   AOpen PaymentBNothing: upcoming steps are not clickableCShow ReviewDReset the form

4. 4.The user presses Edit next to Shipping on the Review page and saves. Where should they land?

   AOn Payment, with an empty formBBack on Review, with everything else keptCOn step 1DOn the order confirmation

5. 5.Which is NOT the +/− stepper from the component library?

   AA quantity control in a cartBA step indicator: Contact › Shipping › Payment › ReviewCA "Guests: − 2 +" control in a booking

6. 6.How should a screen reader user learn that the next step has opened?

   AA color change in the indicatorBFocus moves to the step heading, e.g. "Step 2 of 4: Shipping"CA sound effectDThey have to scroll up and look

Key takeaways

• A wizard splits a long task into ordered steps with an indicator. It is not the +/− stepper.
• Use it for long forms with natural groups and dependencies; not for short forms or independent sections (use tabs).
• Back keeps data, always. Test in-app Back, browser or system Back, the indicator and Edit links.
• On the web, every step has a URL; a draft lets refresh and return visits continue where the user stopped.
• Linear wizards don’t let users skip ahead; Edit from Review returns to Review; server errors open the right step.
• The indicator never lies, and each new step is announced to screen readers (“Step 2 of 4: Shipping”).