WCAG 2.2.6: Tidsgränser

Vad den här regeln innebär

WCAG 2.2.6 Timeouts (Nivå AAA) kräver att användare varnas om längden på all inaktivitet som kan orsaka dataförlust, om inte data bevaras i mer än 20 timmar av användarens inaktivitet. I praktiska termer innebär detta att om din webbapplikation eller tjänst kan förlora en användares data – såsom formulärinmatningar, en kundvagn eller en pågående transaktion – på grund av att användaren har varit inaktiv under en viss tid, måste du informera användare om exakt hur lång tid de har innan dessa data går förlorade.

Kriteriet gäller alla situationer där en timeout leder till dataförlust. Vanliga exempel inkluderar sessionsutgång på bank- eller myndighetsportaler som rensar formulärdata, kundvagnar som töms efter en period av inaktivitet, flerstegsguider eller formulär som återställs när en sessionscookie går ut, och onlinetester eller bokningssystem som kastar bort delvis ifyllda svar. Den avgörande utlösaren är kombinationen av inaktivitet (inte en hård tidsgräns för att slutföra en uppgift, vilket täcks av 2.2.1) och konsekvensen dataförlust.

Vad som räknas som godkänt: En sida klarar 2.2.6 om den tydligt informerar användare i början av en session – eller innan de börjar mata in data – om den specifika inaktivitetsperiod som leder till dataförlust. Alternativt klarar en sida kravet om ingen dataförlust kan inträffa oavsett hur länge användaren är inaktiv (till exempel för att servern lagrar alla formulärdata i mer än 20 timmar, eller på obestämd tid). Att visa en varning först efter att sessionen redan har gått ut uppfyller inte kriteriet.

Vad som räknas som underkänt: En sida underkänns om den tyst förlorar användardata efter en period av inaktivitet utan att någonsin informera användaren om denna risk. Den underkänns också om en varning finns men endast presenteras i samma ögonblick som dataförlusten inträffar (för sent för att agera), eller om varningen är vag – till exempel genom att säga ”din session kan gå ut” utan att ange den faktiska inaktivitetslängd som utlöser timeouten.

Officiella undantag: Kriteriet undantar uttryckligen situationer där data bevaras i mer än 20 timmar av inaktivitet. Tröskeln 20 timmar valdes för att tillgodose användare som påbörjar en uppgift en dag och återupptar den nästa. Om ditt system på ett tillförlitligt sätt lagrar alla inmatade data på serversidan i minst 20 timmar utan att användaren behöver göra något, krävs ingen varning. Dessutom gäller inte detta kriterium för timeouter som är nödvändiga för säkerheten – till exempel ett hårt krav i lag eller föreskrift på att en session måste avslutas efter en fast period oavsett användarens agerande. I sådana fall uppmuntrar kriteriet fortfarande till transparens, men erkänner den juridiska begränsningen.

Varför det är viktigt

Timeouts utan tillräcklig varning drabbar i oproportionerligt hög grad personer med kognitiva funktionsnedsättningar, motoriska funktionsnedsättningar och personer som är blinda eller har nedsatt syn. Användare med kognitiva funktionsnedsättningar såsom dyslexi, ADHD eller traumatisk hjärnskada kan behöva avsevärt mer tid för att läsa instruktioner, formulera text eller granska information innan de skickar in ett formulär. Om en session tyst går ut medan de fortfarande arbetar, förlorar de allt arbete och måste börja om – en djupt nedslående upplevelse som kan få dem att överge uppgiften helt.

Personer med motoriska funktionsnedsättningar som är beroende av switch-styrning, ögonspårningsenheter eller andra alternativa inmatningsmetoder interagerar med gränssnitt i mycket långsammare takt än en musanvändare. Att slutföra ett omfattande skadeanmälansformulär eller en flersidig myndighetsansökan kan ta dem många gånger längre tid än vad standardinställningen för sessionstimeout förutsätter. Utan att känna till nedräkningen har de ingen möjlighet att agera – till exempel genom att spara sina framsteg eller begära en förlängning – innan deras data försvinner.

Skärmläsaranvändare står också inför en förstärkt utmaning: att navigera i komplexa formulär tar längre tid när varje fält måste läsas upp och bekräftas med tangentbordet. En session som går ut medan en användare fortfarande metodiskt arbetar sig igenom ett långt formulär är inte bara besvärlig – den kan innebära timmars förlorat arbete och ett betydande hinder för att få tillgång till viktiga tjänster.

