WCAG 2.2.5: Återautentisering

Vad den här regeln innebär

WCAG 2.2.5 Re-authenticating hör till riktlinje 2.2 (Tillräckligt med tid) och är ett krav på nivå AAA. Kriteriet säger: "When an authenticated session expires, the user can continue the activity without loss of data after re-authenticating." I praktiken innebär detta att om en användare håller på att fylla i ett formulär, slutföra ett köp, skriva ett meddelande eller utföra någon flerstegsuppgift på en autentiserad plattform och deras session löper ut, måste de kunna logga in igen och fortsätta exakt där de slutade — med alla tidigare inmatade uppgifter bevarade.

Detta kriterium är nära relaterat till WCAG 2.2.1 (Timing Adjustable, nivå A) och 2.2.4 (Interruptions, nivå AAA), men det behandlar ett specifikt scenario: ögonblicket då en sessionsgräns passeras. Medan 2.2.1 kräver att du ger användare tillräckligt med tid eller låter dem förlänga sin session, hanterar 2.2.5 felscenariot — vad som händer efter att tiden har gått ut. De två samverkar: idealiskt sett både förlänger du sessionen och bevarar data om den ändå löper ut.

Ett godkänt resultat enligt detta kriterium kräver att plattformen bevarar alla användarinmatade data — textinmatningar, valda alternativ, filbilagor, kryssrutor, radioknappar och all annan formulärstatus — över en återautentisering. Efter att användaren loggat in igen måste de återföras till samma punkt i den aktivitet de utförde, med sina data intakta och uppgiften möjlig att slutföra utan upprepning.

Ett underkänt resultat uppstår när en sessionstimeout orsakar något av följande: användaren omdirigeras till en inloggningssida och skickas efter lyckad inloggning till startsidan istället för sidan de befann sig på; formulärdata som matats in före timeouten går förlorade och användaren måste mata in allt igen; delvis slutförd flerstegsguide återställs; eller användaren loggas helt enkelt ut utan någon mekanism för att återautentisera och återuppta.

Den officiella WCAG-specifikationen definierar ingen minsta sessionslängd för detta kriterium — det gäller oavsett hur lång eller kort timeoutperioden är. Observera dock att inga undantag ges för dataförlust av säkerhetsskäl; förväntningen är att implementationer hittar säkra sätt att bevara tillstånd, såsom serverside-sessionslagring kopplad till användarens identitet, eller krypterade klientbaserade token som överlever återautentiseringsflödet.

Varför det är viktigt

Sessionstimeouter som raderar data skapar en oproportionerligt stor börda för personer med funktionsnedsättning. Många användare med funktionsnedsättning behöver avsevärt mer tid för att slutföra digitala uppgifter än sina icke-funktionsnedsatta jämnåriga, och de kan ofta inte bara "skriva snabbare" eller "komma runt" en godtycklig timeout.

Användare som är blinda eller har nedsatt syn navigerar i formulär med skärmläsare, vilket i sig är långsammare än visuell skanning. En blind användare som fyller i ett långt försäkringsansökningsformulär kan lägga 20 eller 30 minuter på att noggrant navigera fält för fält, bara för att få sitt arbete utraderat när en sessionstimeout på 15 minuter utlöses. De måste sedan börja om — utan garanti för att samma sak inte händer en andra gång.

Personer med motoriska funktionsnedsättningar — såsom de som använder switch-styrning, ögonstyrningsteknik eller munpinnar — kan ta flera gånger längre tid än genomsnittet för att mata in text och navigera i formulär. En användare med ALS eller spinal muskelatrofi kan hålla på att skriva ett viktigt medicinskt remissformulär och skriva bara några få tecken per minut. Sessionstimeouter som förstör deras arbete är inte en mindre olägenhet; de kan vara ett fullständigt hinder för att slutföra nödvändiga uppgifter.

Användare med kognitiva funktionsnedsättningar, inklusive de med dyslexi, ADHD, traumatiska hjärnskador eller demens, kan behöva läsa instruktioner flera gånger, ta pauser för att bearbeta information eller helt enkelt röra sig långsammare genom flerstegsprocesser. Forskning visar konsekvent att denna grupp drabbas oproportionerligt av tidspress och dataförlust — båda förstärker den kognitiva belastningen av att försöka börja om från början.

