--- title: "Re-authenticating" url: "https://barrierefreihochzwei.de/en/wcag/2-2-5-re-authenticating" language: "en" description: "WCAG 2.2.5 (AAA) requires that no input is lost when users have to sign in again. Learn how to preserve data and progress safely across expired sessions." published: "2025-01-01T08:00:00+01:00" updated: "2026-10-15T09:42:00+02:00" --- # Re-authenticating When time runs out, progress has to stay. - **Erfolgskriterium:** 2.2.5 - **Prinzip:** Operable - **Konformitätsstufe:** Level AAA - **Erklärung beim W3C:** [www.w3.org/WAI/WCAG22/Understanding/re-a...](https://www.w3.org/WAI/WCAG22/Understanding/re-authenticating.html) Success criterion 2.2.5 # 2.2.5 Re-authenticating Level AAAOperable When time runs out, progress has to stay. ## 1. What is the goal of this criterion? Imagine you’ve been filling out an important online form for 20 minutes – and suddenly you’re signed out. Everything you entered is gone and you have to start over. Frustrating for anyone, but for people with disabilities it can make the difference between “doable” and “impossible”. The goal of Success Criterion 2.2.5 is clear: when users have to sign in again because their session has expired, they must not lose any data they entered or any progress they made. The website has to pick them up exactly where they left off. ## 2. What exactly does it require? It’s about protected areas – pages where you need to be signed in. If a session expires there and users have to sign in again: **Data is preserved:** Everything users entered – in forms, shopping carts or other interactive elements – is still there after they sign in again. **State is preserved:** Users return to where they were before the session expired – same page, same progress, same selections. **They can continue seamlessly:** After signing in, they can carry on as if the session had never expired. The criterion doesn’t prohibit session timeouts – security still matters. It only requires that a timeout doesn’t lead to data loss, whether the session ends due to inactivity or for other security reasons. ## 3. Why does it matter for accessibility? Imagine you’re using a screen reader and slowly working your way through a complex form – then the session expires and everything is lost. Or you have a motor impairment and need a long time to enter your credit card details – only to have to start all over again. Keeping data after re-authentication improves accessibility because it: - allows people with cognitive disabilities to work at their own pace without worrying about losing data, - helps screen reader users who need more time to navigate complex forms, - supports people with motor impairments who need more time for input, - relieves people with low vision who use magnification and therefore move more slowly, - lets everyone complete important tasks without stress or time pressure. And not least: it makes websites more robust for everyone – including people who simply get interrupted or run into technical problems. ## 4. How to meet the criterion It takes some planning on the server side, but it pays off in happier users. Here are the most proven approaches: **Store data on the server:** - Save input automatically before the session expires, or accept it on the next submission once the user has signed in again. - Save not just form data but the application state too (step, selections, position). - Encrypt the temporary storage and limit how long it’s kept (for example 24 hours). **Pass data through the sign-in page:** - Pass the input to the re-authentication page as hidden, encrypted fields. - Restore the previous state automatically after a successful sign-in. - Make sure sensitive information is securely encrypted. **Warn in time:** - Warn before the session expires and offer a one-click extension – [Timing Adjustable](https://barrierefreihochzwei.de/en/wcag/2-2-1-timing-adjustable) already requires this. - Show the warning as an accessible dialog that receives focus and is announced by screen readers. - Tell users up front how much inactivity could cause data loss (see [Timeouts](https://barrierefreihochzwei.de/en/wcag/2-2-6-timeouts)). **Good practice:** - Test your implementation systematically with different timeout scenarios. - Explain transparently what happens to users’ data. - Make sure the temporary storage complies with the GDPR. - Securely delete stored data after completion or after a defined period. - Make signing in again easy – without a memory test (see [Accessible Authentication (Minimum)](https://barrierefreihochzwei.de/en/wcag/3-3-8-accessible-authentication-minimum)). ## 5. Why this criterion matters for businesses Even at Level AAA, accessibility brings real benefits, not just costs. **1. Fewer abandoned processes:** People who lose their shopping cart or form data after a session expires often give up. If the data is preserved, you remove one of the most irritating stumbling blocks in online retail. **2. Stronger satisfaction and loyalty:** Nobody likes doing work twice. Anyone who has seen their data vanish after a timeout becomes wary of your website. Reliable re-authentication builds trust and saves you support requests. **3. Security and usability together:** In sensitive areas such as banking, healthcare and public administration, short session times are common. With 2.2.5 you can keep them without punishing your users. And finally: AAA criteria like 2.2.5 are not mandatory under the European Accessibility Act (EAA) or its German implementation, the Barrierefreiheitsstärkungsgesetz (BFSG), since the harmonised standard EN 301 549 references WCAG 2.1 Level AA. Implementing them is a deliberate step beyond the minimum. This is general information, not legal advice. ## 6. The success criterion in the W3C’s words > **Success Criterion 2.2.5 Re-authenticating (Level AAA)** > > When an authenticated session expires, the user can continue the activity without loss of data after re-authenticating. In short: when a session expires, users must be able to pick up where they left off without losing data after signing in again. **Official explanation from the W3C** The W3C explains every success criterion in depth – with intent, examples and techniques. [Understanding 2.2.5](https://www.w3.org/WAI/WCAG22/Understanding/re-authenticating.html) ## More criteria from “Operable” [ 2.1.1 Level A ### Keyboard When every click can also be a keystroke. ](https://barrierefreihochzwei.de/en/wcag/2-1-1-keyboard) [ 2.1.2 Level A ### No Keyboard Trap When there’s no way out. ](https://barrierefreihochzwei.de/en/wcag/2-1-2-no-keyboard-trap) [ 2.1.3 Level AAA ### Keyboard (No Exception) When everything really has to work by keyboard. ](https://barrierefreihochzwei.de/en/wcag/2-1-3-keyboard-no-exception)