Fundera på följande verkliga scenario: En användare med multipel skleros ansöker om en sjukersättning via en myndighetsportal. Formuläret har 12 avsnitt och kräver uppladdning av styrkande dokument. Sessionen går ut efter 15 minuter av inaktivitet, men användaren gjorde en paus mitt i avsnitt 7 för att hämta ett dokument i ett annat rum. När hen kommer tillbaka har all data rensats och hen måste börja om – utan någon förvarning om att detta skulle ske. Enligt 2.2.6 skulle portalen vara skyldig att informera användaren redan från början om att inaktivitet i mer än 15 minuter leder till dataförlust, så att hen kan planera därefter.

Utöver tillgänglighet förbättrar proaktiv information om timeout-beteende användarupplevelsen för alla och minskar avhoppsfrekvensen i viktiga konverteringsflöden såsom kassa, registrering och ansökningsformulär. Det bygger också förtroende, eftersom användare inte lämnas undrande över varför deras data försvann.

Relaterade Axe-core-regler

WCAG 2.2.6 kräver manuell testning. Det finns ingen automatiserad axe-core-regel som kan upptäcka denna överträdelse, och att förstå varför är viktigt både för testare och utvecklare.

• Manuell testning krävs – Information om sessionstimeout: Automatiserade verktyg som axe-core kan skanna DOM:en efter förekomst eller avsaknad av specifika element, attribut och textmönster, men de kan inte avgöra om en webbapplikation kommer att förlora användardata efter en period av inaktivitet. Timeout-beteendet styrs vanligtvis av sessionskonfiguration på serversidan (t.ex. en PHP- eller Node.js-session TTL), och informationen – om den finns – kan förekomma i introduktionstext, en modaldialog, en hjälpsida eller till och med i ett avsnitt med användarvillkor. Ingen statisk DOM-analys kan på ett tillförlitligt sätt koppla ihop en informations­text med det faktiska timeout-beteendet på serversidan. Ett verktyg kan inte veta om en mening som ”Av säkerhetsskäl går sessioner ut efter 15 minuter” är korrekt, gäller för den aktuella sidans data eller är placerad tillräckligt tidigt i användarresan för att vara användbar. Endast en mänsklig testare som kan interagera med applikationen, observera dess beteende över tid och utvärdera fullständigheten och tajmingen i eventuell information kan avgöra efterlevnad.
• Manuell testning krävs – Verifiering av databeständighet: Axe-core kan inte heller verifiera undantaget på 20 timmar. Huruvida data faktiskt lagras på serversidan i mer än 20 timmar – och därmed om information överhuvudtaget krävs – beror helt på backend-logik som är osynlig för ett webbläsarbaserat skanningsverktyg. Testare måste antingen granska serverkonfiguration, tala med utvecklare eller empiriskt testa genom att lämna ett delvis ifyllt formulär under en längre period och observera om data finns kvar.

Hur man testar

1. Automatiserad förskanning: Kör axe DevTools eller Lighthouse mot sidan som innehåller formuläret, kassaflödet eller annat gränssnitt för datainmatning. Även om inget av verktygen direkt kommer att flagga en överträdelse av 2.2.6, använd detta steg för att identifiera eventuella timeout-relaterade ARIA live-regioner eller dialogkomponenter som kan vara en del av varningsmekanismen, och verifiera att de i sig är tillgängliga (korrekta roller, etiketter, fokus­hantering).
2. Identifiera timeout-beteende: Tala med utvecklingsteamet eller granska konfigurationen på serversidan för att fastställa sessionens inaktivitets-timeout. Vanliga platser inkluderar webbserverns konfigurationsfiler, inställningar för applikationens sessions-middleware och dokumentation för autentiseringsleverantörer. Notera den exakta längden i minuter.
3. Kontrollera information i förväg: Ladda sidan på nytt och läs allt innehåll som presenteras för användaren innan någon datainmatning påbörjas. Leta efter en tydlig formulering – i sidans brödtext, ett inledande stycke, en banner eller en modal – som anger den exakta inaktivitets-timeouten och säger att data kommer att gå förlorade om användaren är inaktiv under den perioden. Informationen måste ange längden uttryckligen (t.ex. ”15 minuter”), inte vagt (t.ex. ”en kort stund”).
4. Testa med skärmläsare: Använd NVDA med Firefox, VoiceOver med Safari eller JAWS med Chrome och navigera sidan från allra början. Bekräfta att eventuell information om timeout är nåbar och uppläses av skärmläsaren utan att användaren aktivt behöver leta efter den. Om informationen finns i en visuellt framträdande banner, verifiera att den ligger i läsordningen före det första formulärfältet.
5. Simulera inaktivitet: Börja fylla i formuläret. Sluta sedan interagera med sidan under en period som är något kortare än timeouten och observera vad som händer. Upprepa sedan, men vänta tills efter att timeoutperioden har passerat. Notera om data går förlorade, om en varning visas innan dataförlust inträffar och om den varningen kommunicerades innan sessionen började.
6. Testa undantaget på 20 timmar: Om teamet hävdar att data bevaras i mer än 20 timmar, verifiera detta empiriskt genom att delvis fylla i ett formulär, vänta minst 20 timmar och återvända till sidan för att bekräfta att data fortfarande finns kvar. Alternativt kan du granska konfigurationen för serverns sessionslagring tillsammans med utvecklingsteamet.
7. Tangentbords- och fokustestning: Om en timeout-varningsdialog eller avisering visas, verifiera med enbart tangentbordsnavigering att den automatiskt får fokus, att dess innehåll är fullt läsbart och att användaren kan stänga den eller agera (t.ex. förlänga sessionen) utan att använda mus.

