WCAG 2.2.3: Ingen tidsbegränsning

Vad den här regeln innebär

WCAG 2.2.3 — No Timing ligger på AAA-nivån under Riktlinje 2.2: Tillräckligt med tid. Kravet är tydligt: tid får inte vara en väsentlig del av någon händelse eller aktivitet som presenteras för användaren. Med andra ord, om ditt innehåll eller din funktionalitet innebär en tidsgräns, deadline eller någon form av tidskänslig interaktion, måste detta tidsberoende antingen kunna tas bort eller vara helt irrelevant för uppgiften — såvida inte något av de snäva undantagen gäller.

Detta kriterium går längre än kriterium 2.2.1 på nivå A (Timing Adjustable) och kriterium 2.2.2 på nivå AA (Pause, Stop, Hide). Medan dessa tidigare kriterier tillåter justerbara eller pausbara tidsgränser, kräver 2.2.3 att tid helt enkelt inte får finnas som en meningsfull begränsning alls. En användare som tar tio sekunder eller tio minuter på sig att fylla i ett formulär, navigera i en meny eller slutföra ett arbetsflöde måste nå samma resultat som en användare som blir klar direkt.

Vad som räknas som godkänt: Innehåll där ingen tidsgräns finns, eller där en eventuell tidsgräns enbart är kosmetisk och inte påverkar resultatet (till exempel en animation som loopar men inte hindrar interaktion). Innehåll som är fullt funktionellt oavsett hur lång tid användaren tar uppfyller detta kriterium.

Vad som räknas som underkänt: Sessionstimeouter som loggar ut användare efter inaktivitet; tidsbegränsade quiz eller prov där poäng eller genomförande beror på att man blir klar inom ett visst tidsfönster; utgångstider för varukorgar som raderar varor; auktionsgränssnitt med nedräkningsklockor som stänger budgivningen; engångslösenordsfält (OTP) som löper ut; CAPTCHA-utmaningar med tidsgränser; och alla interaktiva element som blir otillgängliga eller skickas automatiskt baserat på förfluten tid.

Officiella undantag definierade av WCAG: Kriteriet undantar uttryckligen två kategorier. För det första, realtidsundantag — händelser där timing är absolut inneboende i aktiviteten, såsom en liveauktion, en direktsändning eller ett realtids-multiplayerspel. För det andra, väsentliga undantag — situationer där borttagning av tidsgränsen fundamentalt skulle förändra aktiviteten. Till exempel mäter ett snabbskrivningstest i grunden hastighet, så timing är väsentlig. Utvecklare och produktägare måste dock vara rigorösa: bekvämlighet, tekniskt arv eller affärspreferenser kvalificerar inte som ”väsentliga”. Ribban är om aktiviteten skulle förlora sin kärnmening eller sitt syfte utan tidsbegränsningen.

Det är viktigt att notera att synkroniserade medier — såsom en förinspelad video med undertexter — också är undantagna, eftersom timing i mediaplayback styrs av användarens egen mediaspelare och inte innebär en begränsning av användarens möjlighet att interagera med resten av sidan.

Varför det är viktigt

Tidsgränser på webben skadar oproportionerligt användare med ett brett spektrum av funktionsnedsättningar. Effekten är inte abstrakt — för många användare är ett tidsstyrt gränssnitt i praktiken otillgängligt.

Användare med motoriska funktionsnedsättningar — inklusive de som använder switch-enheter, munpinnar, ögonstyrningsprogram eller andra alternativa inmatningsmetoder — arbetar i en fundamentalt annan takt än mus- och tangentbordsanvändare. Att slutföra ett flerstegsformulär eller navigera i en rullgardinsmeny kan ta flera gånger längre tid. En sessionstimeout eller en varukorg som löper ut automatiskt kan radera minuter av noggrant, ansträngande arbete på ett ögonblick.

Användare med kognitiva funktionsnedsättningar, inklusive dyslexi, ADHD, bearbetningsstörningar och förvärvade hjärnskador, kan behöva avsevärt mer tid för att läsa instruktioner, förstå alternativ eller formulera svar. Forskning sammanställd av Web Accessibility Initiative uppskattar att kognitiva och inlärningsrelaterade funktionsnedsättningar påverkar ungefär 15–20% av världens befolkning i någon form. För dessa användare är en nedräkningstimer inte bara stressande — den försämrar aktivt den kognitiva bearbetning som behövs för att slutföra uppgiften.

