WCAG 2.2.1: Regulacja czasu

Co Oznacza Ta Zasada

WCAG 2.2.1 Timing Adjustable to kryterium sukcesu na poziomie A w ramach Zasady 2: Operable. Stanowi ono, że dla każdego limitu czasu ustawionego przez treść co najmniej jeden z poniższych warunków musi być spełniony: użytkownik może wyłączyć limit czasu, zanim go napotka; użytkownik może dostosować limit czasu w szerokim zakresie (co najmniej dziesięciokrotność ustawienia domyślnego); lub użytkownik może przedłużyć limit czasu prostą akcją — taką jak naciśnięcie klawisza lub kliknięcie przycisku — zanim czas upłynie, przy czym jest ostrzeżony co najmniej 20 sekund wcześniej i ma możliwość przedłużenia limitu co najmniej dziesięć razy.

W praktyce kryterium to ma zastosowanie do każdego interfejsu webowego, który narzuca limit czasu sesji, automatycznie przewijający się karuzel z czasowo zmieniającymi się slajdami, formularza, który samoczynnie się czyści lub wysyła, licznika odliczającego na stronie finalizacji zakupu, odtwarzacza multimediów z czasowanymi napisami, których nie można wstrzymać, lub jakiegokolwiek innego mechanizmu, który ogranicza czas, jaki użytkownik ma na wykonanie zadania. Jeśli Twoja strona lub aplikacja ustawia timer, który po wygaśnięciu usuwa treść, wylogowuje użytkownika lub przenosi go do nowego stanu bez jego zgody, musisz zapewnić sposób na dostosowanie lub przedłużenie tego limitu.

Kryterium definiuje również trzy ważne wyjątki, które mogą pozwolić na pozostawienie limitu czasu bez mechanizmów dostosowania opisanych powyżej. Po pierwsze, wyjątek zdarzenia w czasie rzeczywistym: jeśli limit czasu jest wymaganym elementem zdarzenia w czasie rzeczywistym (takiego jak aukcja na żywo lub synchroniczny egzamin online), dostosowanie czasu unieważniłoby samo zdarzenie i żadna alternatywa nie jest wykonalna. Po drugie, wyjątek elementu istotnego: jeśli limit czasu jest istotny i jego przedłużenie unieważniłoby aktywność — na przykład w testach umiejętności na czas, gdzie celem jest pomiar szybkości reakcji. Po trzecie, wyjątek 20-godzinny: jeśli limit czasu jest dłuższy niż 20 godzin, obciążenie użytkowników uznaje się za minimalne i mechanizmy dostosowania nie są wymagane.

Spełnienie ma miejsce, gdy interakcja ograniczona czasowo zapewnia wyraźny mechanizm — najlepiej przedstawiony zanim limit zostanie napotkany — który pozwala użytkownikowi wyłączyć, przedłużyć lub dostosować ograniczenie czasowe. Niespełnienie ma miejsce, gdy treść automatycznie wygasa, przekierowuje, wylogowuje użytkownika lub przechodzi dalej bez zaoferowania któregokolwiek z trzech powyższych mechanizmów dostosowania, a żaden z trzech wyjątków nie ma zastosowania.

Dlaczego To Ma Znaczenie

Limity czasu w nieproporcjonalny sposób dotykają osoby z niepełnosprawnościami. Użytkownicy polegający na czytnikach ekranu często nawigują po stronach wolniej niż użytkownicy widzący, ponieważ słuchają treści liniowo i muszą eksplorować nieznane interfejsy sekwencyjnie. Użytkownicy z niepełnosprawnościami ruchowymi — w tym korzystający z urządzeń przełącznikowych, oprogramowania śledzącego ruch gałek ocznych, wskaźników trzymanych w ustach lub oprogramowania do sterowania głosem — mogą potrzebować znacznie więcej czasu na wypełnienie pola formularza, potwierdzenie zakupu lub przejście do kolejnego kroku. Użytkownicy z niepełnosprawnościami poznawczymi lub trudnościami w uczeniu się, w tym z dysleksją, zaburzeniami uwagi lub zaburzeniami pamięci, mogą potrzebować dodatkowego czasu na przeczytanie, zrozumienie i odpowiedź na instrukcje. Osoby starsze również często potrzebują więcej czasu na te same zadania, a stanowią szybko rosnący segment globalnej populacji użytkowników internetu.