Hur man åtgärdar

Session med tyst dataförlust – Felaktig

<!-- A multi-step form with a 10-minute server session timeout.
     No warning is displayed anywhere on the page.
     After 10 minutes of inactivity, the session is destroyed
     and all entered data is lost. -->
<form action='/submit-application' method='post'>
  <h1>Benefit Application</h1>
  <label for='full-name'>Full Name</label>
  <input type='text' id='full-name' name='full-name'>
  <!-- ... many more fields ... -->
  <button type='submit'>Submit Application</button>
</form>

Session med tyst dataförlust – Korrekt

<!-- The timeout duration is disclosed clearly before any form fields.
     The disclosure is in the natural reading order so screen readers
     encounter it before the first input. -->
<main>
  <h1>Benefit Application</h1>
  <div role='note' aria-label='Session timeout notice'>
    <p>
      <strong>Important:</strong> This form will time out after
      <strong>10 minutes of inactivity</strong>, and any information
      you have entered will be lost. Please have all required documents
      ready before you begin, or save your progress regularly.
    </p>
  </div>
  <form action='/submit-application' method='post'>
    <label for='full-name'>Full Name</label>
    <input type='text' id='full-name' name='full-name'>
    <!-- ... many more fields ... -->
    <button type='submit'>Submit Application</button>
  </form>
</main>

Kassasession med vag varning – Felaktig

<!-- The warning exists but is vague — it does not state the actual
     timeout duration, making it impossible for users to plan. -->
<p class='notice'>Your session may expire due to inactivity.</p>
<form action='/checkout' method='post'>
  <label for='card-number'>Card Number</label>
  <input type='text' id='card-number' name='card-number'
         autocomplete='cc-number'>
  <button type='submit'>Place Order</button>
</form>

Kassasession med vag varning – Korrekt

<!-- The warning now states the exact duration so users can
     make an informed decision about when to begin the checkout. -->
<p class='notice'>
  For your security, your checkout session will expire after
  <strong>20 minutes of inactivity</strong>. Any payment information
  entered will need to be re-entered if the session expires.
</p>
<form action='/checkout' method='post'>
  <label for='card-number'>Card Number</label>
  <input type='text' id='card-number' name='card-number'
         autocomplete='cc-number'>
  <button type='submit'>Place Order</button>
</form>

Data bevaras på serversidan i mer än 20 timmar – Korrekt (undantag gäller)

<!-- When all form data is saved to the server continuously
     and preserved for at least 20 hours, no timeout warning
     is required by 2.2.6. This is the ideal UX pattern:
     autosave is indicated to the user for transparency. -->
<main>
  <h1>Job Application</h1>
  <p>
    Your progress is automatically saved as you type.
    You can leave and return to this form at any time within
    <strong>30 days</strong> and your answers will be preserved.
  </p>
  <form action='/apply' method='post'>
    <label for='cover-letter'>Cover Letter</label>
    <textarea id='cover-letter' name='cover-letter'></textarea>
    <p aria-live='polite' id='autosave-status'>Draft saved.</p>
    <button type='submit'>Submit Application</button>
  </form>
</main>

Vanliga misstag

