Sources take different approaches
W3C recommends logical groups of fields and communicating progress where possible. GOV.UK starts with one question per page and recommends testing without a progress indicator first, while allowing related questions to be grouped when appropriate. This guide chooses W3C’s logical-group and progress approach.
Preferred source: W3C · Multi-page forms. Use W3C as the preferred source for grouping fields and explaining progress in this guide. Keep related inputs together and communicate the current stage; a graphical progress bar is optional. This is a guide-specific choice over our usual GOV.UK design default.
Compare: GOV.UK · Question pages and progress indicators. How we choose sources.
Recommendation
Divide long forms into logical steps, keeping related fields together. Help users understand their progress on each step and, where possible, explain how many steps there are before they start.
Problem
There is a lot of information to collect.
Split a form into steps when
- An application has separate identity, eligibility, and review stages.
- Branching can keep irrelevant questions out of the user's path.
Keep a form on one page when
- The form is short enough to scan and complete without losing context.
- Users need related fields visible together to answer accurately.
Keep related fields together
Follow W3C’s logical-group approach. A shipping-address step can contain street, postcode and city fields; payment details belong in a separate step. Choose boundaries that make the task easier to understand rather than splitting after a fixed number of fields.
Make progress clear
Tell users which stage they are on and, where possible, how much remains. A heading such as “Step 2 of 4: Shipping details” can do this; a graphical progress bar is not required. Keep progress information accurate when answers change the route.
Example
This reduced example demonstrates moving between steps without losing answers.
Implementation
- Group related fields into logical stages, such as shipping details and payment details. Give each stage a clear heading, repeat essential instructions, and make optional stages easy to skip.
- Communicate progress in the page title or main heading, such as “Step 2 of 4: Shipping details”. Explain the steps up front when possible. If branching makes the total uncertain, give useful stage information without promising an inaccurate count.
- Validate the current step on Continue. When replacing a step without a page load, move focus to its heading or another useful starting point so the change is clear.
- Preserve answers when users go back. Reuse information already supplied in the same process unless re-entry is essential, needed for security, or the earlier information is no longer valid.
- When an earlier answer changes the route, recheck dependent answers before accepting the submission.
- Consider save-and-return for lengthy tasks. If the flow has a time limit, provide the WCAG-required way to turn it off, adjust it, or extend it unless an exception applies.
- For consequential submissions, review and correction is one safeguard; suitable error checking or reversibility may also meet the relevant WCAG requirement. Confirm successful completion.
Tradeoffs
Grouping related fields reduces fragmentation, but large steps can still feel demanding. Steps add navigation, so keep short forms together when that is clearer. Communicate progress with useful titles or headings; use a graphical indicator only when it adds value, and avoid an inaccurate total when the route can change.
Verification
Can a keyboard or screen reader user identify the current stage and their progress, go back, correct an answer, and continue without losing valid work? Are related fields kept together and any step count accurate?