Rozważ konkretny scenariusz z życia: osoba z porażeniem mózgowym dokonuje rezerwacji lotu na stronie tureckich linii lotniczych. Sesja finalizacji zakupu automatycznie wygasa po pięciu minutach bezczynności. Użytkownik, pisząc powoli za pomocą wskaźnika na głowę, wprowadził swoje imię i nazwisko, numer paszportu oraz dane płatności — po czym strona przeładowuje się, czyszcząc wszystkie dane i przenosząc go na stronę główną. Nie tylko jego wysiłek został utracony, ale także zaufanie do strony zostało zachwiane i może on w ogóle nie być w stanie dokończyć zakupu. Jest to bezpośrednia bariera dla równego udziału w handlu cyfrowym.

Wpływ wykracza poza pojedynczych użytkowników. Według Światowej Organizacji Zdrowia około 1,3 miliarda osób na świecie żyje z jakąś formą znaczącej niepełnosprawności. Tylko w Turcji oficjalne statystyki TÜİK wskazują, że ponad 8,5 miliona osób ma niepełnosprawność wpływającą na codzienne czynności. Interfejsy z limitami czasu wykluczają mierzalną część potencjalnej bazy użytkowników każdej aplikacji webowej.

Poza dostępnością, usunięcie arbitralnych limitów czasu lub uczynienie ich regulowalnymi przynosi korzyści także użytkownikom w środowiskach o niskiej przepustowości łącza, użytkownikom z tymczasowo ograniczoną sprawnością ruchową (na przykład z złamaną ręką) oraz użytkownikom, którym po prostu przerwano wykonywanie zadania. Ulepszenia użyteczności są szerokie i mogą zmniejszyć współczynnik porzucania formularzy, zwiększyć współczynniki konwersji w serwisach e-commerce oraz obniżyć obciążenie działów wsparcia klienta.

Powiązane Zasady Axe-core

WCAG 2.2.1 wymaga testów manualnych. Narzędzia automatyczne — w tym axe-core, Lighthouse i podobne silniki — nie mogą wiarygodnie wykrywać naruszeń związanych z czasem, ponieważ limity czasu są często implementowane w logice sesji po stronie serwera, w asynchronicznie działającym JavaScripcie lub w integracjach zewnętrznych. Narzędzie nie ma możliwości zaobserwowania, że strona wygaśnie za pięć minut lub że karuzela będzie się przewijać bez udziału użytkownika, wyłącznie poprzez inspekcję DOM lub analizę statyczną. Poniższe kwestie wyjaśniają, co testerzy muszą ocenić ręcznie.

• Limity czasu sesji (ręcznie): Testerzy muszą poczekać na wygaśnięcie sesji lub je zasymulować, aby ustalić, czy strona wyświetla wcześniejsze ostrzeżenie, oferuje opcję przedłużenia i zapewnia co najmniej 20 sekund na reakcję użytkownika. Żadna reguła automatyczna nie jest w stanie określić czasu trwania sesji ani tego, czy okno ostrzegawcze pojawia się na czas, bez faktycznego odczekania do wygaśnięcia.
• Automatycznie przewijające się karuzele i slidery (ręcznie): Testerzy muszą zaobserwować, czy karuzele przewijają się automatycznie, a jeśli tak, czy dostępny jest przycisk pauzy lub zatrzymania i czy można do niego dotrzeć za pomocą klawiatury. Axe-core może wykryć brak niektórych atrybutów ARIA w komponentach karuzeli, ale nie jest w stanie określić, czy samo czasowe przewijanie jest regulowalne.
• Formularze automatycznie wysyłane lub czyszczone (ręcznie): Jeśli formularz wysyła się lub czyści swoją zawartość po okresie bezczynności, tester musi zidentyfikować to zachowanie poprzez obserwację lub przegląd kodu. Sam DOM nie ujawnia tego zachowania skanerowi automatycznemu.
• Liczniki odliczające w procesach transakcyjnych (ręcznie): Strony finalizacji zakupu, procesy rezerwacji biletów i środowiska egzaminacyjne często zawierają liczniki odliczające. To, czy liczniki te są istotne (a więc zwolnione), czy też wymagają mechanizmu przedłużenia, jest kwestią oceny wymagającą ludzkiego przeglądu zarówno implementacji, jak i kontekstu biznesowego.

