WCAG 2.2.1: Justerbar tidsbegränsning

Vad den här regeln innebär

WCAG 2.2.1 Timing Adjustable är ett framgångskriterium på nivå A under Princip 2: Hanterbar. Det anger att för varje tidsgräns som sätts av innehållet måste minst ett av följande vara sant: användaren kan stänga av tidsgränsen innan hen stöter på den; användaren kan justera tidsgränsen över ett brett intervall (minst tio gånger standardinställningen); eller användaren kan förlänga tidsgränsen med en enkel åtgärd — såsom att trycka på en tangent eller klicka på en knapp — innan tiden går ut, och blir varnad minst 20 sekunder i förväg, med möjlighet att förlänga minst tio gånger.

I praktiska termer gäller detta kriterium för alla webbgränssnitt som inför en sessions-timeout, en automatiskt avancerande karusell med tidsstyrda bilder, ett formulär som rensas eller skickas in automatiskt, en nedräkningstimer på en kassasida, en mediaspelare med tidsstyrda undertexter som inte kan pausas, eller någon annan mekanism som begränsar den tid en användare har för att slutföra en uppgift. Om din sida eller applikation sätter en timer som, när den löper ut, tar bort innehåll, loggar ut användaren eller för användaren vidare till ett nytt tillstånd utan deras samtycke, måste du erbjuda ett sätt att justera eller förlänga den gränsen.

Kriteriet definierar också tre viktiga undantag som kan tillåta att en tidsgräns kvarstår utan de justeringsmekanismer som beskrivs ovan. För det första, undantaget för realtid: om tidsgränsen är en nödvändig del av en realtidshändelse (såsom en liveauktion eller en synkron online-examen), skulle justering av tiden göra aktiviteten ogiltig, och inget alternativ är genomförbart. För det andra, undantaget för väsentlighet: om tidsgränsen är väsentlig och att förlänga den skulle göra aktiviteten ogiltig — till exempel ett tidsbegränsat färdighetstest där syftet är att mäta svarshastighet. För det tredje, undantaget för 20 timmar: om tidsgränsen är längre än 20 timmar anses bördan för användarna vara minimal och justeringskontroller krävs inte.

Ett godkänt resultat uppstår när en tidsbegränsad interaktion tillhandahåller en tydlig mekanism — helst presenterad innan gränsen nås — som gör det möjligt för användaren att inaktivera, förlänga eller justera tidsbegränsningen. Ett underkänt resultat uppstår när innehåll automatiskt löper ut, omdirigerar, loggar ut användaren eller går vidare utan att erbjuda något av de tre justeringsalternativen ovan, och inget av de tre undantagen är tillämpligt.

Varför det är viktigt

Tidsgränser påverkar personer med funktionsnedsättning oproportionerligt mycket. Användare som är beroende av skärmläsare navigerar ofta sidor långsammare än seende användare, eftersom de lyssnar på innehåll linjärt och måste utforska okända gränssnitt sekventiellt. Användare med motoriska funktionsnedsättningar — inklusive de som använder switch-styrda hjälpmedel, ögonstyrningsprogram, munpinnar eller röststyrningsprogram — kan behöva avsevärt längre tid för att fylla i ett formulärfält, bekräfta ett köp eller navigera till nästa steg. Användare med kognitiva eller inlärningssvårigheter, inklusive dyslexi, uppmärksamhetsstörningar eller minnesnedsättningar, kan behöva extra tid för att läsa, förstå och svara på instruktioner. Äldre vuxna behöver också ofta mer tid för samma uppgifter, och de utgör en snabbt växande del av den globala internetbefolkningen.

Överväg ett konkret scenario i verkligheten: en person med cerebral pares håller på att slutföra en flygbokning på en turkisk flygbolagswebbplats. Kassasessionen löper automatiskt ut efter fem minuters inaktivitet. Användaren, som skriver långsamt med en huvudpekare, har fyllt i sitt namn, passnummer och betalningsuppgifter — och sedan laddas sidan om, all data rensas och användaren skickas tillbaka till startsidan. Inte bara har deras ansträngning gått förlorad, utan deras förtroende för webbplatsen är skadat, och de kanske inte kan slutföra köpet alls. Detta är ett direkt hinder för likvärdigt deltagande i digital handel.

