2.2.5 Re-authenticating

WCAG 2.2 · 2.2.5 AAA Operable

What it requires

When an authenticated session expires, the user must be able to continue the activity without losing any data they have already entered, after re-authenticating. In short: if a login session times out, signing back in must not throw away a half-finished form, a shopping cart, or any other in-progress work.

This is a Level AAA criterion under Guideline 2.2 (Enough Time). It applies whenever a session can expire mid-task — the data the user supplied before the timeout must be preserved (or recoverable) so the activity resumes from where it left off.

  • People who work more slowly — users with cognitive, motor, or reading disabilities who are more likely to hit a session timeout before finishing.
  • Screen reader and switch users, for whom completing a long form takes longer and re-entering lost data is especially costly.
  • Anyone interrupted mid-task — re-entering data after an unexpected logout causes frustration, errors, and abandoned transactions for everyone, but the burden falls hardest on disabled users.

How to detect it

Checking re-authentication preserves data
Check How
Manual flow Start a multi-step task, let the session expire (or force it), re-authenticate, and confirm previously entered data is still present.
Keyboard / screen reader Repeat the flow using only the keyboard and a screen reader; verify focus and the restored fields are announced correctly after sign-in.
Data recovery Confirm encrypted or sensitive data is re-supplied or restored without forcing the user to retype it (e.g. server-side draft, secure token).
Automated tools Tools like axe cannot detect this — it is a stateful, flow-based behaviour that requires manual testing.

How to fix it

  1. Persist in-progress input server-side (or in secure client storage) as the user works.
  2. On session expiry, prompt the user to re-authenticate in place rather than discarding the page — for example, a modal sign-in over the existing form.
  3. After successful re-authentication, restore every field to its prior value and return focus to where the user was.
  4. Where data is too sensitive to store, capture it in a hidden field that is re-submitted with the authentication request so nothing is retyped.

A re-auth modal can preserve the form's values via hidden fields submitted on sign-in:

<form action="/reauth" method="post">
  <p>Your session expired. Sign in to continue — your answers are saved.</p>
  <input type="hidden" name="draft_id" value="9f2c...">
  <label for="pw">Password</label>
  <input id="pw" type="password" name="password" autocomplete="current-password">
  <button type="submit">Sign in and continue</button>
</form>

Copy-paste tests

Automated coverage

There is no fully automated axe-core rule for 2.2.5 Re-authenticating — whether re-authentication destroys in-progress data is a behavioural matter a scanner cannot judge. Treat this as a manual review, using the console check and steps below.

Run this in the browser console

console — find-reauth-forms.js 
// Read-only: surfaces login / re-auth forms for manual review.
const forms = [...document.querySelectorAll('form')].filter(f =>
  f.querySelector('input[type="password"], input[autocomplete*="password"]'));
console.log('Possible (re-)authentication forms:', forms.length);
console.table(forms.map(f => ({
  action: f.getAttribute('action') || '(none)',
  hasPassword: !!f.querySelector('input[type="password"]'),
  autocomplete: f.querySelector('input[autocomplete*="password"]')?.autocomplete || '(none)'
})));
forms.forEach(f => { f.style.outline = '3px solid orange'; });

What to check manually: after a session expires, confirm that re-authenticating returns the user to the same activity with all entered data preserved (no script can verify the post-login data state). Also check that any data needed to continue is not exposed where others could read it.