Skärmläsaranvändare som är blinda eller har nedsatt syn navigerar innehåll linjärt och måste lyssna på eller läsa igenom gränssnittselement sekventiellt. Att förstå strukturen och alternativen på en komplex sida tar längre tid än för en seende användare som skummar visuellt. Ett tidsstyrt kassaflöde som löper ut medan en blind användare noggrant granskar sin ordersammanfattning är ett direkt hinder för handel.

Användare med ångestsyndrom kan uppleva att blotta närvaron av en nedräkningstimer skapar tillräcklig kognitiv och emotionell belastning för att hindra att uppgiften slutförs, även om de tekniskt sett har tillräckligt med tid. Att ta bort timing som faktor tar bort detta hinder helt.

Ett konkret scenario från verkligheten: Tänk dig en internetbankportal som använder en fem minuters inaktivitetstimeout kombinerad med ett OTP som löper ut efter sextio sekunder. En användare med Parkinsons sjukdom som behöver assisterande inmatningsteknik för att skriva, eller en äldre användare som inte är van vid att snabbt växla mellan appar, kan finna det fysiskt omöjligt att ta emot SMS:et, byta applikation, läsa koden, byta tillbaka och ange den inom den angivna tiden. De blir utestängda från sitt eget konto — inte av säkerhetsnödvändighet, utan av en godtycklig tidsbegränsning. Att utforma OTP:t så att det förblir giltigt under en längre period (eller ta bort den hårda utgången till förmån för en ”skicka igen”-mekanism) löser problemet utan att kompromissa med säkerheten.

Utöver tillgänglighet förbättrar borttagning av onödiga tidsbegränsningar den allmänna användbarheten och minskar avhoppsfrekvensen. En e-handelskassa som inte löper ut mitt i flödet behåller fler kunder, ökar konverteringen och minskar supportbördan — vilket gör detta till en affärspositiv förändring såväl som en etisk nödvändighet.

Relaterade Axe-core-regler

WCAG 2.2.3 kräver manuell testning. Ingen automatiserad axe-core-regel mappar direkt till detta kriterium, och detta är en viktig arkitektonisk realitet att förstå.

• Manuell testning krävs — Sessions- och interaktionstiming: Automatiserade verktyg kan inte upptäcka om en webbapplikation upprätthåller en tidsgräns eftersom timinglogik implementeras i serversidigt sessionshanteringssystem, JavaScript-timers eller back-end-API-svar — inget av detta är synligt i statisk DOM-analys. Ett verktyg som axe-core inspekterar det renderade HTML:et och det tillgängliga trädet; det kan inte observera att en fetch-begäran kommer att returnera en 401 efter fem minuters inaktivitet, eller att ett JavaScript-setTimeout kommer att omdirigera användaren till en utloggningssida. Endast en mänsklig testare som interagerar med applikationen långsamt och observerar vad som händer kan avgöra om tidsbegränsningar finns och om de påverkar möjligheten att slutföra uppgifter.
• Manuell testning krävs — OTP- och CAPTCHA-utgång: Engångslösenord och tidsbegränsade verifieringsutmaningar visas i DOM:en som vanliga inmatningsfält. Nedräkningstimern, om den är synlig, kan vara en enkel textnod eller ett CSS-animerat element. Axe kan inte dra slutsatsen att inmatning av ett värde i detta fält efter nittio sekunder kommer att resultera i ett fel. En testare måste medvetet vänta längre än utgångstiden och försöka skicka in för att bekräfta om timing upprätthålls.
• Manuell testning krävs — Autosändande och auto-avancerande formulär: Vissa gränssnitt går automatiskt vidare till nästa steg eller skickar ett formulär efter en period av inaktivitet eller efter en viss tid (till exempel en enkät som går vidare till nästa fråga efter trettio sekunder). Axe-core kommer inte att flagga detta eftersom DOM-strukturen ser giltig ut; det problematiska beteendet visar sig bara under faktisk interaktion över tid.
• Manuell testning krävs — Utgång för handel och bokningar: Tidsbegränsningar för varukorgsreservationer, biljettbokningshållningar och låsning av tidsluckor för bokningar implementeras via serverlogik och återspeglas i UI:t endast som en nedräkningsvisning. Automatiserade verktyg ser en siffra som uppdateras på skärmen men kan inte avgöra om den orsakar dataförlust eller nekad åtkomst när den når noll.

Hur man testar