Effekten är bredare än enskilda användare. Enligt Världshälsoorganisationen lever cirka 1,3 miljarder människor globalt med någon form av betydande funktionsnedsättning. Enbart i Turkiet visar officiell statistik från TÜİK att över 8,5 miljoner människor har en funktionsnedsättning som påverkar dagliga aktiviteter. Tidsbegränsade gränssnitt utesluter en mätbar del av den potentiella användarbasen för varje webbapplikation.

Utöver tillgänglighet gynnar borttagning av godtyckliga tidsgränser eller att göra dem justerbara även användare i miljöer med låg bandbredd, användare med tillfälligt nedsatt motorisk funktion (till exempel en bruten arm) och användare som helt enkelt blir avbrutna under en uppgift. Användbarhetsförbättringarna är omfattande och kan minska avhoppsfrekvensen i formulär, öka konverteringsgraden på e-handelssajter och sänka volymen till kundsupport.

Relaterade Axe-core-regler

WCAG 2.2.1 kräver manuell testning. Automatiserade verktyg — inklusive axe-core, Lighthouse och liknande motorer — kan inte pålitligt upptäcka tidsrelaterade överträdelser eftersom tidsgränser ofta implementeras i sessionslogik på serversidan, JavaScript som körs asynkront eller tredjepartsintegrationer. Verktyget har inget sätt att observera att en sida kommer att löpa ut om fem minuter, eller att en karusell kommer att avancera utan användarinmatning, enbart genom att inspektera DOM:en eller köra statisk analys. Följande överväganden förklarar vad testare måste utvärdera manuellt.

• Sessions-timeouts (manuell): Testare måste vänta på eller simulera en sessions-timeout för att avgöra om sidan visar en förvarning, erbjuder en förlängningsmöjlighet och ger minst 20 sekunder för användaren att svara. Ingen automatiserad regel kan avgöra sessionens längd eller om en varningsdialog visas i tid utan att faktiskt vänta ut timeouten.
• Automatiskt avancerande karuseller och reglage (manuell): Testare måste observera om karuseller avancerar automatiskt och, om så är fallet, om en paus- eller stoppkontroll finns och kan nås med tangentbord. Axe-core kan upptäcka vissa saknade ARIA-attribut på karusellkomponenter, men kan inte avgöra om själva den tidsstyrda förflyttningen är justerbar.
• Formulär som skickas eller rensas automatiskt (manuell): Om ett formulär skickas eller rensar sitt innehåll efter en period av inaktivitet måste en testare identifiera detta beteende genom observation eller kodgranskning. DOM:en i sig avslöjar inte detta beteende för en automatiserad skanner.
• Nedräkningstimers i transaktionsflöden (manuell): Kassasidor, biljettbokningsflöden och provmiljöer innehåller ofta nedräkningstimers. Huruvida dessa timers är väsentliga (och därmed undantagna) eller om de kräver en förlängningsmekanism är en bedömningsfråga som kräver mänsklig granskning av både implementationen och affärskontexten.

Hur man testar

