WCAG 2.2.5: Re-authenticating

What This Rule Means

WCAG 2.2.5 Re-authenticating belongs to Guideline 2.2 (Enough Time) and is a Level AAA requirement. The criterion states: "When an authenticated session expires, the user can continue the activity without loss of data after re-authenticating." In practical terms, this means that if a user is in the middle of filling out a form, completing a purchase, composing a message, or performing any multi-step task on an authenticated platform and their session times out, they must be able to log back in and pick up exactly where they left off — with all previously entered data preserved.

This criterion is closely related to WCAG 2.2.1 (Timing Adjustable, Level A) and 2.2.4 (Interruptions, Level AAA), but it addresses a specific scenario: the moment a session boundary is crossed. While 2.2.1 asks you to give users enough time or let them extend their session, 2.2.5 handles the failure case — what happens after the time has elapsed. The two work together: ideally you both extend the session and preserve data if it does expire.

A pass under this criterion requires that the platform preserve all user-entered data — text inputs, selected options, file attachments, checkboxes, radio selections, and any other form state — across a re-authentication event. After the user logs back in, they must be returned to the same point in the activity they were performing, with their data intact and the task completable without repetition.

A fail occurs when a session timeout causes any of the following: the user is redirected to a login page and upon successful login is sent to the homepage instead of the page they were on; form data entered before the timeout is lost and the user must re-enter everything; partially completed multi-step wizard state is reset; or the user is simply logged out with no mechanism to re-authenticate and resume.

The official WCAG specification does not define a minimum session duration for this criterion — it applies regardless of how long or short the timeout period is. However, note that no exception is provided for data loss due to security concerns; the expectation is that implementations find secure ways to preserve state, such as server-side session storage keyed to the user's identity, or encrypted client-side tokens that survive the re-authentication flow.

Why It Matters

Session timeouts that erase data create a disproportionately severe burden for people with disabilities. Many users with disabilities require significantly more time to complete digital tasks than their non-disabled peers, and they often cannot simply "type faster" or "work around" an arbitrary timeout.

Users who are blind or have low vision navigate forms using screen readers, which is inherently slower than visual scanning. A blind user completing a lengthy insurance claim form may spend 20 or 30 minutes carefully navigating field by field, only to have their work wiped out when a 15-minute session timeout fires. They must then start again — with no guarantee the same thing won't happen a second time.

People with motor impairments — such as those using switch access devices, eye-tracking technology, or mouth sticks — can take several times longer than average to enter text and navigate forms. A user with ALS or spinal muscular atrophy may be composing a critical medical referral form and typing just a few characters per minute. Session timeouts that destroy their work are not a minor inconvenience; they can be a complete barrier to completing essential tasks.

Users with cognitive disabilities, including those with dyslexia, ADHD, traumatic brain injuries, or dementia, may need to re-read instructions multiple times, take breaks to process information, or simply move more slowly through multi-step processes. Research consistently shows this population is disproportionately affected by time pressure and data loss — both of which compound the cognitive load of attempting to start over from scratch.

Consider a concrete real-world scenario: a user with multiple sclerosis is applying for a government disability benefit through a public institution's web portal. The application has 8 steps and requires uploading medical documents, entering employment history, and writing a personal statement. They get through 6 steps in 45 minutes, their session expires, and all their entered data is lost. They must now gather the same documents again and repeat the entire process, potentially abandoning the application altogether. This is not a hypothetical — it is a pattern documented repeatedly in accessibility research and user testing.

Beyond disability, data loss on session timeout affects all users and has measurable business impacts: abandoned shopping carts, incomplete registrations, and lost leads. Preserving session state is both an accessibility imperative and a sound UX and conversion optimization practice. According to the Baymard Institute, form abandonment is a major contributor to e-commerce cart abandonment rates, and unexpected data loss is one of the top cited reasons users do not complete online purchases.

Related Axe-core Rules

WCAG 2.2.5 requires manual testing only. There are no automated axe-core rules that can reliably detect violations of this criterion. The following explains why automated tools fall short and what human testers must do instead:

• No automated rule exists for session state preservation: Axe-core and similar automated accessibility engines operate by inspecting the current DOM and evaluating static or near-static conditions such as color contrast ratios, ARIA attribute correctness, and missing alternative text. They cannot simulate the passage of time, trigger a session expiry event, submit re-authentication credentials, and then verify whether previously entered data was restored. This entire sequence is a stateful, time-dependent behavior that requires a human (or a scripted end-to-end test) to observe.
• Session timeout detection is out of scope for static analysis: Even if an automated tool could detect that a page implements a session timeout (for example by reading a meta refresh tag or a JavaScript setTimeout call), it cannot evaluate what happens to user data after the timeout fires. The data preservation behavior lives in server-side session management logic, not in the DOM structure that automated tools analyze.
• Re-authentication flow complexity: The re-authentication experience may involve multiple pages (login form, MFA prompt, redirect), and the state restoration may depend on server-side logic, cookies, local storage, or URL parameters. No single-page DOM inspection tool can trace this multi-page, multi-system flow.
• Why manual testing is essential: A qualified tester must manually initiate an authenticated workflow, deliberately wait for or trigger session expiration, complete the re-authentication process, and then verify data integrity. This is the only reliable method to test conformance. Automated scans can be used as a starting point to flag related issues (like missing session warning mechanisms covered under 2.2.1), but they cannot replace manual testing for 2.2.5.

How to Test

1. Identify authenticated workflows with forms or multi-step processes. Begin by mapping all areas of the site that require authentication and involve user data entry — checkout flows, profile editors, application forms, booking systems, messaging interfaces, and administrative dashboards. These are the highest-risk areas for 2.2.5 failures.
2. Determine the session timeout duration. Check server configuration, application settings, or consult with the development team to find out when sessions expire. Alternatively, start a session and wait until you are automatically logged out. Note the duration. Common timeouts range from 15 minutes to 2 hours.
3. Begin a task and enter substantial data. Log in and begin filling out a representative form — for example, a multi-field registration or purchase flow. Enter text into text fields, make selections, and proceed through any wizard steps. Do not submit the form.
4. Trigger session expiration. Either wait for the natural timeout to occur, or — if you have developer access — artificially expire the session by invalidating the session cookie in the browser's developer tools (Application tab > Cookies > delete the session cookie), or by directly expiring the session server-side.
5. Observe the re-authentication prompt. Check whether the site prompts you to re-authenticate (pass) or simply redirects you to a login page without warning (a related usability issue, though 2.2.5 focuses on data preservation, not the warning itself). Attempt to log back in.
6. Verify data preservation after login. After successfully re-authenticating, observe where you are redirected and whether your previously entered data is intact. If you are sent to the homepage and/or your form data is gone, this is a failure of 2.2.5.
7. Test with assistive technologies. Repeat the above test sequence using NVDA with Firefox, JAWS with Chrome, and VoiceOver with Safari to ensure that the re-authentication prompt is accessible to screen reader users and that the restored page state is correctly announced. A sighted user might recognize restored data visually; a screen reader user needs the focus to be placed correctly and the restored content to be in the reading order.
8. Test keyboard-only navigation. Ensure that the entire re-authentication process — from the session expiry notice to logging back in to returning to the preserved task — is completable using only a keyboard, without requiring a mouse.
9. Test with extended timeout simulations. If possible, reduce the session timeout to 1–2 minutes in a development environment and run full user journey tests to make the test cycle faster and more repeatable.

How to Fix

Simple Login Form with Session Timeout — Incorrect

<!-- BAD: Session expires silently. On re-login, user is sent to homepage.
     All entered data in the checkout form is lost. -->
<form action='/checkout' method='POST' id='checkout-form'>
  <input type='text' name='full_name' placeholder='Full Name' />
  <input type='text' name='address' placeholder='Address' />
  <button type='submit'>Place Order</button>
</form>

<!-- Server-side: session expires after 10 minutes of inactivity.
     No state saved. POST redirect on login goes to /dashboard. -->

Simple Login Form with Session Timeout — Correct

