WCAG 2.2.5 Re-authenticating: Preserve User Data After Session Timeout

What This Criterion Requires

WCAG 2.2.5 requires that when an authenticated session expires, the user can continue the activity without loss of data after re-authenticating. This criterion addresses a common frustration for all users but is especially critical for people with disabilities who may need significantly more time to complete tasks. A person using a screen reader, switch device, or voice recognition software may take considerably longer to fill out a form or complete a multi-step process. If their session times out and they lose all entered data upon re-authenticating, they face a disproportionate burden. The requirement applies to any activity that involves user-submitted data within an authenticated session, including form submissions, shopping carts, document editing, and multi-step workflows. Implementations typically involve server-side session storage, temporary data persistence, or client-side storage mechanisms that preserve the user state across the authentication boundary. Meeting this criterion ensures that session management policies do not create unnecessary barriers for users who work at different speeds.

Why It Matters

Session timeouts are a security necessity for many web applications, but they create a particularly harsh penalty for users with disabilities. Consider a user with a motor disability who takes 45 minutes to complete a form that most users finish in 10 minutes. If the session times out at 30 minutes and the user loses all entered data, they must start over from scratch, potentially facing another timeout. This creates a cycle of frustration that can make the application effectively unusable. Similarly, users with cognitive disabilities may need to pause frequently, look up information, or take breaks during complex tasks. Users of assistive technology often navigate more slowly through form fields, dropdown menus, and multi-step wizards. Without data preservation across re-authentication, these users face a discriminatory time penalty that does not affect users who can complete tasks quickly. Preserving data after re-authentication is also good practice for all users who may experience unexpected session timeouts due to network issues or inactivity.

Common Failures and How to Fix Them

// Session expired - redirect to login, then back to empty form
app.get('/application', requireAuth, (req, res) => {
  res.render('application', { formData: {} });
});

// Preserve form data in server session before timeout
app.post('/save-draft', (req, res) => {
  req.session.formDraft = req.body;
  res.json({ saved: true });
});

app.get('/application', requireAuth, (req, res) => {
  res.render('application', {
    formData: req.session.formDraft || {}
  });
});

// Cart stored only in session memory
function getCart(req) {
  return req.session.cart || [];
}
// Session expires = cart gone

// Cart persisted to database, linked to user account
function getCart(userId) {
  return db.carts.findOne({ userId });
}
// Cart survives session expiry and re-authentication

// Wizard progress only in session
app.get('/wizard/step/:n', requireAuth, (req, res) => {
  const step = parseInt(req.params.n);
  res.render('wizard-step-${step}', { data: {} });
});

// Wizard progress persisted per user
app.get('/wizard/step/:n', requireAuth, async (req, res) => {
  const progress = await db.wizardProgress.findOne({
    userId: req.user.id
  });
  const step = parseInt(req.params.n);
  res.render('wizard-step-${step}', {
    data: progress?.steps[step] || {}
  });
});

How to Test

1. Start filling out a form or begin a multi-step process in an authenticated session.
2. Allow the session to expire naturally or manually clear the session cookie to simulate a timeout.
3. Re-authenticate by logging back in with valid credentials.
4. Verify that all previously entered data is preserved and the user can continue from where they left off.
5. Test with shopping carts, document editors, and other stateful interactions to confirm data persistence across re-authentication.

CMS-Specific Guidance

This criterion commonly causes issues on these platforms:

• Wordpress Accessibility Checklist
• Shopify Accessibility Checklist
• Magento Accessibility Checklist

Further Reading

• Accessible Forms Guide
• Accessible Ecommerce Checkout Guide
• Keyboard Navigation Testing

Related WCAG Criteria

• WCAG 2.2.1
• WCAG 2.2.3
• WCAG 3.3.4