1. Automatiserad skanningsbaslinje: Kör axe DevTools eller Lighthouse mot sidan för att identifiera kända ARIA- eller interaktiva elementfel som kan förvärra tidsrelaterade problem. Observera att dessa verktyg inte kommer att flagga själva tidsgränsen, men de hjälper till att etablera en baslinje för andra tillgänglighetsproblem. I Chrome DevTools, öppna Lighthouse-panelen, välj Accessibility och kör granskningen. I axe DevTools, aktivera webbläsartillägget, klicka på Analyze och granska resultaten — ingen tidsbegränsningsspecifik regel kommer att visas, vilket bekräftar att manuell testning krävs.
2. Identifiera alla tidsgränser: Granska sidans JavaScript-kod, nätverksförfrågningar och sessionskonfiguration på serversidan för att identifiera varje tidsgräns. Vanliga platser inkluderar setTimeout- och setInterval-anrop i JavaScript, inställningar för sessionsutgång i backendramverk, utgångsvärden för cookies och konfigurationer för tredjepartswidgetar såsom betalningslösningar eller chattwidgetar.
3. Testa varning för sessions-timeout med NVDA + Firefox: Öppna webbplatsen i Firefox med NVDA igång. Navigera genom ett flerstegsformulär eller en autentiserad sektion. Vänta på sessionsvarningsdialogen (eller själva timeouten om ingen varning visas). Verifiera att NVDA meddelar varningen automatiskt — helst via en live region — och att användaren kan förlänga sessionen genom att trycka på Enter eller mellanslag på en fokuserad knapp utan att förlora formulärdata.
4. Testa varning för sessions-timeout med VoiceOver + Safari (macOS/iOS): Upprepa testet ovan i Safari med VoiceOver aktiverat. Använd rotorn för att navigera mellan interaktiva element och bekräfta att timeoutvarningen meddelas och att förlängningskontrollen kan nås inom 20-sekundersfönstret.
5. Testa varning för sessions-timeout med JAWS + Chrome: Upprepa med JAWS i Chrome. Bekräfta att fokus flyttas till varningsdialogen, att JAWS läser upp återstående tid och förlängningsalternativet, och att aktivering av förlängningsknappen håller sessionen vid liv utan att kräva en sidomladdning.
6. Testa med enbart tangentbord (ingen skärmläsare): Inaktivera din mus och navigera enbart med Tab, Shift+Tab, Enter och mellanslag. Bekräfta att eventuell varningsdialog kan nås med tangentbord, att förlängningsknappen kan fokuseras och att fokus återgår till rätt plats i formuläret efter att sessionen har förlängts.
7. Testa karusell- och medietiming: Identifiera eventuella automatiskt avancerande karuseller. Navigera till karusellen med Tab. Verifiera att en paus- eller stoppknapp finns och kan nås utan mus. Aktivera den och bekräfta att förflyttningen upphör. Om karusellen återupptas efter användarinteraktion, bekräfta att den inte återupptas automatiskt.
8. Verifiera undantagens tillämplighet: För varje tidsgräns som hittas, avgör om undantaget för realtid, väsentlighet eller 20 timmar är tillämpligt. Dokumentera din motivering. Om inget av undantagen är tillämpligt och ingen justeringsmekanism finns, registrera detta som ett misslyckande av WCAG 2.2.1.

Hur man åtgärdar

Sessions-timeout utan varning — felaktigt

<!-- Sessionen löper tyst ut efter 5 minuter; sidan laddas om utan varning -->
<script>
  setTimeout(function() {
    window.location.href = '/session-expired';
  }, 300000);
</script>

Sessions-timeout med varning och förlängning — korrekt

<!-- Varna användaren 60 sekunder före utgång; erbjud förlängning; annonsera via live region -->
<div
  id='session-warning'
  role='alertdialog'
  aria-modal='true'
  aria-labelledby='warning-title'
  aria-describedby='warning-desc'
  hidden
>
  <h2 id='warning-title'>Your session is about to expire</h2>
  <p id='warning-desc'>
    Your session will expire in <span id='countdown'>60</span> seconds.
    Select "Stay logged in" to continue your session.
  </p>
  <button id='extend-btn' type='button'>Stay logged in</button>
  <button id='logout-btn' type='button'>Log out now</button>
</div>

<script>
  var SESSION_DURATION = 300000; // 5 minutes
  var WARNING_BEFORE   = 60000;  // warn 60 seconds before
  var sessionTimer, warningTimer, countdownInterval;

  function startSessionTimer() {
    warningTimer = setTimeout(showWarning, SESSION_DURATION - WARNING_BEFORE);
    sessionTimer = setTimeout(expireSession, SESSION_DURATION);
  }

  function showWarning() {
    var dialog = document.getElementById('session-warning');
    dialog.hidden = false;
    document.getElementById('extend-btn').focus(); // move focus to dialog
    var seconds = 60;
    countdownInterval = setInterval(function() {
      seconds--;
      document.getElementById('countdown').textContent = seconds;
      if (seconds <= 0) clearInterval(countdownInterval);
    }, 1000);
  }

  function extendSession() {
    clearTimeout(sessionTimer);
    clearTimeout(warningTimer);
    clearInterval(countdownInterval);
    document.getElementById('session-warning').hidden = true;
    startSessionTimer();
    // Return focus to last active element
  }

  function expireSession() {
    window.location.href = '/session-expired';
  }

  document.getElementById('extend-btn').addEventListener('click', extendSession);
  document.getElementById('logout-btn').addEventListener('click', expireSession);
  startSessionTimer();