1. Automatiserad grundskanning: Kör axe DevTools eller Lighthouse på sidan för att identifiera eventuella relaterade tidsrelaterade överträdelser på lägre nivå (såsom de som omfattas av 2.2.1 eller 2.2.2) som kan peka dig mot områden som kräver djupare manuell granskning. Även om ingen axe-regel testar 2.2.3 direkt kan fynd kring tidsgränsvarningar eller auto-uppdatering vägleda omfattningen av din manuella granskning. I Lighthouse, granska avsnittet ”Accessibility” för eventuella tidsrelaterade flaggor.
2. Inventera alla tidsberoende funktioner: Innan testning, katalogisera systematiskt varje funktion i applikationen som kan involvera timing. Detta inkluderar: sessionshantering och inaktivitetstimeouter; OTP- och verifieringskodfält; varukorgs- eller bokningshållningar; tidsbegränsade quiz, prov eller enkäter; auktions- eller budgränssnitt; CAPTCHA-utmaningar; autosparmekanismer med inlämningsfönster; och alla synliga nedräknings- eller förloppstimrar.
3. Testa beteende vid sessionstimeout: Öppna applikationen och påbörja en uppgift som omfattar flera steg (till exempel att fylla i ett flersidigt formulär eller slutföra en kassa). Interagera inte under en period som överstiger den misstänkta timeoutgränsen. Försök sedan fortsätta. Observera om dina framsteg bevaras, om du varnas och får möjlighet att förlänga sessionen, eller om du loggas ut eller förlorar data. Godkänt kräver att antingen ingen timeout finns, att timeouten enbart är försiktighetsåtgärd och data bevaras vid återautentisering, eller att användaren får adekvat varning och kontroll.
4. Testa OTP och kodutgång: Utlös ett OTP- eller verifieringskodflöde. Vänta tills efter kodens angivna utgångstid (eller längre om ingen tid visas). Försök att ange koden. Om systemet avvisar den enbart på grund av tid är detta ett misslyckande av 2.2.3. Obs: en ”skicka igen”-mekanism i sig löser inte 2.2.3 — den ursprungliga kodens utgång innebär fortfarande timing.
5. Skärmläsartestning (NVDA + Firefox): Använd NVDA med Firefox och navigera genom alla tidsstyrda gränssnitt enbart med tangentbord och skärmläsare. Notera hur lång tid varje steg tar med den extra navigationen som hjälpmedel innebär. Gå medvetet fram i långsam takt — pausa för att lyssna på alla instruktioner, utforska alla alternativ via virtuell markör — och försök sedan skicka in eller gå vidare. Verifiera att långsam navigering inte utlöser timeout eller förlust av tillstånd.
6. Skärmläsartestning (VoiceOver + Safari på macOS): Upprepa samma långsamma navigeringstest med VoiceOver på macOS med Safari. Var särskilt uppmärksam på dynamiska nedräkningstimrar: meddelar VoiceOver återstående tid på ett sätt som skapar brådska, och misslyckas gränssnittet när tiden tar slut?
7. Skärmläsartestning (JAWS + Chrome): Använd JAWS med Chrome och testa samma flöden. JAWS-användare utgör en betydande del av professionella skärmläsaranvändare; timingproblem som påverkar NVDA-användare kommer typiskt att påverka JAWS-användare lika mycket.
8. Verifiera undantagens legitimitet: För all timing som utvecklingsteamet hävdar är ”väsentlig” eller ”realtid”, dokumentera motiveringen och bedöm om timingen verkligen är inneboende i aktivitetens syfte, eller om den skulle kunna mildras, förlängas eller tas bort utan att ändra uppgiftens grundläggande natur.

Hur man åtgärdar

Sessionstimeout — Felaktig

<!-- Session expires after 5 minutes of inactivity with no warning.
     User data is lost and they are redirected to login. -->
<script>
  setTimeout(function() {
    window.location.href = '/logout?reason=timeout';
  }, 300000);
</script>

Sessionstimeout — Korrekt

<!-- No automatic session expiry on inactivity.
     Server session is maintained as long as the browser tab is open.
     If a timeout is legally required (e.g. banking regulation),
     warn the user well in advance and offer to extend the session
     without time pressure on the extension dialog itself. -->
<div role='dialog' aria-modal='true' aria-labelledby='session-dialog-title' aria-describedby='session-dialog-desc' id='session-warning' hidden>
  <h2 id='session-dialog-title'>Your session is about to expire</h2>
  <p id='session-dialog-desc'>For your security, your session will expire due to inactivity. Would you like to stay signed in?</p>
  <button type='button' id='extend-session'>Stay signed in</button>
  <button type='button' id='end-session'>Sign out now</button>