Överväg ett konkret scenario i verkligheten: en användare med multipel skleros ansöker om en statlig funktionshinderförmån via en offentlig institutions webbportal. Ansökan har 8 steg och kräver uppladdning av medicinska dokument, inmatning av anställningshistorik och skrivande av en personlig motivering. De tar sig igenom 6 steg på 45 minuter, deras session löper ut och alla inmatade data går förlorade. De måste nu samla samma dokument igen och upprepa hela processen, och kan i slutändan avbryta ansökan helt. Detta är inte hypotetiskt — det är ett mönster som dokumenterats upprepade gånger i tillgänglighetsforskning och användartester.

Utöver funktionsnedsättning påverkar dataförlust vid sessionstimeout alla användare och har mätbara affärseffekter: övergivna kundvagnar, ofullständiga registreringar och förlorade leads. Att bevara sessionstillstånd är både ett tillgänglighetskrav och en sund UX- och konverteringsoptimeringspraxis. Enligt Baymard Institute är formuläravhopp en stor bidragande orsak till övergivna e-handelsvagnar, och oväntad dataförlust är en av de främsta angivna orsakerna till att användare inte slutför onlineköp.

Relaterade Axe-core-regler

WCAG 2.2.5 kräver endast manuell testning. Det finns inga automatiserade axe-core-regler som på ett tillförlitligt sätt kan upptäcka överträdelser av detta kriterium. Följande förklarar varför automatiserade verktyg inte räcker till och vad mänskliga testare måste göra istället:

• Ingen automatiserad regel finns för bevarande av sessionstillstånd: Axe-core och liknande automatiserade tillgänglighetsmotorer fungerar genom att inspektera den aktuella DOM:en och utvärdera statiska eller nästan statiska förhållanden såsom färgkontrastförhållanden, korrekthet i ARIA-attribut och saknad alternativtext. De kan inte simulera tidens gång, utlösa en sessionsexpiration, skicka in återautentiseringsuppgifter och sedan verifiera om tidigare inmatade data återställdes. Hela denna sekvens är ett tillståndsberoende, tidsberoende beteende som kräver en människa (eller ett skriptat end-to-end-test) för att observeras.
• Upptäckt av sessionstimeout ligger utanför statisk analys: Även om ett automatiserat verktyg skulle kunna upptäcka att en sida implementerar en sessionstimeout (till exempel genom att läsa en meta refresh-tagg eller ett JavaScript-setTimeout-anrop), kan det inte utvärdera vad som händer med användardata efter att timeouten utlöses. Beteendet för databeständighet finns i serversidans sessionshanteringslogik, inte i DOM-strukturen som automatiserade verktyg analyserar.
• Komplexitet i återautentiseringsflödet: Återautentiseringsupplevelsen kan involvera flera sidor (inloggningsformulär, MFA-prompt, omdirigering), och återställningen av tillstånd kan bero på serversidans logik, cookies, local storage eller URL-parametrar. Inget enkel-sides DOM-inspektionsverktyg kan följa detta flersidiga, multisystemflöde.
• Varför manuell testning är avgörande: En kvalificerad testare måste manuellt initiera ett autentiserat arbetsflöde, medvetet vänta på eller utlösa sessionsexpiration, slutföra återautentiseringsprocessen och sedan verifiera dataintegriteten. Detta är den enda tillförlitliga metoden för att testa överensstämmelse. Automatiserade skanningar kan användas som utgångspunkt för att flagga relaterade problem (som saknade sessionsvarningsmekanismer som omfattas av 2.2.1), men de kan inte ersätta manuell testning för 2.2.5.

Hur man testar

