Re-authenticating
When an authenticated session ends, the user has to be able to log back in and carry on with their data intact. The trigger is not only a timeout. Being signed out because the same account turned up on another machine, or because something looked suspicious, lands in exactly the same place.
Why it matters
A long form takes longer for a lot of people, and that is precisely what makes them the ones most likely to hit the limit. Coming back to an empty form means starting again against the same clock, and the second run tends to fail for the reason the first one did. The fix is not exotic. W3C's own example describes a checkout where the server had already accepted and stored the submission even though the session had timed out, so logging back in put the shopper at the same step with the same information.
Who this rule protects
Anybody who works through a form more slowly. W3C names people with cognitive limitations who read slowly, screen reader users working through a complicated form, and people using alternative input devices.
How to check it yourself
- Start a long form, leave it until the session drops, then log back in.
- Check whether your entries survived.
- Check whether you can carry on where you left off, with the data still there. Landing on a dashboard is only a failure if there is no route back into the work.
- Repeat the test with a security logout. Sign in on a second device and see what happens to the first one.
Failures we see most often
- The form clears completely on re-authentication.
- A second sign-in elsewhere kills the first session and takes the half-finished work with it.
- The user gets dropped at a dashboard with no route back to where they were.
Who this one is for
Read from this rule's own note above, so the grouping and the note cannot disagree.
- Blind and screen reader userspeople who cannot see the screen
- Cognitive and learningpeople for whom the difficulty is understanding, remembering, or staying with it
How to fix it
- Save the data server-side so it is there after the user re-authenticates, which is the first of the two techniques W3C names.
- Or carry it through the login itself, encoded as hidden or encrypted data in the re-authorization page, which suits an application holding no session state.
- Re-authenticate in a second window and leave the first one alive with the work still in it. That is W3C's other example, and it is often the cheapest fix in a single-page application.
Step-by-step fix guides (3)
Passes vs. fails
Passes
The same application saves as a draft and restores on login, at the page the user left.
Fails
A 12-page grant application empties out completely when the session drops.
In audits and lawsuits
This is Level AAA and the one AAA timing criterion worth pushing regardless of whether AAA is the goal, because it is ordinary server-side work and it removes a barrier that is close to absolute. One thing to be clear about with a client. Fixing re-authentication does not discharge criterion 2.2.1, which is Level A, is in scope for every audit we sell, and asks that the user be able to turn off, adjust or extend the limit in the first place. W3C says so directly.