WCAG 2.2.5 — Re-authenticating

What this requires

When an authenticated session expires, the user must be able to continue the activity without loss of data after re-authenticating. This usually means: persist the work in progress to storage that survives the session boundary, restore it on re-login, and don't require the user to redo it. The criterion is AAA but the user need is pervasive — anyone who has ever lost a form to a session timeout has felt this one.

How AI coding tools fail this

When asked to "add a form", AI tools generate forms with no draft persistence. The form lives in component state; a session expiry unmounts the component (the redirect to login is a route change), the state is gone, and the user has nothing to come back to.

The second pattern: long forms split across multi-step wizards with session-bound state. The "next step" relies on data from the previous step held in memory or in a server session that itself expires.

The third: payment flows where the session expires after the user has entered card details but before submission. The user re-logs in and starts over — including re-entering card details, which is an extra security surface as well as a UX failure.

Passing examples

Persist drafts to local storage and restore them on mount; sync to the server when authenticated so the user can resume from another device:

const STORAGE_KEY = "application-draft";

function ApplicationForm() {
  const [data, setData] = useState<FormData>(() => {
    const raw = localStorage.getItem(STORAGE_KEY);
    return raw ? JSON.parse(raw) : initial;
  });

  useEffect(() => {
    localStorage.setItem(STORAGE_KEY, JSON.stringify(data));
  }, [data]);

  return (
    <form>
      <p aria-live="polite" className="text-sm text-muted-foreground">
        Draft auto-saved. You can sign back in and continue from this
        device.
      </p>
      {/* ... */}
    </form>
  );
}

For server-side persistence, save the draft to the user's account whenever the form has unsaved changes, and surface "draft saved" explicitly so they know it survived.

Edge cases

Payment fields (card number, CVV) typically shouldn't persist across sessions for security reasons. The criterion accepts this: re-entering specifically sensitive data is reasonable, as long as the rest of the form survives.
Multi-step wizards need persistence at every step boundary.
Server-rendered forms without client persistence still need a story for resuming. Either server-side drafts or local storage.
Anonymous-to-authenticated flows (the user starts a form before signing in) need the same persistence model.
Tabbed-out or backgrounded tabs: while not technically a session timeout, the persistence pattern usually covers this case too.

How Jeikin handles this

This is a manual review item. The dashboard records, per form, the persistence strategy in place. The scanner flags forms longer than five fields that have no detected persistence call (localStorage, sessionStorage, draft-save action) as leading indicators.

References

W3C — Understanding 2.2.5 Re-authenticating (opens in new tab)