WCAG 2.2.5 Re-authenticating: How to Preserve Information During Login Sessions

WCAG 2.2.5 Re-authenticating requires that when a web page asks a user to re-authenticate, the site preserves information the user entered or selected before the authentication interruption. This article explains what that means, who benefits, when it applies, and how to implement and test re-authentication without losing user data.

What WCAG 2.2.5 Re-authenticating covers

The success criterion covers situations where a site interrupts an activity to ask the user to sign in again. Typical triggers include session timeout, elevated privilege checks, or a protected operation such as payment confirmation. The requirement focuses on preventing loss of information and avoiding unnecessary repetition for the user.

Who benefits and why it matters

People who use screen readers, keyboard-only users, people with short-term memory or concentration difficulties, and those who use slow assistive technologies benefit most. Losing form data or choices forces repeated typing or navigation. That adds time and increases the chance of errors.

When this applies

• When a site asks for credentials mid-task because a session expired.
• When a site requires re-authentication before an action that changes data or completes a transaction.
• When the same page or multi-page process is interrupted by an authentication requirement.

Core requirements to meet WCAG 2.2.5

• Preserve user-entered information and selections that existed immediately before re-authentication was requested.
• After successful re-authentication, restore the user to the same place in the task with the same data and selections still present.
• Avoid forcing users to manually re-enter the same information because of authentication.

Common implementation patterns

1. Multi-page forms and server redirects

Preserve in-progress data on the server or send it in a secure stateful token when redirecting to a login page. On successful login, return the user to the original form and re-populate fields from the preserved state.

2. Single-page apps (SPAs)

Use a client-side mechanism to stash form state in memory or in sessionStorage while sending the user to re-authenticate. On successful login, rehydrate the state and keep the DOM focus and scroll position where the user left off.

3. Silent token refresh

When possible, refresh authentication tokens without interrupting the user. Use background token refresh to avoid presenting a re-authentication dialog at all.

4. Auth-required modal or inline prompt

If the app shows an inline login prompt over the current content, ensure the prompt is keyboard focusable, announced to assistive tech, and that canceling the prompt leaves the underlying content and data unchanged.

Detailed accessibility requirements

• Keep form values intact. Do not clear input values, selection lists, or uploaded file references because of an auth flow.
• Restore scroll position and focus. After re-authenticating return focus to a logical place where the user can continue. Use programmatic focus management and clear focus indicators.
• Announce state changes. Use WAI-ARIA live regions or semantic markup so screen readers announce the need to re-authenticate and the success of re-authentication.
• Avoid inaccessible CAPTCHAs. If a CAPTCHA is required during re-authentication, provide an accessible alternative that meets WCAG and, where relevant, offers audio or other formats.
• Keep instructions and errors simple and linked. Associate error messages and instructions with form controls with aria-describedby or native labels.
• Maintain keyboard-only operation. All flows, including the re-authentication prompt and cancel action, must be operable with keyboard and accessible focus order.

Technical techniques that preserve data

• Session-backed drafts: Save partial form data to the server as a draft before redirecting to login.
• Encrypted client storage: Temporarily store form state in sessionStorage with short lifetime and encryption precautions for sensitive fields.
• State tokens: Encode return-state in a signed server token that the login endpoint returns after successful auth.
• POST-to-GET conversion: For traditional POST forms, save the POST payload server side and use a safe redirect back to the form with the payload rehydrated.
• Silent renewal: Use OAuth or OpenID Connect refresh tokens or silent iframe refresh where supported to avoid user-visible re-authentication.

Step-by-step example flow (practical)

1. User works on a multi-page application form.
2. The session expires and the app detects a 401 response when the user requests the next step.
3. App saves the current form data to a server draft or secure client storage.
4. App presents a login prompt that is announced by assistive tech and supports keyboard.
5. After successful login, the app restores the saved draft, returns focus to the field the user last used, and keeps validation messages intact.

Testing checklist

• Confirm that fields retain values after a forced re-authentication in each major browser.
• Test with screen readers: NVDA, JAWS, VoiceOver on macOS and iOS. Verify announcements and focus behaviour.
• Test keyboard-only: open and close the login prompt, cancel and continue working without data loss.
• Test on mobile with limited connectivity to ensure uploads and selections survive an auth round trip.
• Run security review for stored drafts. Ensure sensitive data is never left unprotected in persistent client storage.

Common mistakes to avoid

• Clearing form fields on a 401 response instead of preserving them.
• Using non-semantic modals that trap focus or are invisible to assistive tech.
• Relying on client memory only without a fallback when the browser is refreshed.
• Exposing sensitive personal data in localStorage without encryption and an expiry.

Interactions with other accessibility and privacy requirements

Preserving user data must respect privacy and security. Do not store passwords or full payment card numbers. Follow secure handling guidance from your identity platform. Also ensure the preserved state and any announcements meet WCAG 2.1 and 2.2 requirements for focus, labels, and error identification.

Quick developer checklist

• Save in-progress state server side or in ephemeral client storage.
• Use accessible login prompts: proper landmark roles, aria-labelledby, and aria-live where needed.
• Restore focus and scroll position after login.
• Provide a cancel option that returns the user to their task without data loss.
• Review security: encrypt sensitive fragments and set short lifetimes.
• Test with assistive technology and keyboard-only interaction.

Wrap-up

Meeting WCAG 2.2.5 Re-authenticating improves usability and reduces repeated effort for people who rely on assistive technologies or who have cognitive or motor challenges. Implementing server drafts, silent token refresh, or accessible inline prompts will keep users moving through tasks without losing work.

Further reading and standards to check

• WCAG 2.2 and related WCAG techniques for focus, forms, and ARIA.
• WAI-ARIA Authoring Practices for modal dialogs, live regions, and focus management.
• Security guidance from your chosen identity provider for token refresh and session handling.