1. Identifiera autentiserade arbetsflöden med formulär eller flerstegsprocesser. Börja med att kartlägga alla områden på webbplatsen som kräver autentisering och involverar inmatning av användardata — kassaflöden, profilredigerare, ansökningsformulär, bokningssystem, meddelandegränssnitt och administrativa paneler. Detta är de områden med högst risk för fel enligt 2.2.5.
2. Fastställ sessionstimeoutens längd. Kontrollera serverkonfiguration, applikationsinställningar eller rådgör med utvecklingsteamet för att ta reda på när sessioner löper ut. Alternativt kan du starta en session och vänta tills du automatiskt loggas ut. Notera längden. Vanliga timeouter ligger mellan 15 minuter och 2 timmar.
3. Påbörja en uppgift och mata in omfattande data. Logga in och börja fylla i ett representativt formulär — till exempel ett flerfältsregistrerings- eller köpflöde. Mata in text i textfält, gör val och gå vidare genom eventuella guide-steg. Skicka inte formuläret.
4. Utlös sessionsexpiration. Vänta antingen på att den naturliga timeouten ska inträffa, eller — om du har utvecklaråtkomst — låt sessionen löpa ut artificiellt genom att ogiltigförklara sessionscookien i webbläsarens utvecklarverktyg (fliken Application > Cookies > ta bort sessionscookien), eller genom att låta sessionen löpa ut direkt på serversidan.
5. Observera återautentiseringsprompten. Kontrollera om webbplatsen uppmanar dig att återautentisera (godkänt) eller helt enkelt omdirigerar dig till en inloggningssida utan varning (ett relaterat användbarhetsproblem, även om 2.2.5 fokuserar på databeständighet, inte själva varningen). Försök att logga in igen.
6. Verifiera databeständighet efter inloggning. Efter lyckad återautentisering, observera vart du omdirigeras och om dina tidigare inmatade data är intakta. Om du skickas till startsidan och/eller dina formulärdata är borta, är detta ett fel enligt 2.2.5.
7. Testa med hjälpmedelsteknik. Upprepa testsekvensen ovan med NVDA med Firefox, JAWS med Chrome och VoiceOver med Safari för att säkerställa att återautentiseringsprompten är tillgänglig för skärmläsaranvändare och att det återställda sidtillståndet meddelas korrekt. En seende användare kan visuellt känna igen återställda data; en skärmläsaranvändare behöver att fokus placeras korrekt och att det återställda innehållet finns i läsordningen.
8. Testa med enbart tangentbordsnavigering. Säkerställ att hela återautentiseringsprocessen — från meddelandet om sessionsexpiration till inloggning igen och återgång till den bevarade uppgiften — kan slutföras med enbart tangentbord, utan att en mus krävs.
9. Testa med simulerade förlängda timeouter. Om möjligt, minska sessionstimeouten till 1–2 minuter i en utvecklingsmiljö och kör fullständiga användarresor för att göra testcykeln snabbare och mer upprepningsbar.

Hur man åtgärdar

Enkelt inloggningsformulär med sessionstimeout — felaktigt

<!-- 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. -->

Enkelt inloggningsformulär med sessionstimeout — korrekt

<!-- 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>

Flerstegsguide som tappar framsteg — felaktigt

<!-- 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>

Flerstegsguide som tappar framsteg — korrekt

<!-- 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>

Varning om sessionsexpiration utan databeständighet — felaktigt

<!-- 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>

Varning om sessionsexpiration utan databeständighet — korrekt

<!-- 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>

Vanliga misstag

• Omdirigering till startsidan efter återautentisering istället för den ursprungliga sidan: Det vanligaste felmönstret. Efter inloggning skickar applikationen användaren till /dashboard eller / istället för URL:en de befann sig på när sessionen löpte ut, vilket tvingar dem att manuellt navigera tillbaka till sin uppgift — och deras data är redan borta.
• Lagring av formulärtillstånd endast i JavaScript-minne eller React/Vue-komponenttillstånd: Klientsidans ramverkstillstånd överlever inte en sidomladdning som utlöses av en omdirigering till inloggningssidan vid sessionsexpiration. Tillstånd måste bevaras på serversidan eller i en lagringsmekanism (t.ex. localStorage) som pålitligt återställs vid återkomst.
• Spara en "return URL" men inte formulärdata: Vissa implementationer lagrar URL:en att omdirigera tillbaka till efter inloggning men sparar inte de faktiska formulärfältsvärdena. Användaren kommer till rätt sida men med tomma fält, vilket fortfarande bryter mot 2.2.5.
• Autospara till sessionStorage som rensas när fliken stängs: Om sessionsexpirationen gör att webbläsarfliken navigerar bort (t.ex. omdirigering till inloggning), rensas sessionStorage. Använd localStorage med ett användarnamnsbaserat namnrymd, eller helst serverside-utkastlagring.
• Att inte testa med filuppladdningsfält: Filinmatningar kan inte förifyllas av HTML av säkerhetsskäl. Om ett formulär innehåller en filuppladdning som slutfördes före sessionsexpiration, går filreferensen förlorad. Applikationer måste hantera detta genom att lagra uppladdade filreferenser på serversidan och visa användaren att deras fil fortfarande är bifogad.
• Omedelbar rensning av sparade utkastdata vid återautentisering: Vissa implementationer raderar utkastet så snart användaren loggar in, innan de verifierar att användaren faktiskt har sett och bekräftat de återställda uppgifterna. Utkastet bör bevaras tills uppgiften uttryckligen slutförs eller avbryts.
• Att inte meddela återställda data för skärmläsaranvändare: Efter återautentisering och omdirigering behöver skärmläsaranvändare en aria-live-region eller fokuserad avisering som bekräftar att deras data har återställts och att de kan fortsätta där de slutade. Utan detta kanske de inte vet att deras arbete sparades.
• Att behandla AJAX-baserade sessioner annorlunda än sidbaserade sessioner: Single-page-applikationer som använder tokenbaserad autentisering (t.ex. JWT-expiration) misslyckas ofta tyst med API-anrop när token löper ut utan att ge användaren en chans att återautentisera och återuppta. Återautentiseringsmekanismen måste vara lika robust för SPA-arkitekturer.
• Användning av <meta http-equiv='refresh'> för att tvinga utloggning utan föregående datasparande: En meta refresh som utlöses vid timeout omdirigerar omedelbart användaren utan någon serverside-bevaring av tillstånd, vilket gör dataåterställning omöjlig. Sessionshantering måste hanteras i applikationslagret med korrekt tillståndsbevarande.
• Antagandet att korta sessioner eliminerar behovet av detta kriterium: Även en sessionstimeout på 5 minuter kan drabba en långsam skrivare, en användare med kognitiv funktionsnedsättning som läser instruktioner igen, eller någon som avbryts av en vårdgivare. Längden på timeouten ändrar inte skyldigheten att bevara data över återautentisering.