<!-- GOOD: Before session expires, form state is saved server-side
     (or to sessionStorage as a fallback). After re-auth, the user
     is redirected back to the checkout page with data restored. -->

<!-- 1. JavaScript saves form state periodically to the server -->
<script>
  function saveFormState() {
    const formData = new FormData(document.getElementById('checkout-form'));
    const data = Object.fromEntries(formData.entries());
    // Save to server-side session keyed to authenticated user identity
    fetch('/api/save-draft', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ formId: 'checkout', data })
    });
  }
  // Auto-save every 60 seconds and on input change
  setInterval(saveFormState, 60000);
  document.getElementById('checkout-form')
    .addEventListener('input', saveFormState);
</script>

<!-- 2. On the server: when user re-authenticates,
     redirect to /checkout?restore=true
     which reloads saved draft data into the form -->
<form action='/checkout' method='POST' id='checkout-form'>
  <!-- Form fields are pre-populated from saved draft -->
  <input type='text' name='full_name' value='[restored value]'
         aria-label='Full Name' />
  <input type='text' name='address' value='[restored value]'
         aria-label='Address' />
  <button type='submit'>Place Order</button>
</form>

Multi-Step Wizard Losing Progress — Incorrect

<!-- BAD: Multi-step form uses only client-side state.
     Session expiry wipes wizard progress completely.
     Re-login sends user to step 1 with no data. -->

<div id='wizard'>
  <div class='step active' id='step-3'>
    <h2>Step 3 of 5: Employment History</h2>
    <textarea name='employment_history'>Typed content here...</textarea>
  </div>
</div>

<script>
  // State is only in JavaScript variables — lost on session expiry
  let wizardState = { step: 3, data: {} };
</script>

Multi-Step Wizard Losing Progress — Correct

<!-- GOOD: Wizard state is persisted server-side at each step
     and linked to the user's account. On re-authentication,
     the server restores the user to their last saved step
     with all data intact. A visible confirmation is shown. -->

<div id='wizard'>
  <div class='step active' id='step-3'
       aria-live='polite' aria-label='Step 3 of 5: Employment History'>
    <p role='status'>
      Your progress has been restored from your last session.
    </p>
    <h2>Step 3 of 5: Employment History</h2>
    <!-- Data is pre-populated from server-side draft -->
    <textarea name='employment_history'
              aria-label='Describe your employment history'>
      Previously entered content restored here...
    </textarea>
    <!-- Wizard nav saves progress before moving to next step -->
    <button type='button' onclick='saveAndProceed()'>Next Step</button>
  </div>
</div>

<script>
  async function saveAndProceed() {
    await fetch('/api/wizard/save', {
      method: 'POST',
      body: JSON.stringify({ step: 3, data: collectStepData() }),
      headers: { 'Content-Type': 'application/json' }
    });
    goToStep(4);
  }
</script>

Session Expiry Warning Without Data Preservation — Incorrect

<!-- BAD: Site shows a countdown warning but does not save data.
     If the user misses the warning (e.g., screen reader user
     focused elsewhere), they lose all their work. -->
<div id='timeout-warning' style='display:none'>
  <p>Your session will expire in 2 minutes. <a href='/extend'>Extend</a></p>
</div>

Session Expiry Warning Without Data Preservation — Correct

<!-- GOOD: Warning uses aria-live so screen readers announce it.
     Data is saved server-side regardless of whether the user
     extends the session — so re-auth always restores state. -->
<div id='timeout-warning'
     role='alertdialog'
     aria-live='assertive'
     aria-labelledby='warning-title'
     aria-describedby='warning-desc'
     hidden>
  <h2 id='warning-title'>Session Expiring Soon</h2>
  <p id='warning-desc'>
    Your session will expire in 2 minutes. Your work has been
    saved automatically. You can extend your session or log in
    again to continue exactly where you left off.
  </p>
  <button onclick='extendSession()'>Extend Session</button>
  <button onclick='dismissWarning()'>Dismiss</button>
</div>

Common Mistakes