</script>

Automatiskt avancerande karusell utan kontroller — felaktigt

<!-- Bilder avancerar var 4:e sekund; ingen pausknapp; ingen tangentbordsåtkomst -->
<div class='carousel'>
  <div class='slide active'>Slide 1 content</div>
  <div class='slide'>Slide 2 content</div>
  <div class='slide'>Slide 3 content</div>
</div>

Automatiskt avancerande karusell med pausknapp — korrekt

<!-- Pausknapp stoppar automatisk förflyttning; knappens etikett uppdateras för att återspegla tillståndet -->
<section aria-roledescription='carousel' aria-label='Featured announcements'>
  <div aria-live='off' aria-atomic='true'>
    <div class='slide active' role='group' aria-roledescription='slide' aria-label='Slide 1 of 3'>
      Slide 1 content
    </div>
    <div class='slide' role='group' aria-roledescription='slide' aria-label='Slide 2 of 3'>
      Slide 2 content
    </div>
    <div class='slide' role='group' aria-roledescription='slide' aria-label='Slide 3 of 3'>
      Slide 3 content
    </div>
  </div>
  <button id='carousel-pause' type='button' aria-pressed='false'>
    Pause slideshow
  </button>
</section>

<script>
  var paused = false;
  var btn = document.getElementById('carousel-pause');
  btn.addEventListener('click', function() {
    paused = !paused;
    btn.setAttribute('aria-pressed', paused.toString());
    btn.textContent = paused ? 'Play slideshow' : 'Pause slideshow';
    // toggle the carousel's auto-advance logic accordingly
  });
</script>

Tidsbegränsad nedräkning i kassan utan förlängning — felaktigt

<!-- 10-minuters låsning i kassan; ingen förlängning erbjuds; inte ett väsentligt undantag -->
<p>Your items are reserved for: <span id='timer'>10:00</span></p>
<!-- Timer löper ut, varukorgen rensas tyst -->

Tidsbegränsad nedräkning i kassan med förlängningsalternativ — korrekt

<!-- Varna före utgång och erbjud en förlängning med ett klick -->
<p>
  Your items are reserved for:
  <span id='timer' aria-live='polite' aria-atomic='true'>10:00</span>
</p>
<div id='extend-notice' hidden role='alert'>
  <p>Your reservation expires in 2 minutes.</p>
  <button type='button' id='extend-checkout'>Give me more time</button>
</div>
<!--
  When timer reaches 2:00, reveal #extend-notice.
  Clicking the button resets the reservation timer via an API call.
  aria-live='alert' ensures screen readers announce the warning immediately.
-->

Vanliga misstag