Relation till Turkiets tillgänglighetsreglering

Turkiets Presidential Circular 2025/10 (publicerad i Official Gazette nr 32933 den 21 juni 2025) fastställer den nationella ramen för digital tillgänglighet och hänvisar till WCAG 2.2 som sin tekniska standardbas. Cirkuläret kräver efterlevnad för ett brett spektrum av aktörer som är verksamma i Turkiet, inklusive offentliga institutioner och myndigheter, e-handelsplattformar, banker och finansiella tjänsteleverantörer, sjukhus och privata vårdgivare, telekommunikationsföretag med 200,000 eller fler abonnenter, resebyråer, privata transportföretag och privata utbildningsinstitutioner auktoriserade av Ministry of National Education (MoNE).

WCAG 2.2.5 Re-authenticating är ett kriterium på nivå AAA, vilket innebär att det inte ingår bland de minimikrav som är juridiskt föreskrivna enligt cirkuläret (som siktar på nivå A- och AA-efterlevnad). Organisationer som vill visa ledarskap inom tillgänglighet, betjäna olika användargrupper inklusive personer med funktionsnedsättning eller positionera sig som digitala tjänsteleverantörer i toppklass bör dock behandla kriterier på nivå AAA — särskilt sådana som är så praktiskt betydelsefulla som 2.2.5 — som ambitiösa mål värda att sträva efter.

Vissa kategorier av berörda aktörer har särskilt starka skäl att implementera 2.2.5. Banker och finansiella plattformar kräver ofta att användare fyller i långa formulär för låneansökningar, kontoöppning eller investeringsprodukter, och deras säkerhetsdrivna korta sessionstimeouter skapar en direkt konflikt med skyldigheten att bevara data. Sjukhus och vårdportaler utsätter patienter för dataförlust under kritiska uppgifter som tidsbokning eller ifyllande av hälsoformulär, vilket kan få verkliga konsekvenser för kontinuiteten i vården. Offentliga institutioner som driver e-förvaltningstjänster — såsom skattedeklaration, tillståndsansökningar eller förmånsanspråk — betjänar medborgare med funktionsnedsättning som kan behöva förlängd tid för att fylla i komplexa myndighetsformulär.

Även där efterlevnad av nivå AAA inte är juridiskt krävd bör turkiska organisationer vara medvetna om att tillsynsmyndigheter, civilsamhällesorganisationer och funktionsrättsaktivister i allt högre grad granskar kvaliteten och fullständigheten i digitala tillgänglighetsimplementationer. Att dokumentera överensstämmelse med kriterier på nivå AAA såsom 2.2.5 stärker en organisations tillgänglighetsredogörelse, minskar risken för rättsprocesser och visar ett genuint engagemang för inkluderande design bortom minsta möjliga kryssruteefterlevnad. För aktörer med internationell räckvidd, särskilt de som är verksamma på EU-marknader parallellt med Turkiet, kan kriterier på nivå AAA sammanfalla med krav enligt European Accessibility Act (EAA) och relaterade nationella implementationer.