Jak Testować

1. Automatyczny skan bazowy: Uruchom axe DevTools lub Lighthouse na stronie, aby zidentyfikować znane naruszenia związane z ARIA lub elementami interaktywnymi, które mogą potęgować problemy z czasem. Zauważ, że narzędzia te nie oznaczą samego limitu czasu, ale pomagają ustalić bazę innych problemów z dostępnością. W Chrome DevTools otwórz panel Lighthouse, wybierz Accessibility i uruchom audyt. W axe DevTools aktywuj rozszerzenie przeglądarki, kliknij Analyze i przejrzyj wyniki — żadna reguła specyficzna dla czasu się nie pojawi, co potwierdza konieczność testów manualnych.
2. Identyfikacja wszystkich limitów czasu: Przejrzyj źródło JavaScript strony, żądania sieciowe i konfigurację sesji po stronie serwera, aby zidentyfikować każdy limit czasu. Typowe miejsca to wywołania setTimeout i setInterval w JavaScripcie, ustawienia wygaśnięcia sesji w frameworkach backendowych, wartości wygaśnięcia ciasteczek oraz konfiguracje widżetów zewnętrznych, takich jak procesory płatności czy widżety czatu.
3. Test ostrzeżenia o wygaśnięciu sesji z NVDA + Firefox: Otwórz stronę w Firefox z uruchomionym NVDA. Przejdź przez wieloetapowy formularz lub sekcję wymagającą uwierzytelnienia. Poczekaj na okno ostrzegawcze o wygaśnięciu sesji (lub samo wygaśnięcie, jeśli ostrzeżenie się nie pojawi). Zweryfikuj, że NVDA automatycznie ogłasza ostrzeżenie — najlepiej za pomocą regionu live — oraz że użytkownik może przedłużyć sesję, naciskając Enter lub Spację na fokusowanym przycisku, bez utraty danych formularza.
4. Test ostrzeżenia o wygaśnięciu sesji z VoiceOver + Safari (macOS/iOS): Powtórz powyższy test w Safari z włączonym VoiceOver. Użyj rotor, aby nawigować po elementach interaktywnych i potwierdź, że ostrzeżenie o wygaśnięciu jest ogłaszane oraz że kontrolka przedłużenia jest osiągalna w 20-sekundowym oknie.
5. Test ostrzeżenia o wygaśnięciu sesji z JAWS + Chrome: Powtórz test z JAWS w Chrome. Potwierdź, że fokus jest przenoszony do okna ostrzegawczego, że JAWS odczytuje pozostały czas i opcję przedłużenia oraz że aktywacja przycisku przedłużenia utrzymuje sesję przy życiu bez konieczności przeładowania strony.
6. Test wyłącznie z klawiaturą (bez czytnika ekranu): Wyłącz mysz i nawiguj wyłącznie za pomocą Tab, Shift+Tab, Enter i Spacji. Potwierdź, że każde okno ostrzegawcze jest osiągalne z klawiatury, że przycisk przedłużenia może otrzymać fokus oraz że fokus wraca we właściwe miejsce w formularzu po przedłużeniu sesji.
7. Testowanie czasu w karuzelach i mediach: Zidentyfikuj wszystkie automatycznie przewijające się karuzele. Przejdź do karuzeli za pomocą Tab. Zweryfikuj, że dostępny jest przycisk pauzy lub zatrzymania i że można do niego dotrzeć bez użycia myszy. Aktywuj go i potwierdź, że przewijanie się zatrzymuje. Jeśli karuzela wznawia działanie po interakcji użytkownika, potwierdź, że nie wznawia się automatycznie.
8. Weryfikacja zastosowania wyjątków: Dla każdego znalezionego limitu czasu ustal, czy ma zastosowanie wyjątek zdarzenia w czasie rzeczywistym, elementu istotnego lub 20-godzinny. Udokumentuj swoje rozumowanie. Jeśli żaden z wyjątków nie ma zastosowania i nie istnieje mechanizm dostosowania, odnotuj to jako naruszenie WCAG 2.2.1.