</div>
<!-- The "Stay signed in" button itself has no expiry —
     the user can take as long as they need to find and activate it. -->

Utgående OTP-fält — Felaktigt

<!-- OTP expires in 60 seconds. After expiry, form submission
     returns an error and the user must restart the entire flow. -->
<label for='otp'>Enter the code sent to your phone</label>
<input type='text' id='otp' name='otp' autocomplete='one-time-code' inputmode='numeric' maxlength='6'>
<p aria-live='assertive'>Code expires in: <span id='countdown'>60</span> seconds</p>
<button type='submit'>Verify</button>

Utgående OTP-fält — Korrekt

<!-- OTP does not expire within a short user-facing window.
     A longer server-side validity period (e.g. 15-30 minutes) is used.
     A resend option is available but the original code remains valid.
     No countdown timer is shown, removing false urgency. -->
<label for='otp'>Enter the 6-digit code sent to your phone</label>
<input type='text' id='otp' name='otp' autocomplete='one-time-code' inputmode='numeric' maxlength='6'>
<p>The code is valid for 30 minutes. <button type='button' id='resend-otp'>Send a new code</button></p>
<button type='submit'>Verify</button>
<!-- Server invalidates the code after first successful use,
     not after a short time window. -->

Tidsbegränsat quiz — Felaktigt

<!-- Quiz auto-submits when the 10-minute timer reaches zero,
     regardless of whether the user has finished answering. -->
<div id='quiz-timer' aria-live='polite'>Time remaining: <span id='time-left'>10:00</span></div>
<form id='quiz-form'>
  <!-- quiz questions -->
  <button type='submit'>Submit Quiz</button>
</form>

Tidsbegränsat quiz — Korrekt

<!-- Quiz has no time limit unless timing is the explicit
     subject being assessed (e.g. a certified speed test).
     If an optional time indicator is shown for user reference,
     it does not trigger auto-submission or penalise slow completion. -->
<form id='quiz-form'>
  <!-- quiz questions -->
  <button type='submit'>Submit Quiz</button>
</form>
<!-- If a time reference is genuinely needed, it is informational only:
<p>Most users complete this in about 10 minutes. Take as long as you need.</p> -->

Vanliga misstag

• Att anta att sessionssäkerhet kräver en hård timeout: Många team implementerar korta inaktivitetstimeouter med hänvisning till säkerhetskrav, men de flesta säkerhetsstandarder (inklusive PCI-DSS och OWASP) tillåter användarkontrollerad sessionsförlängning. En hård utloggning utan varning eller möjlighet till förlängning är ett tillgänglighetsfel, inte en säkerhetsnödvändighet.
• Att visa en nedräkningstimer utan att ge möjlighet att stoppa eller förlänga den: Att lägga till en aria-live-region till en nedräkning gör det värre för skärmläsaranvändare — den annonserar varje sekund — utan att åtgärda det underliggande tidsproblemet. Lösningen är att ta bort begränsningen, inte att annonsera den mer tillgängligt.
• Att behandla ”skicka om kod” som en lösning på OTP-utgång: Att tillhandahålla en ”skicka igen”-knapp gör det möjligt för användare att få en ny kod men åtgärdar inte det faktum att den ursprungliga koden löpte ut på grund av timing. Tidsgränsen finns fortfarande. Den korrekta lösningen är att förlänga giltighetsfönstret för att eliminera tidspress.
• Auto-avancerande karusell- eller guide-steg efter inaktivitet: Flerstegsformulär eller guider som automatiskt går vidare till nästa steg efter en viss tid inför en tidsbegränsning. Användare som läser instruktioner eller funderar på sitt svar blir straffade. Steg får endast gå vidare genom uttrycklig användaråtgärd.
• Varukorgstimrar som raderar varor utan att bevara dem: Reservationstimrar i e-handel (”Din varukorg löper ut om 15 minuter”) bryter mot 2.2.3 när varor försvinner permanent vid utgång istället för att bara släppas från reservation. Minst bör varor sparas i en önskelista eller så bör sessionen kunna återställas.
• Att tillämpa ”realtidsundantaget” för brett: Att märka ett gränssnitt som ”realtid” för att motivera tidsbegränsningar när det inte är genuint live. En förinspelad auktionsrepris, ett statiskt budgränssnitt eller ett quiz som bara liknar ett frågesportprogram kvalificerar inte för realtidsundantaget.
• Att ignorera timing i back-end-API-svar: Team åtgärdar front-end-timers men förbiser att API:t i sig avvisar begäranden som görs efter ett visst fönster. Användaren ser ingen nedräkning men deras inlämning misslyckas tyst. Back-end-sessionshantering måste stämma överens med front-end-upplevelsen.
• Att använda setTimeout för auto-utloggning utan att spara formulärstatus: När en automatisk utloggning är oundviklig (till exempel på grund av regulatoriska krav) innebär underlåtenhet att spara användarens formulärdata före omdirigering att allt arbete går förlorat. Minst bör utkaststatus sparas och återställas efter återautentisering.
• Att blanda ihop efterlevnad av 2.2.1 med efterlevnad av 2.2.3: Att tillhandahålla en kontroll för att ”stänga av, justera eller förlänga” (som krävs av 2.2.1 nivå A) uppfyller inte 2.2.3. Nivå AAA kräver att timing inte är väsentlig — inte bara hanterbar. En tidsgräns med generös förlängning är fortfarande en tidsgräns.
• Att förbise timing i inbäddade tredjepartskomponenter: Inbäddade chattwidgetar, betalningslösningar, identitetsverifierings-SDK:er och karttjänster kan introducera egna tidsbegränsningar. Tredjepartsursprung undantar inte dessa från WCAG:s tillämpning när de integreras i ditt gränssnitt.

