Accessible business forms

Replace a long form without stranding existing drafts

A form redesign changes data and navigation as well as appearance. Map saved answers, validation rules and return paths before introducing the new flow.

In this article

Inventory what users can return to

List saved drafts, bookmarked steps, pending uploads and partially completed submissions. Record the schema version and any expiry rules attached to them.

A new multi-step form may combine questions or change required fields. Decide how an older answer maps to the new model and when the user must review it. Do not fabricate missing information just to make the migration pass validation.

Preserve the original draft until the conversion succeeds. A failed upgrade should leave a recoverable record rather than an empty new form.

Test the new journey with old data

Create synthetic drafts at each significant stage, including one with a validation error and one with an uploaded file reference. Open them in the new interface and verify the appropriate step and focus target.

If the old form requested a single contact name and the new form needs separate roles, present the existing answer for confirmation rather than guessing which role it belongs to.

Check direct links and browser navigation. Returning from a later step should retain answers, and an obsolete step URL should lead to a meaningful place rather than a blank page.

Release the shared behaviour first

Stabilise field labels, error mapping, draft persistence and submission state before adding decorative changes. These behaviours should remain consistent across the redesigned steps.

Introduce the new form to a bounded audience and monitor abandoned drafts, repeated validation errors and support contacts. Compare complete journeys, not just the new screen's initial loading speed.

Keep server compatibility for supported older clients while the rollout is active. A tab opened before deployment may submit after the new version is released.

Define rollback around user work

Rolling back the page assets may not be enough if the new form writes a changed draft schema. Ensure the old version can read the supported data or provide a forward recovery path.

Retain drafts and accepted submission identities during rollback. Do not ask users to submit again merely because the interface version changed.

After migration, review the accessibility evidence for the full flow, including error and confirmation states. Reusing accessible individual controls does not automatically preserve an accessible sequence across new pages.

Primary sources

W3C WAI: forms tutorialW3C WAI: redundant entry

References checked 11 September 2026.