• Visa en timeoutvarning utan hantering av tangentbordsfokus: Varningsdialogen visas visuellt men fokus flyttas aldrig till den, så användare som bara använder tangentbord och skärmläsare upptäcker aldrig att de kan förlänga sessionen innan den löper ut.
• Ge mindre än 20 sekunder att svara på en timeoutvarning: Att visa en ”Session expiring”-varning bara 10 sekunder före utloggning uppfyller inte kriteriet, som kräver att minst 20 sekunder finns tillgängliga för förlängningsåtgärden.
• Använda role='alert' på en timeoutdialog som kräver interaktion: Rollen alert är för skrivskyddade meddelanden; en dialog som kräver användarinmatning bör använda role='alertdialog' med aria-modal='true' och aria-labelledby så att skärmläsare behandlar den som en modal som kräver svar.
• Hävda undantaget för väsentlighet för en standardtimer i en e-handelsvarukorg: Att reservera varor i en varukorg i 10 minuter är en affärsmässig bekvämlighet, inte en verkligt väsentlig aktivitet där syftet är att mäta hastighet. Att tillämpa undantaget för väsentlighet här är felaktigt; en förlängningsmekanism krävs.
• Automatiskt avancera en karusell utan en synlig pausknapp som kan nås med tangentbord: Att lägga till en pausknapp som bara är synlig vid hovring, eller som saknas i Tab-ordningen, uppfyller inte kriteriet. Kontrollen måste kunna nås utan pekdon.
• Återställa timeout-räknaren vid all musrörelse men inte vid tangentbordshändelser: JavaScript som förlänger inaktivitetstimern vid mousemove-händelser men ignorerar keydown- eller focus-händelser kommer tyst att låta sessioner löpa ut för användare som bara använder tangentbord men som är aktiva på sidan.
• Förlänga sessionen via en fullständig sidomladdning: När en användare klickar på ”Stay logged in” rensar en sidomladdning all data som användaren har fyllt i i formulär. Förlängningen bör ske via ett API-anrop eller en cookie-uppdatering i bakgrunden, så att DOM-tillståndet bevaras.
• Använda setTimeout-värden som inte är konfigurerbara eller exponerade för användaren: Att hårdkoda en sessionslängd på fem minuter utan någon UI-kontroll för användaren att välja en längre varaktighet bryter mot kriteriet om inte en av de tre justeringsmekanismerna (stänga av, justera eller förlänga) finns tillgänglig.
• Underlåta att testa timeoutflödet med faktiska hjälpmedel före lansering: Utvecklare som bara testar med mus kanske inte märker att varningsdialogen är otillgänglig för skärmläsaranvändare, eftersom testning med syn inte avslöjar brister i fokus-hanteringen.
• Anta att inbäddade tredjepartswidgetar automatiskt följer kraven: Betalningslösningar, livechattwidgetar och bokningsmotorer som bäddas in via iframes eller skript inför ofta egna tidsgränser. Ansvaret för WCAG-efterlevnad för hela sidan — inklusive inbäddat innehåll du kontrollerar — ligger hos sidägaren.

Relation till Turkiets tillgänglighetsreglering

Turkiets presidentdekret 2025/10, publicerat i Officiella tidningen nr 32933 den 21 juni 2025, fastställer obligatoriska krav på webbtillgänglighet i linje med WCAG 2.2 nivå AA för ett brett spektrum av offentliga och privata aktörer som driver digitala tjänster i Turkiet. WCAG 2.2.1 Timing Adjustable är ett kriterium på nivå A, vilket innebär att det ligger på den grundläggande nivån för efterlevnad — det är ett av de första kraven som berörda aktörer måste uppfylla.

Enligt dekretet måste offentliga institutioner och myndigheter — inklusive ministerier, kommuner, universitet och statligt ägda företag — uppnå full efterlevnad inom ett år från dekretets publiceringsdatum. Privata aktörer som omfattas av regleringen har två år på sig att uppfylla kraven. Omfattningen för den privata sektorn är uttryckligen bred: den omfattar e-handelsplattformar, banker och finansiella institutioner, privata sjukhus och vårdgivare, telekommunikationsföretag med 200 000 eller fler abonnenter, resebyråer, privata passagerartransportföretag och privatskolor som verkar under tillstånd från Ministry of National Education (MoNE).

För organisationer i dessa kategorier är ett misslyckande med WCAG 2.2.1 inte bara en brist i bästa praxis — det är en juridisk bristande efterlevnad som kan leda till tillsyn från myndigheter, klagomål via officiella kanaler och skadat anseende. Tänk på de specifika affärsflöden som mest sannolikt utlöser denna överträdelse: en e-handelskassa med tidsbegränsad varukorgsreservation, en internetbankssession som tyst löper ut medan en kund fyller i ett betalningsformulär, ett sjukhus bokningssystem som löper ut innan en användare med motorisk funktionsnedsättning hinner slutföra sin registrering, eller en telekomleverantörs självbetjäningsportal som automatiskt loggar ut användare från ett avtalsadministrationsflöde. Var och en av dessa är ett plausibelt misslyckandescenario inom en aktörstyp som uttryckligen nämns i dekretet.

Organisationer bör behandla efterlevnad av WCAG 2.2.1 inte som en teknisk kryssruta utan som ett designkrav som måste hanteras på arkitekturnivå — i policys för sessionshantering, krav vid upphandling av tredjepartswidgetar och standarder för UI-komponenter — snarare än att eftermonteras i efterhand. Revisionsprogram bör inkludera manuell testning av alla tidsstyrda interaktioner, inte bara automatiserade skanningar, just eftersom automatiserade verktyg inte kan upptäcka denna typ av överträdelser utan mänsklig observation.