A Public Form Should Survive an Interruption

A parent begins an application after dinner. One document is on the phone, another in an email, and a third must wait until a child is asleep. Forty minutes later, an upload fails. The page reloads. The answers are gone.

Nothing spectacular has broken. The server may be healthy, the form may pass its field-level checks, and the institution may never see an error. Yet the person has been asked to donate the same hour twice. For someone sharing a device, relying on an unstable connection, using assistive technology or fitting administration around care and shift work, that loss can become the point at which a right or service stops being reachable.

A public form should therefore be designed to survive an ordinary interruption. The useful principle is not “keep every session open”. It is: preserve the person’s work separately from the temporary session, explain what has been saved and for how long, and provide a route back that does not weaken privacy.

The session is not the application

Many failures begin by treating three different things as one. A browser page holds fields that have not yet travelled anywhere. A session tells the service that successive requests belong to the same visitor and is often allowed to expire for security. The application itself is the durable record that should outlive a closed tab, a dropped connection or a required re-authentication.

If progress exists only inside the browser or the live session, an interruption destroys it. A more resilient service creates a stable draft identifier early, sends small validated updates to the server as work proceeds, and records which parts arrived successfully. Uploaded files can be staged separately and associated with that draft only after the service has confirmed their receipt. Re-authentication then restores the draft rather than starting a blank form.

This separation also makes failure more legible. “Your session ended; sign in to continue the draft saved at 19:42” tells a person what happened and what remains. “Something went wrong” transfers the diagnostic burden to them. The GOV.UK Design System recommends task lists only when evidence shows that people cannot or do not want to complete a complex service in one sitting, and says multi-session services should consider allowing progress to be saved and resumed. Its service-unavailable pattern goes further: tell users whether answers were saved and how long they will remain available.

The mechanism is surprisingly modest. It does not require predicting why somebody stopped. It requires the system to acknowledge that stopping is normal.

Time limits distribute the burden

A timeout can protect a form left open on a shared or public computer. But a silent timeout does not eliminate risk; it chooses who pays for it. The institution avoids a longer live session while the applicant repeats work, re-finds documents and may miss a deadline.

The Web Content Accessibility Guidelines make this distribution visible. WCAG 2.2’s guidance on adjustable timing says that content-set time limits should generally be removable, adjustable or extendable, with specified exceptions. It explains why: blindness, low vision, dexterity impairments and cognitive limitations can make forms take longer. Where a warning and extension are used, the person should be able to return to the exact condition that existed before the warning.

Another WCAG criterion, Redundant Entry, requires information already supplied in the same process to be auto-populated or selectable, except where repetition is essential, needed for security or the information is no longer valid. Importantly, the guidance says this criterion does not itself require storage between separate sessions. That boundary is useful. Conformance is a floor; a service that people predictably complete across several sittings still needs an explicit product decision about drafts.

The practical test is not simply whether a timeout exists. It is whether the security event destroys the work. A service can close an authenticated session promptly while retaining an encrypted, access-controlled draft that requires the person to prove who they are again.

Saving everything forever is not resilience

The strongest objection is serious: a recoverable draft is another store of addresses, income details, identity documents or accounts of vulnerable circumstances. Automatic saving can expose information on a shared device, create a target for attackers, or keep incomplete disclosures longer than the applicant expects.

The answer is not indefinite retention. It is deliberate draft stewardship. Under Article 5 of the GDPR, personal data should be limited to what is necessary and kept in identifiable form no longer than necessary. A resilient design must therefore answer concrete questions: Which fields need server-side saving? Are unfinished attachments retained? When is a draft deleted? Can the person delete it sooner? Is the expiry date visible before they depend on it? What recovery route is safe for somebody who loses access to an email address?

There is no universal retention period. A low-stakes booking form and an application containing medical evidence should not inherit the same default. Nor should “save automatically” mean leaving answers readable in browser storage on a borrowed machine. A sound design separates the server-side draft from local convenience features, minimises what is stored, encrypts sensitive material, expires drafts predictably and records access. It also preserves a telephone, in-person or assisted route for people who cannot safely create an account.

This is where responsibility matters. The applicant can choose when to pause, but the institution must own the recovery design. It should not ask individuals to compensate by copying every answer into a private document—especially when that creates a second, unmanaged copy of sensitive information.

Run an interruption audit

A civic group, service team or curious resident can test this property without submitting an application or entering real personal data. Choose one public form whose start page permits a harmless trial. Stop immediately if testing could create a record, consume an appointment, trigger a legal declaration or interfere with a live service.

1. Map the promise. Before entering anything, note whether the service says how long it takes, whether progress can be saved, what account is required, when drafts expire and which alternative channel exists.
2. Use dummy, non-sensitive entries. Proceed only as far as the service clearly allows without submission. Do not upload identity documents, imitate another person or bypass authentication.
3. Introduce one ordinary interruption. Use the back button, reload a page, close and reopen the tab, or let a clearly disclosed non-critical session warning appear. Test only one condition at a time.
4. Observe the recovery. Record whether previous answers remain, whether the system identifies what was saved, whether an upload can be retried without repeating other steps, and whether returning requires re-authentication rather than a new application.
5. Check the exit. Look for a visible deletion control, expiry date, confirmation of submission and a human support route. Do not confuse the absence of an error message with successful saving.

Turn the result into a short evidence note: interruption tested, expected behaviour, observed behaviour, people likely to bear the cost, privacy risk, and the smallest repair. A useful repair might be a timeout warning that truly restores state, server-side saving after each completed section, a retryable upload queue, or one sentence that states “saved until 18 November”. If the service has a support channel, report the exact journey step without including personal data. Alkemata’s earlier article The Help Desk Is a Sensor, Not a Cost Centre explains how repeated support contacts can become maintenance evidence rather than isolated complaints.

The decision worth taking back to a service owner is precise: when a person is interrupted, which part of their work survives, who can recover it, and when is it erased? If those answers are invisible, the form is asking the public to trust a process that the interface itself cannot explain. A small interruption audit can make that hidden contract inspectable—and give an institution one repair it can actually test.