Jak Naprawić

Limit czasu sesji bez ostrzeżenia — nieprawidłowe

<!-- Session expires silently after 5 minutes; page reloads with no warning -->
<script>
  setTimeout(function() {
    window.location.href = '/session-expired';
  }, 300000);
</script>

Limit czasu sesji z ostrzeżeniem i możliwością przedłużenia — prawidłowe

<!-- Warn user 60 seconds before expiry; offer extension; announce 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>

Automatycznie przewijająca się karuzela bez kontrolek — nieprawidłowe

<!-- Slides advance every 4 seconds; no pause control; no keyboard access -->
<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>

Automatycznie przewijająca się karuzela z kontrolką pauzy — prawidłowe

<!-- Pause button stops auto-advance; button label updates to reflect state -->
<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>

Czasowe odliczanie w koszyku bez możliwości przedłużenia — nieprawidłowe

<!-- 10-minute checkout lock; no extension offered; not an essential exception -->
<p>Your items are reserved for: <span id='timer'>10:00</span></p>
<!-- Timer expires, cart is cleared silently -->

Czasowe odliczanie w koszyku z opcją przedłużenia — prawidłowe

<!-- Warn before expiry and offer a one-click extension -->
<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.
-->

Typowe Błędy

• Wyświetlanie ostrzeżenia o wygaśnięciu bez zarządzania fokusem klawiatury: Okno ostrzegawcze pojawia się wizualnie, ale fokus nigdy nie jest do niego przenoszony, więc użytkownicy korzystający wyłącznie z klawiatury i czytników ekranu nie odkrywają, że mogą przedłużyć sesję przed jej wygaśnięciem.
• Zapewnienie mniej niż 20 sekund na reakcję na ostrzeżenie o wygaśnięciu: Wyświetlenie alertu „Session expiring” tylko 10 sekund przed wylogowaniem nie spełnia kryterium, które wymaga, aby na akcję przedłużenia dostępne było co najmniej 20 sekund.
• Użycie role='alert' w oknie dialogowym limitu czasu wymagającym interakcji: Rola alert jest przeznaczona do ogłoszeń tylko do odczytu; okno dialogowe wymagające działania użytkownika powinno używać role='alertdialog' z aria-modal='true' i aria-labelledby, aby czytniki ekranu traktowały je jako modal wymagający odpowiedzi.
• Powolywanie się na wyjątek elementu istotnego dla standardowego timera koszyka e-commerce: Rezerwowanie produktów w koszyku zakupowym na 10 minut jest udogodnieniem biznesowym, a nie prawdziwą istotną aktywnością, w której celem jest pomiar szybkości. Zastosowanie tu wyjątku elementu istotnego jest nieprawidłowe; wymagany jest mechanizm przedłużenia.
• Automatyczne przewijanie karuzeli bez widocznego przycisku pauzy dostępnego z klawiatury: Dodanie przycisku pauzy, który jest widoczny tylko po najechaniu kursorem lub który jest nieobecny w kolejności Tab, nie spełnia kryterium. Kontrolka musi być osiągalna bez urządzenia wskazującego.
• Resetowanie licznika limitu czasu przy każdym ruchu myszy, ale nie przy zdarzeniach klawiatury: JavaScript, który przedłuża timer bezczynności przy zdarzeniach mousemove, ale ignoruje keydown lub focus, będzie po cichu wygaszał sesje użytkowników korzystających wyłącznie z klawiatury, którzy aktywnie pracują na stronie.
• Przedłużanie sesji poprzez pełne przeładowanie strony: Gdy użytkownik klika „Stay logged in”, przeładowanie strony czyści wszelkie dane wprowadzone w formularzach. Przedłużenie powinno następować poprzez wywołanie API lub odświeżenie ciasteczka w tle, z zachowaniem stanu DOM.
• Używanie wartości setTimeout, które nie są konfigurowalne ani udostępnione użytkownikowi: Zakodowanie na stałe długości sesji na pięć minut bez kontrolki w interfejsie, która pozwala użytkownikowi wybrać dłuższy czas trwania, narusza kryterium, chyba że dostępny jest jeden z trzech mechanizmów dostosowania (wyłączenie, regulacja lub przedłużenie).
• Brak testów przepływu limitu czasu z użyciem rzeczywistych technologii asystujących przed wdrożeniem: Deweloperzy testujący wyłącznie za pomocą myszy mogą nie zauważyć, że okno ostrzegawcze jest niedostępne dla użytkowników czytników ekranu, ponieważ testy wzrokowe nie ujawniają problemów z zarządzaniem fokusem.
• Zakładanie, że osadzone widżety zewnętrzne automatycznie spełniają wymagania: Procesory płatności, widżety czatu na żywo i silniki rezerwacyjne osadzane za pomocą iframe lub skryptów często narzucają własne limity czasu. Odpowiedzialność za zgodność całej strony z WCAG — w tym osadzonej treści, którą kontrolujesz — spoczywa na właścicielu strony.

