Re-authenticating
When an authenticated session expires, the user must be able to continue without losing any data they had already entered. The session ends, but the work in progress doesn't.
What it asks
If an authenticated session expires mid-task, the user must be able to re-authenticate and resume the activity without losing any data they had entered. Form fields stay populated, the shopping basket stays full, the half-written comment stays drafted.
How to meet it
- Persist form state to the server (or to local storage with a recovery prompt) on every meaningful change, not only on submit.
- When a session expires, return a 401 to the API call but keep the user on the same page; render an in-page sign-in prompt rather than a full redirect.
- After successful re-authentication, replay the original action with the original payload. The user should experience it as if no interruption happened.
- For multi-step flows, track progress server-side keyed to the user account, not to the session token.
Common failures
- Banking transfer flows where session expiry returns the user to the login screen and the partially-filled transfer form is gone.
- Comment systems where a long reply is lost on a re-auth redirect — common on Reddit, news sites, and forums.
- Multi-step government forms that lose all entered data on session expiry, forcing a restart from page one.
- Checkout flows where the basket survives but shipping and payment details have to be re-entered.
Why it matters
This criterion is about respecting the user’s labour. Re-typing a long form is annoying for any user; for someone using a screen reader, voice control, or a switch device, it can mean another twenty to forty minutes of work — and is often the reason they give up. Most commercial sites do not yet conform, but cloud productivity apps (Google Docs, Office 365, modern banking) have largely solved this through autosave plus background re-authentication.