Can applicants tell where they are in a multi-step form?

First decide whether the stages help

A long application can be divided into logical stages so customers understand one group of information at a time. W3C’s multi-page forms tutorial recommends grouping related controls, repeating overall instructions, identifying optional stages, and explaining progress on each page. That is a design starting point, not a command to split every form. A three-question enquiry is usually clearer on one page; a service application that needs identity, eligibility, supporting documents and review may benefit from stages. Write down the information each stage requires and what the person can accomplish before moving on. A step named “Details” says little; “Contact details” or “Supporting documents” gives a concrete expectation.

Do not turn the indicator into a decorative row of numbered circles. It should answer three real questions: where am I, what remains, and can I revisit an earlier stage without losing current work? These questions matter to a customer who needs to fetch a document, pause, or correct an address. State at the beginning how many stages are expected when the count is known. If later questions change the route, avoid a falsely precise promise: say that some applicants may have an additional document stage, or show an approximate count that updates consistently. A counter that says “step three of four” while an unannounced fifth stage appears damages trust even if the form eventually submits.

Make the current position visible and spoken

W3C suggests placing progress in the page title and main heading because screen-reader users often hear the title early, while sighted readers can scan the heading. A page might say “Step 2 of 4: Supporting documents” in its title and “Supporting documents, step 2 of 4” in the main heading. Keep the order and names consistent across pages and languages. A visual step list can reinforce this, but colour alone must not carry the meaning. Mark completed, current and upcoming stages with words. If a designer removes visible words for a compact mobile layout, check that the mobile user still knows what the symbols mean and that assistive technology hears the same state.

For a known sequence, W3C shows an ordered list as a practical step indicator and suggests linking to completed steps when data can be preserved. This gives both order and a route backward. If the sequence is variable, an HTML progress element may help communicate approximate completion, but a percentage can imply more precision than the process has. Choose a representation that reflects the underlying state. A progress bar is an indicator, not navigation; do not make it appear clickable if it cannot take the applicant anywhere. Conversely, if completed stages are links, give them ordinary link behavior, visible focus and a clear current-stage marker. The semantics should match what the user can actually do.

Design the backward route with the data model

A link to a completed stage is only useful if the application retains what the customer has already entered. Decide when a stage is saved: on Continue, on a deliberate Save action, or at another clearly explained point. If a customer returns to change a previous answer, later answers may no longer apply. For example, changing an applicant type might remove a required document stage. The system should explain which later entries are affected, preserve unaffected data, and ask for confirmation before discarding substantial work. Do not silently show a reassuring “completed” label on a stage whose answers are now invalid. W3C’s example explicitly conditions links to past stages on saving current data.

Distinguish “Back” inside the application from the browser Back button. Both paths should be tested because customers will use both. If the form creates a draft record, make sure a second tab or a resumed session does not quietly overwrite newer answers. Explain whether a draft exists, how to resume it, and whether a “previous” page can be safely revisited after final submission. An application that has reached a final confirmation should not make the progress list look as if changing a past answer will edit the submitted record when it will actually start a new request. The progress indicator must reflect the data lifecycle, not just the front-end screen sequence.

Work through a service application

Consider a local service application with four expected stages: contact details, service needs, supporting documents, and review. On the first page, show the stage names and explain that an applicant without supporting documents can save a draft and return. On the second page, the title and heading say “step 2 of 4”; the indicator names the previous stage as completed and the next two as upcoming. On the document page, tell the user whether the stage is required for their answers and offer a clear skip path if it is optional. The review page summarizes entered information and links back to the relevant stage for correction, while the data remains intact.

Now test a customer who changes “individual” to “company” at the second stage. If a company document becomes necessary, update the visible and spoken stage state and explain why the document stage changed. If an optional stage disappears, do not leave the progress list counting a page that cannot be reached. Test the English and Traditional Chinese labels independently: a literal translation may be too vague for the actual document requested, and long Chinese text can wrap on a narrow screen. Run the journey with keyboard only and a screen reader, then repeat on a small phone. Note where focus lands after Continue or Back and whether the new page title is announced or otherwise perceivable.

Turn the indicator into an acceptance check

An acceptance session should include a first-time applicant, an applicant returning to a saved draft, and someone whose answers change the number of stages. Ask each person to identify the current stage, the remaining work, and the safe way to revise an earlier answer without coaching. Observe the actual answer rather than counting clicks alone. Check that optional steps are named as optional and that the page title, main heading, and visual list do not disagree. W3C’s labels and instructions guidance supports clear expectations for input, so the stage heading should also prepare the customer for what the page asks. If people cannot tell whether they are near submission, revise the information design before polishing the graphics.

Keep the tested state model in the product specification: what counts as current, completed, skipped, blocked and submitted; when each transition occurs; and what data survives a backward move. This gives designers, developers, translators and testers a shared reference. Revisit it whenever a new eligibility branch or document type changes the journey. A genuine progress indicator is a promise about the customer’s route through the service. When the route changes, the promise must change with it. That is the practical standard for a small business deciding whether its multi-step application actually helps rather than merely looks organized.

Handle branches and interruptions honestly

A branch can change the meaning of “completed.” If an applicant first says that no representative will act for them, the representative stage may be absent. When they later change that answer, the new stage should appear as required and incomplete, and the overall count should update without implying that the applicant has lost unrelated work. Conversely, removing a stage should not make a percentage jump look like unexplained progress. Use the stage name and current task to explain the change. The state model should be based on required information now, not on how many screens the customer happened to visit. This is particularly important when eligibility rules evolve during a service redesign.

An interrupted journey deserves a clear re-entry point. An applicant who returns through an email or account dashboard should land on the next incomplete stage, with a summary of what has already been saved. If the system cannot safely infer the next stage because earlier answers changed, show a review of the affected answer rather than guessing. The progress display should identify the draft status separately from final submission status. “Four of four stages complete” is not the same as “application submitted”; the latter depends on a deliberate final action and a recorded confirmation. Treating these as separate states prevents a customer from believing a draft was received as a formal request.

Before release, test the indicator as content and behavior. A tester should read each page title without seeing the visual component and still know the stage. Another should inspect the narrowest supported screen for clipping or confusing wrapping. A keyboard tester should use the backward links and continue forward without losing input. A screen-reader tester should hear the current position and distinguish it from completed links. Finally, compare the submitted confirmation with the preceding progress state. These tests are more informative than checking only that all circles have the expected colour. Record the actual failures and revise the stage model or copy where users cannot predict what will happen next.