The session expired and took the form with it

Walk one long form at real speed

Pick the longest form in your web app. Not the sign-up page; the one people actually dread. A quote builder, a supplier onboarding questionnaire, an insurance application, a project intake with thirty fields and three uploads.

Now fill it in the way a customer does. Not the way a developer tests it, with fake data in four minutes, but with real answers you have to look up. Stop halfway to find a document. Take a phone call. Answer a message. Let the tab sit in the background while you check something in another system.

Here's a composite version. A purchasing manager is building a quote request: twelve line items, delivery addresses for two sites, a spec sheet attached. Forty minutes in, a colleague calls. Twenty-five minutes later they come back and press Next. The app shows a login screen. They sign in. The form is empty.

The timeout protected the account. Nothing protected the forty minutes. Walk your own form like this once and you'll know whether you have the same problem.

Find where the clock starts

Before you fix anything, find out which clocks are running. There are usually more than one.

The idle timeout. The session ends after a stretch with no activity. Typing in a field may or may not count as activity, depending on whether the page talks to the server while people type.

The absolute timeout. Some apps end every session after a fixed time no matter what. Someone actively working can still be logged out mid-sentence.

Token expiry. In single-page apps, the access token behind the page may expire separately from what the user sees. The page looks alive; the next save fails.

The background tab. Browsers throttle tabs that aren't in front, so a "keep alive" ping can stop while the tab sits behind another window.

Another tab. Someone signs out of the app in one tab, or their session is ended by an admin, and the form open in a second tab finds out only when they press Save.

Write down the actual numbers for each, and who chose them. Often nobody remembers why it's fifteen minutes. Sometimes there's a real reason, like a security policy for an admin tool. Sometimes it was a default.

Warn before you end it

If a session must end, say so before it does. A small dialog a minute or two ahead: "You'll be signed out soon for security. Stay signed in?" with one button.

This isn't only courtesy. WCAG 2.2 success criterion 2.2.1, Timing Adjustable, is Level A, the baseline most accessibility requirements point to. For time limits your content sets, it asks that people can turn the limit off, adjust it, or be warned before it expires and given at least 20 seconds to extend it with a simple action, at least ten times. There are exceptions, for example real-time events like auctions and limits longer than 20 hours. A login screen that appears without warning in the middle of a form usually fails it.

Make the warning reachable for everyone: keyboard focus moves to it, screen readers announce it, and the extend button is the obvious default. Test it with the sound off and the mouse unplugged at least once.

Save as they go

The warning helps people who are at their desk. The person on the phone call won't see it. That's why the real fix is saving the work.

Save a draft on the server every time someone finishes a step or leaves a field, tied to their account, not just to the browser. A draft in the browser's local storage is better than nothing, but it disappears if they switch devices or clear their browser, and it's the wrong place for sensitive answers on a shared computer.

Show that it's saved: a quiet "Draft saved at 2:14" near the buttons is enough. Give the draft a name and a place to find it again, such as a "Your drafts" list on the dashboard. People who know their work is safe stop racing the clock.

Don't let validation block the draft. A half-finished answer, a phone number missing a digit, a required field left blank for now: all of it should save as a draft. Check it when they move to the next step or submit, not when you're trying to keep their work safe.

Uploads need care. If a file was attached before the session ended, keep it with the draft rather than asking for it again.

Bring them back to the same place

When the session has ended and they sign back in, send them straight back to the step they were on, with every answer and every attachment as they left them. WCAG 2.2 has a criterion for exactly this, 2.2.5 Re-authenticating, at Level AAA: when an authenticated session expires, the person can continue the activity without loss of data after signing in again. AAA is the strictest level and few teams are required to meet it, but for a long form it's simply the right behavior.

Restore the draft only to the same account that started it. On a shared computer, the next person to sign in shouldn't see someone else's half-finished application. And if a tool really does need a short timeout, such as an admin panel that can change money or permissions, keep the short timeout and save the draft anyway. Security and losing work aren't the same decision.

Two details make this work. Keep the return address through the login, so the app knows where to send them. And if the draft was changed elsewhere in the meantime, say so rather than silently overwriting one version with the other.

Put this into practice

This week, walk your three longest forms at real speed with a real interruption, and write down what happens to the work. Then check the numbers: idle timeout, absolute timeout, token expiry. If any form loses data when a session ends, start with server-side drafts on that form before anything else.

We build web applications around how people really work, phone calls and all. If your forms are losing people's work, talk to us.

Related work: PatientIQ.