Relation till Turkiets tillgänglighetsreglering

Turkiets Presidential Circular 2025/10, publicerad i Officiella tidningen nr 32933 den 21 juni 2025, etablerar ett nationellt ramverk för webbtillgänglighet som refererar till WCAG 2.2 som teknisk baslinje. Cirkuläret kräver efterlevnad från ett brett spektrum av aktörer som driver digitala tjänster i Turkiet.

De aktörstyper som omfattas inkluderar offentliga institutioner och statliga organ, e-handelsplattformar, banker och finansiella tjänster, sjukhus och vårdgivare, telekommunikationsföretag med 200,000 eller fler abonnenter, resebyråer, privata transportföretag och privatskolor auktoriserade av Ministry of National Education (MoNE). Dessa organisationer måste uppfylla de tillgänglighetsstandarder som definieras i eller refereras av cirkuläret när de tillhandahåller digitala tjänster till allmänheten.

WCAG 2.2.3 — No Timing är ett kriterium på nivå AAA, och Presidential Circular 2025/10, liksom den europeiska standarden EN 301 549 som den är anpassad till, kräver nivå A- och nivå AA-efterlevnad som laglig miniminivå. Efterlevnad av nivå AAA är inte en direkt rättslig skyldighet inom detta ramverk. Att uppnå nivå AAA — och specifikt implementera 2.2.3 — erkänns dock som en indikator på tillgänglighet i toppklass och visar ett genuint engagemang för inkluderande design bortom miniminivåerna i lagstiftningen.

För vissa typer av aktörer, särskilt banker och finansiella tjänster under BDDK:s tillsyn, och e-handelsplattformar med hög transaktionsvolym, är tidsbegränsningar såsom OTP-utgång, sessionshantering och kassaflödestimers genomgående funktioner. Även där 2.2.3 inte krävs juridiskt skapar underlåtenhet att åtgärda tidsrelaterade hinder i dessa flöden en verklig diskrimineringsrisk — särskilt i takt med att turkiska tillgänglighetsmekanismer för tillsyn mognar och klagomålsförfaranden blir mer etablerade.

Offentliga institutioner och vårdgivare som betjänar användare med funktionsnedsättningar, äldre användare och användare med låg digital kompetens har ett särskilt starkt etiskt skäl att helt eliminera tidsbegränsningar. Att ta bort tidsgränser från digitala e-förvaltningstjänster och vårdportaler ligger i linje med Turkiets bredare mål för inkludering i e-förvaltning och minskar risken för framtida regulatorisk exponering i takt med att AAA-krav i offentlig upphandling blir vanligare.

Organisationer som vill positionera sina digitala produkter som fullt inkluderande — vare sig för nationellt ledarskap, internationell marknadstillgång eller upphandlingsfördelar i EU-sammanhang (där EN 301 549 och European Accessibility Act gäller) — bör betrakta efterlevnad av WCAG 2.2.3 som en strategisk investering snarare än en valfri förbättring.