• Redirecting to the homepage after re-authentication instead of the original page: The most common failure pattern. After login, the application sends the user to /dashboard or / instead of the URL they were on when their session expired, forcing them to navigate back to their task manually — and their data is already gone.
• Storing form state only in JavaScript memory or React/Vue component state: Client-side framework state does not survive a page reload triggered by a session expiry redirect to the login page. State must be persisted server-side or in a storage mechanism (e.g., localStorage) that is reliably restored on return.
• Saving a "return URL" but not the form data: Some implementations store the URL to redirect back to after login but do not save the actual form field values. The user arrives at the correct page but with empty fields, which still violates 2.2.5.
• Auto-saving to sessionStorage which is cleared when the tab closes: If the session expiry causes the browser tab to navigate away (e.g., redirect to login), sessionStorage is cleared. Use localStorage with a user-keyed namespace, or preferably server-side draft storage.
• Not testing with file upload inputs: File inputs cannot be pre-populated by HTML for security reasons. If a form includes a file upload that was completed before session expiry, the file reference is lost. Applications must handle this by storing uploaded file references server-side and showing the user that their file is still attached.
• Clearing saved draft data immediately on re-authentication: Some implementations delete the draft as soon as the user logs in, before verifying the user has actually seen and confirmed the restored data. The draft should be preserved until the task is explicitly completed or cancelled.
• Not announcing restored data to screen reader users: After re-authentication and redirect, screen reader users need an aria-live region or focused announcement confirming that their data has been restored and they can continue from where they left off. Without this, they may not know their work was saved.
• Treating AJAX-based sessions differently from page-based sessions: Single-page applications using token-based auth (e.g., JWT expiry) often silently fail API calls when the token expires without giving the user a chance to re-authenticate and resume. The re-authentication mechanism must be equally robust for SPA architectures.
• Using <meta http-equiv='refresh'> to force logout without prior data save: A meta refresh that fires on timeout immediately redirects the user without any server-side state preservation, making data recovery impossible. Session management must be handled at the application layer with proper state persistence.
• Assuming short sessions eliminate the need for this criterion: Even a 5-minute session timeout can catch a slow typist, a user with a cognitive disability re-reading instructions, or someone interrupted by a caregiver. The duration of the timeout does not change the obligation to preserve data across re-authentication.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10 (published in Official Gazette No. 32933 on June 21, 2025) establishes the national framework for digital accessibility and references WCAG 2.2 as its technical standard baseline. The circular mandates conformance for a broad range of entities operating in Turkey, including public institutions and agencies, e-commerce platforms, banks and financial service providers, hospitals and private healthcare providers, telecommunications companies with 200,000 or more subscribers, travel agencies, private transport companies, and private educational institutions authorized by the Ministry of National Education (MoNE).

WCAG 2.2.5 Re-authenticating is a Level AAA criterion, which means it is not among the minimum legally mandated requirements under the Circular (which targets Level A and AA conformance). However, organizations seeking to demonstrate leadership in accessibility, serve diverse user populations including those with disabilities, or position themselves as best-in-class digital service providers should treat Level AAA criteria — especially those as practically impactful as 2.2.5 — as aspirational targets worth pursuing.

Certain categories of covered entities have particularly strong reasons to implement 2.2.5. Banks and financial platforms often require users to complete long forms for loan applications, account opening, or investment products, and their security-driven short session timeouts create direct tension with data preservation obligations. Hospitals and healthcare portals expose patients to data loss during critical tasks like appointment booking or health questionnaire completion, which can have real consequences for continuity of care. Public institutions operating e-government services — such as tax filing, permit applications, or benefit claims — serve citizens with disabilities who may need extended time to complete complex government forms.

Even where Level AAA compliance is not legally required, Turkish organizations should be aware that regulators, civil society organizations, and disability rights advocates are increasingly scrutinizing the quality and completeness of digital accessibility implementations. Documenting conformance with Level AAA criteria such as 2.2.5 strengthens an organization's accessibility statement, reduces litigation risk, and demonstrates genuine commitment to inclusive design beyond minimum checkbox compliance. For entities with international reach, particularly those operating in EU markets alongside Turkey, Level AAA criteria may intersect with requirements under the European Accessibility Act (EAA) and related national implementations.