Związek z Tureckimi Regulacjami Dotyczącymi Dostępności

Prezydenckie Okólniki Turcji 2025/10, opublikowane w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawiają obowiązkowe wymagania dotyczące dostępności stron internetowych, zgodne z WCAG 2.2 na poziomie AA, dla szerokiego zakresu podmiotów publicznych i prywatnych świadczących usługi cyfrowe w Turcji. WCAG 2.2.1 Timing Adjustable jest kryterium na poziomie A, co oznacza, że znajduje się na podstawowym poziomie zgodności — jest jednym z pierwszych wymagań, które objęte podmioty muszą spełnić.

Zgodnie z okólnikiem instytucje i agencje publiczne — w tym ministerstwa, gminy, uniwersytety i przedsiębiorstwa państwowe — są zobowiązane do osiągnięcia pełnej zgodności w ciągu roku od daty publikacji okólnika. Podmioty sektora prywatnego objęte regulacją mają dwuletnie okno na dostosowanie się. Zakres sektora prywatnego jest wyraźnie szeroki: obejmuje platformy e-commerce, banki i instytucje finansowe, prywatne szpitale i świadczeniodawców usług zdrowotnych, firmy telekomunikacyjne z 200,000 lub większą liczbą abonentów, biura podróży, prywatne firmy przewozu pasażerskiego oraz szkoły prywatne działające na podstawie upoważnienia Ministerstwa Edukacji Narodowej (MoNE).

Dla organizacji z tych kategorii niespełnienie WCAG 2.2.1 nie jest jedynie brakiem najlepszej praktyki — jest to niezgodność z prawem, która może przyciągnąć uwagę organów regulacyjnych, skargi składane oficjalnymi kanałami oraz szkody wizerunkowe. Rozważ konkretne procesy biznesowe najbardziej narażone na to naruszenie: finalizacja zakupu w e-commerce z czasową rezerwacją koszyka, sesja bankowości internetowej, która po cichu wygasa, gdy klient wypełnia formularz płatności, system rezerwacji wizyt w szpitalu, który wygasa, zanim użytkownik z niepełnosprawnością ruchową zdoła ukończyć rejestrację, czy portal samoobsługowy operatora telekomunikacyjnego, który automatycznie wylogowuje użytkowników z procesu zarządzania umową. Każdy z tych scenariuszy jest prawdopodobnym przypadkiem naruszenia w ramach typu podmiotu, który jest wyraźnie wymieniony w okólniku.

Organizacje powinny traktować zgodność z WCAG 2.2.1 nie jako techniczne odhaczenie punktu na liście, lecz jako wymaganie projektowe, które musi zostać uwzględnione na poziomie architektury — w politykach zarządzania sesją, wymaganiach dotyczących zakupu widżetów zewnętrznych i standardach komponentów interfejsu użytkownika — zamiast być dodawane po fakcie. Programy audytowe powinny obejmować manualne testy wszystkich interakcji ograniczonych czasowo, a nie tylko skany automatyczne, właśnie dlatego, że narzędzia automatyczne nie są w stanie wykryć tego typu naruszeń bez obserwacji przez człowieka.