• Att visa timeout-varningen endast i webbläsarkonsolen eller i en serverloggpost som är osynlig för slutanvändare – varningen måste presenteras i användargränssnittet, på en plats där användaren kommer att se den innan dataförlust inträffar.
• Att placera informationen i en sidfot, integritetspolicy eller sida med användarvillkor som användare sannolikt inte läser innan de börjar mata in data, istället för direkt på eller omedelbart före själva formuläret.
• Att använda en modaldialog för att varna användare om en förestående sessionstimeout men misslyckas med att flytta tangentbordsfokus till dialogen – tangentbords- och skärmläsaranvändare kanske aldrig blir medvetna om att varningen har dykt upp.
• Att ange en sessionslängd (t.ex. ”din session varar i 30 minuter”) istället för en inaktivitets-timeout (t.ex. ”efter 15 minuters inaktivitet kommer dina data att gå förlorade”) – detta är olika begrepp, och endast inaktivitetsutlöst dataförlust omfattas av 2.2.6.
• Att anta att kriteriet är uppfyllt bara för att en timeout-varningsmodal finns för seende användare – om modalen inte är tillgänglig via tangentbord, saknar ett tillgängligt namn eller inte aviseras via ARIA live-regioner eller fokushantering, kommer skärmläsaranvändare inte att få varningen.
• Att ställa in sessionstimeouten på serversidan till 25 timmar och dra slutsatsen att ingen information behövs, utan att verifiera att tillståndet på klientsidan eller applikationsnivå (t.ex. en Redux-store eller localStorage) inte rensas tidigare – den effektiva timeouten är den mekanism som förlorar data först.
• Att ange timeout-längden i en tooltip som bara visas vid hovring – användare som är beroende av tangentbordsnavigering eller pekskärmsenheter kanske aldrig ser informationen.
• Att förlita sig på en generell CMS- eller ramverksvarning som säger ”session expired” och visas efter att dataförlust redan har inträffat, istället för att proaktivt informera användare innan de börjar mata in data.
• Att inte ta hänsyn till användare som öppnar formuläret i en bakgrundsflik: om sessionstimern fortsätter medan fliken är inaktiv kan data gå förlorade innan användaren överhuvudtaget har haft möjlighet att interagera med formuläret. Detta är särskilt problematiskt i mobila webbläsare som aggressivt pausar bakgrundsflikar.
• Att utelämna varningen i mobilversioner eller PWA-sammanhang samtidigt som den visas i skrivbordsversionen, vilket skapar en inkonsekvent upplevelse som inte uppfyller 2.2.6 för en betydande del av användarna.

Relation till Turkiets tillgänglighetsreglering

Turkiets presidentcirkulär 2025/10, publicerat i den officiella tidningen nr 32933 den 21 juni 2025, fastställer bindande krav på webbtillgänglighet för ett brett spektrum av offentliga och privata aktörer verksamma i Turkiet. Cirkuläret föreskriver efterlevnad av WCAG 2.2 som teknisk standard och kräver att berörda aktörer uppnår minst nivå AA. WCAG 2.2.6 Timeouts är ett kriterium på nivå AAA och är därför inte direkt föreskrivet av cirkulärets grundläggande krav. Cirkulärets räckvidd och syfte skapar dock starka praktiska skäl för berörda aktörer att sträva efter AAA-efterlevnad för kriterier som 2.2.6.

De aktörer som omfattas av presidentcirkulär 2025/10 inkluderar offentliga institutioner och myndigheter, e-handelsplattformar, banker och finansiella institutioner, sjukhus och vårdgivare, teleoperatörer med fler än 200 000 abonnenter, resebyråer, privata transportföretag och privatskolor som godkänts av Ministry of National Education (MoNE). Många av dessa sektorer driver onlineportaler som innefattar just de typer av datainmatningsflöden som 2.2.6 är avsett att skydda: låneansökningar, patientintagsformulär, biljettbokningssystem, ansökningsformulär för utbildning och ansökningar om offentliga förmåner.

För banker och e-handelsplattformar i synnerhet är sessionstimeouter en rutinmässig säkerhetsåtgärd, och samspelet mellan säkerhetskrav och tillgänglighetskrav är direkt relevant. Även om en bank kan ha en regulatorisk skyldighet att avsluta inaktiva sessioner efter en fast period, står det inte i konflikt med detta säkerhetskrav att implementera WCAG 2.2.6 genom att informera om timeout-längden i förväg – det kompletterar det. Användare görs medvetna om begränsningen utan att banken behöver försvaga sin säkerhetsnivå för sessioner.

Vårdgivare och sjukhus som omfattas av cirkuläret hanterar några av de mest kritiska datainmatningsuppgifterna som finns – patienthistorikformulär, förhandsauktorisationsförfrågningar och bokningssystem för vårdbesök. Patienter med kognitiva funktionsnedsättningar eller motoriska funktionsnedsättningar som förlorar sina data mitt i ett formulär i dessa sammanhang drabbas inte bara av frustration utan riskerar även förseningar i att få vård. Att implementera 2.2.6 i dessa miljöer är ett direkt uttryck för det inkluderande serviceuppdrag som ligger till grund för cirkuläret.

Även om nivå AAA inte är juridiskt obligatorisk innebär det att uppnå den för kriterier som 2.2.6 – som kräver relativt liten implementationsinsats (att lägga till en enda, korrekt informations­text i ett formulär) men ger betydande nytta för utsatta användargrupper – en tillgänglighetspraxis i toppklass. Organisationer som vill visa sitt engagemang för digital inkludering på den turkiska marknaden, eller som förutser skärpt framtida reglering, gör klokt i att behandla 2.2.6 som ett praktiskt genomförandemål snarare än en valfri ambition.