WCAG 2.2.6: Limity czasu

Co Oznacza Ta Zasada

WCAG 2.2.6 Timeouts (poziom AAA) wymaga, aby użytkownicy byli ostrzegani o czasie trwania każdej bezczynności, która może spowodować utratę danych, chyba że dane są zachowywane przez ponad 20 godzin bezczynności użytkownika. W praktyce oznacza to, że jeśli Twoja aplikacja internetowa lub usługa może utracić dane użytkownika — takie jak wpisy w formularzu, koszyk zakupowy lub trwająca transakcja — z powodu okresu bezczynności użytkownika, musisz poinformować użytkowników dokładnie, jak długo mają, zanim te dane zostaną utracone.

Kryterium ma zastosowanie do każdej sytuacji, w której limit czasu skutkuje utratą danych. Typowe przykłady obejmują wygaśnięcie sesji na portalach bankowych lub rządowych, które czyści dane formularza, koszyki zakupowe, które opróżniają się po okresie bezczynności, wieloetapowe kreatory lub formularze, które resetują się po wygaśnięciu ciasteczka sesji, oraz systemy testów online lub rezerwacji, które odrzucają częściowe odpowiedzi. Kluczowym wyzwalaczem jest połączenie bezczynności (nie twardego limitu czasu na ukończenie zadania, który jest objęty 2.2.1) oraz konsekwencji w postaci utraty danych.

Co jest uznawane za spełnienie: Strona spełnia 2.2.6, jeśli wyraźnie informuje użytkowników na początku sesji — lub zanim zaczną wprowadzać dane — o konkretnym czasie bezczynności, po którym nastąpi utrata danych. Alternatywnie, strona spełnia kryterium, jeśli do utraty danych nie może dojść niezależnie od tego, jak długo użytkownik jest nieaktywny (na przykład dlatego, że serwer przechowuje wszystkie dane formularza przez ponad 20 godzin lub bezterminowo). Wyświetlenie ostrzeżenia dopiero po tym, jak sesja już wygasła, nie spełnia kryterium.

Co jest uznawane za niespełnienie: Strona nie spełnia kryterium, jeśli po okresie bezczynności po cichu traci dane użytkownika, nigdy nie informując go o tym ryzyku. Nie spełnia go także wtedy, gdy ostrzeżenie istnieje, ale jest prezentowane dopiero w momencie utraty danych (zbyt późno, by zareagować), lub gdy ostrzeżenie jest nieprecyzyjne — na przykład stwierdza „Twoja sesja może wygasnąć” bez określenia rzeczywistego czasu bezczynności, który wywołuje limit.

Oficjalne wyjątki: Kryterium wprost wyłącza sytuacje, w których dane są zachowywane przez ponad 20 godzin bezczynności. Próg 20 godzin został wybrany, aby uwzględnić użytkowników, którzy rozpoczynają zadanie jednego dnia, a wznawiają je następnego. Jeśli Twój system niezawodnie przechowuje wszystkie wprowadzone dane po stronie serwera przez co najmniej 20 godzin bez jakichkolwiek działań ze strony użytkownika, nie musisz wyświetlać ostrzeżenia. Ponadto kryterium nie ma zastosowania do limitów czasu, które są niezbędne dla bezpieczeństwa — na przykład twardego wymogu prawnego lub regulacyjnego, że sesja musi zostać zakończona po określonym czasie niezależnie od działań użytkownika. W takich przypadkach kryterium nadal zachęca do ujawnienia informacji, ale uznaje ograniczenia prawne.

Dlaczego To Ma Znaczenie

Limity czasu bez odpowiedniego ostrzeżenia w nieproporcjonalny sposób dotykają osoby z niepełnosprawnościami poznawczymi, z niepełnosprawnością ruchową oraz osoby niewidome lub słabowidzące. Użytkownicy z niepełnosprawnościami poznawczymi, takimi jak dysleksja, ADHD czy urazowe uszkodzenie mózgu, mogą potrzebować znacznie więcej czasu na przeczytanie instrukcji, sformułowanie tekstu lub przejrzenie informacji przed wysłaniem formularza. Jeśli sesja wygaśnie po cichu, gdy wciąż pracują, tracą cały swój wysiłek i muszą zaczynać od nowa — to głęboko zniechęcające doświadczenie, które może skłonić ich do całkowitego porzucenia zadania.

Osoby z niepełnosprawnością ruchową, które polegają na przełącznikach, urządzeniach śledzących ruch gałek ocznych lub innych alternatywnych metodach wprowadzania danych, wchodzą w interakcję z interfejsami znacznie wolniej niż użytkownik myszy. Wypełnienie długiego formularza zgłoszenia szkody ubezpieczeniowej lub wielostronicowego wniosku do urzędu może zająć im wielokrotnie więcej czasu, niż zakłada domyślny limit czasu sesji. Nie znając odliczania, nie mają możliwości podjęcia działań — takich jak zapisanie postępów czy poproszenie o przedłużenie — zanim ich dane znikną.

Użytkownicy czytników ekranu również stoją przed złożonym wyzwaniem: nawigacja po złożonych formularzach trwa dłużej, gdy każde pole musi zostać odczytane na głos i potwierdzone klawiaturą. Sesja, która wygasa, gdy użytkownik wciąż metodycznie przechodzi przez długi formularz, nie jest jedynie niedogodnością — może oznaczać godziny straconej pracy i istotną barierę w dostępie do kluczowych usług.

Rozważmy ten scenariusz z życia wzięty: użytkownik z stwardnieniem rozsianym składa wniosek o świadczenie z tytułu niepełnosprawności za pośrednictwem portalu rządowego. Formularz ma 12 sekcji i wymaga przesłania dokumentów potwierdzających. Sesja wygasa po 15 minutach bezczynności, ale użytkownik zatrzymał się w połowie sekcji 7, aby przynieść dokument z innego pokoju. Po powrocie wszystkie dane zostały wyczyszczone i musi zacząć od nowa — bez wcześniejszego ostrzeżenia, że tak się stanie. Zgodnie z 2.2.6 portal musiałby poinformować użytkownika na początku, że bezczynność dłuższa niż 15 minut spowoduje utratę danych, umożliwiając mu odpowiednie zaplanowanie.

Poza dostępnością, proaktywne ujawnianie zachowania limitów czasu poprawia doświadczenie użytkownika dla wszystkich i zmniejsza współczynnik porzuceń w kluczowych ścieżkach konwersji, takich jak finalizacja zakupu, rejestracja i formularze aplikacyjne. Buduje też zaufanie, ponieważ użytkownicy nie zastanawiają się, dlaczego ich dane zniknęły.

Powiązane Reguły Axe-core

WCAG 2.2.6 wymaga testów manualnych. Nie istnieje zautomatyzowana reguła axe-core, która mogłaby wykryć to naruszenie, a zrozumienie dlaczego jest to ważne, ma znaczenie zarówno dla testerów, jak i deweloperów.

• Wymagane testy manualne — ujawnienie limitu czasu sesji: Zautomatyzowane narzędzia, takie jak axe-core, mogą skanować DOM w poszukiwaniu obecności lub braku określonych elementów, atrybutów i wzorców tekstowych, ale nie są w stanie ustalić, czy aplikacja internetowa utraci dane użytkownika po okresie bezczynności. Zachowanie limitu czasu jest zazwyczaj kontrolowane przez konfigurację sesji po stronie serwera (np. PHP lub Node.js session TTL), a ujawnienie — jeśli istnieje — może pojawić się w tekście wprowadzającym, oknie modalnym, na stronie pomocy, a nawet w sekcji warunków korzystania z usługi. Żadna statyczna analiza DOM nie może wiarygodnie powiązać fragmentu tekstu informacyjnego z rzeczywistym zachowaniem limitu czasu po stronie serwera. Narzędzie nie może wiedzieć, czy zdanie „Ze względów bezpieczeństwa sesje wygasają po 15 minutach” jest dokładne, czy dotyczy danych na bieżącej stronie, ani czy jest umieszczone wystarczająco wcześnie w ścieżce użytkownika, aby można było na nie zareagować. Tylko tester-ludzki, który może wchodzić w interakcję z aplikacją, obserwować jej zachowanie w czasie i oceniać kompletność oraz moment ujawnienia informacji, może określić zgodność.
• Wymagane testy manualne — weryfikacja zachowania danych: Axe-core nie może również zweryfikować wyjątku 20-godzinnego. To, czy dane są faktycznie przechowywane po stronie serwera przez ponad 20 godzin — a zatem czy ujawnienie jest w ogóle wymagane — zależy całkowicie od logiki backendu, która jest niewidoczna dla narzędzia skanującego działającego w przeglądarce. Testerzy muszą albo przejrzeć konfigurację serwera, porozmawiać z deweloperami, albo empirycznie przetestować, pozostawiając częściowo wypełniony formularz na dłuższy czas i obserwując, czy dane się zachowują.

Jak Testować

1. Zautomatyzowany wstępny skan: Uruchom axe DevTools lub Lighthouse na stronie zawierającej formularz, proces finalizacji zakupu lub inny interfejs wprowadzania danych. Chociaż żadne z tych narzędzi nie oznaczy bezpośrednio naruszenia 2.2.6, użyj tego kroku, aby zidentyfikować wszelkie powiązane z limitami czasu regiony ARIA live lub komponenty dialogowe, które mogą być częścią mechanizmu ostrzegania, i zweryfikuj, że same są dostępne (prawidłowe role, etykiety, zarządzanie fokusem).
2. Identyfikacja zachowania limitu czasu: Porozmawiaj z zespołem deweloperskim lub przejrzyj konfigurację po stronie serwera, aby ustalić czas bezczynności powodujący wygaśnięcie sesji. Typowe lokalizacje obejmują pliki konfiguracyjne serwera WWW, ustawienia middleware sesji aplikacji oraz dokumentację dostawcy uwierzytelniania. Zanotuj dokładny czas w minutach.
3. Sprawdzenie ujawnienia z wyprzedzeniem: Załaduj stronę od nowa i przeczytaj całą treść prezentowaną użytkownikowi, zanim rozpocznie wprowadzanie danych. Poszukaj jasnego stwierdzenia — w treści strony, akapicie wprowadzającym, banerze lub oknie modalnym — które określa dokładny czas bezczynności powodujący utratę danych i stwierdza, że dane zostaną utracone, jeśli użytkownik będzie nieaktywny przez ten okres. Ujawnienie musi podawać czas wprost (np. „15 minut”), a nie nieprecyzyjnie (np. „krótki czas”).
4. Test z czytnikiem ekranu: Używając NVDA z Firefoxem, VoiceOver z Safari lub JAWS z Chrome, nawiguj po stronie od samego początku. Potwierdź, że każde ujawnienie limitu czasu jest osiągalne i odczytywane na głos przez czytnik ekranu bez konieczności aktywnego wyszukiwania go przez użytkownika. Jeśli ujawnienie znajduje się w wizualnie wyróżnionym banerze, zweryfikuj, że znajduje się w kolejności odczytu przed pierwszym polem formularza.
5. Symulacja bezczynności: Zacznij wypełniać formularz. Następnie przestań wchodzić w interakcję ze stroną na czas nieco krótszy niż okres limitu i obserwuj, co się dzieje. Następnie powtórz, czekając, aż okres limitu upłynie. Zanotuj, czy dane zostały utracone, czy ostrzeżenie zostało wyświetlone przed utratą danych oraz czy to ostrzeżenie zostało zakomunikowane przed rozpoczęciem sesji.
6. Test wyjątku 20-godzinnego: Jeśli zespół twierdzi, że dane są zachowywane przez ponad 20 godzin, zweryfikuj to empirycznie, częściowo wypełniając formularz, czekając co najmniej 20 godzin i wracając na stronę, aby potwierdzić, że dane są nadal obecne. Alternatywnie, przejrzyj konfigurację magazynu sesji po stronie serwera z zespołem deweloperskim.
7. Testowanie klawiatury i fokusu: Jeśli pojawia się okno dialogowe lub powiadomienie o limicie czasu, zweryfikuj, używając wyłącznie klawiatury, że automatycznie otrzymuje fokus, że jego treść jest w pełni czytelna oraz że użytkownik może je zamknąć lub podjąć działanie (np. przedłużyć sesję) bez użycia myszy.

Jak Naprawić

Sesja z cichą utratą danych — Nieprawidłowe

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

Sesja z cichą utratą danych — Prawidłowe

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

Sesja finalizacji zakupu z nieprecyzyjnym ostrzeżeniem — Nieprawidłowe

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

Sesja finalizacji zakupu z nieprecyzyjnym ostrzeżeniem — Prawidłowe

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

Dane zachowywane po stronie serwera przez ponad 20 godzin — Prawidłowe (ma zastosowanie wyjątek)

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

Typowe Błędy

• Wyświetlanie ostrzeżenia o limicie czasu wyłącznie w konsoli przeglądarki lub w wpisie dziennika serwera, który jest niewidoczny dla użytkowników końcowych — ostrzeżenie musi być prezentowane w interfejsie użytkownika, w miejscu, w którym użytkownik napotka je przed utratą danych.
• Umieszczanie ujawnienia w stopce, polityce prywatności lub na stronie z warunkami korzystania z usługi, których użytkownicy prawdopodobnie nie przeczytają przed rozpoczęciem wprowadzania danych, zamiast bezpośrednio na formularzu lub tuż przed nim.
• Używanie okna modalnego do ostrzegania użytkowników o zbliżającym się wygaśnięciu sesji, ale bez przeniesienia fokusu klawiatury do tego okna — użytkownicy klawiatury i czytników ekranu mogą nigdy nie zauważyć, że ostrzeżenie się pojawiło.
• Podawanie długości sesji (np. „Twoja sesja trwa 30 minut”) zamiast limitu czasu bezczynności (np. „po 15 minutach bezczynności Twoje dane zostaną utracone”) — są to różne pojęcia, a tylko utrata danych wywołana bezczynnością jest objęta 2.2.6.
• Zakładanie, że skoro istnieje okno modalne z ostrzeżeniem o limicie czasu dla użytkowników widzących, kryterium jest spełnione — jeśli okno modalne nie jest dostępne z poziomu klawiatury, nie ma dostępnej nazwy lub nie jest ogłaszane przez regiony ARIA live lub zarządzanie fokusem, użytkownicy czytników ekranu nie otrzymają ostrzeżenia.
• Ustawienie limitu czasu sesji po stronie serwera na 25 godzin i uznanie, że ujawnienie nie jest potrzebne, bez weryfikacji, że stan po stronie przeglądarki lub aplikacji (np. magazyn Redux lub localStorage) nie jest czyszczony wcześniej — efektywnym limitem czasu jest ten mechanizm, który jako pierwszy powoduje utratę danych.
• Ujawnianie czasu limitu w podpowiedzi wyświetlanej tylko po najechaniu kursorem — użytkownicy polegający na nawigacji klawiaturą lub urządzeniach dotykowych mogą nigdy nie napotkać tego ujawnienia.
• Poleganie na ogólnym ostrzeżeniu CMS lub frameworka „session expired” wyświetlanym po tym, jak utrata danych już nastąpiła, zamiast proaktywnego informowania użytkowników przed rozpoczęciem wprowadzania danych.
• Brak uwzględnienia użytkowników, którzy otwierają formularz w tle w innej karcie: jeśli licznik sesji działa, gdy karta jest nieaktywna, dane mogą zostać utracone, zanim użytkownik w ogóle będzie miał możliwość wejścia w interakcję z formularzem. Jest to szczególnie problematyczne w przeglądarkach mobilnych, które agresywnie wstrzymują karty w tle.
• Pomijanie ostrzeżenia w wersjach mobilnych lub w kontekście progresywnych aplikacji webowych (PWA), przy jednoczesnym wyświetlaniu go w wersji desktopowej, co tworzy niespójne doświadczenie i oznacza niespełnienie 2.2.6 dla istotnej części użytkowników.

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

Okrężnik Prezydencki Turcji 2025/10, opublikowany w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia wiążące obowiązki w zakresie dostępności stron internetowych dla szerokiego zakresu podmiotów publicznych i prywatnych działających w Turcji. Okrężnik nakazuje zgodność z WCAG 2.2 jako standardem technicznym, wymagając od objętych podmiotów spełnienia co najmniej poziomu AA. WCAG 2.2.6 Timeouts jest kryterium poziomu AAA i dlatego nie jest bezpośrednio wymagane przez podstawowe wymogi okrężnika. Jednak zakres i cel okrężnika tworzą silne praktyczne powody, dla których objęte podmioty powinny dążyć do zgodności z poziomem AAA w kryteriach takich jak 2.2.6.

Podmioty objęte Okrężnikiem Prezydenckim 2025/10 obejmują instytucje i agencje publiczne, platformy e-commerce, banki i instytucje finansowe, szpitale i świadczeniodawców opieki zdrowotnej, operatorów telekomunikacyjnych z ponad 200 000 abonentów, biura podróży, prywatne firmy transportowe oraz szkoły prywatne upoważnione przez Ministerstwo Edukacji Narodowej (MoNE). Wiele z tych sektorów prowadzi portale online, które obejmują dokładnie takie przepływy wprowadzania danych, jakie 2.2.6 ma chronić: wnioski kredytowe, formularze przyjęcia pacjenta, systemy rezerwacji biletów, formularze rekrutacyjne i wnioski o świadczenia rządowe.

Dla banków i platform e-commerce w szczególności limity czasu sesji są rutynowym środkiem bezpieczeństwa, a interakcja między wymogami bezpieczeństwa a obowiązkami w zakresie dostępności jest bezpośrednio istotna. Chociaż bank może mieć regulacyjny obowiązek zakończenia bezczynnych sesji po określonym czasie, wdrożenie WCAG 2.2.6 poprzez ujawnienie czasu limitu z wyprzedzeniem nie stoi w sprzeczności z tym wymogiem bezpieczeństwa — uzupełnia go. Użytkownicy są świadomi ograniczenia, bez konieczności osłabiania przez bank zabezpieczeń sesji.

Świadczeniodawcy opieki zdrowotnej i szpitale objęte okrężnikiem obsługują jedne z najbardziej newralgicznych zadań związanych z wprowadzaniem danych, jakie można sobie wyobrazić — formularze historii choroby pacjenta, wnioski o autoryzację wstępną i systemy umawiania wizyt. Pacjenci z niepełnosprawnościami poznawczymi lub ruchowymi, którzy tracą dane w połowie formularza w tych kontekstach, doświadczają nie tylko frustracji, ale także potencjalnego opóźnienia w uzyskaniu opieki. Wdrożenie 2.2.6 w tych środowiskach jest bezpośrednim wyrazem mandatu inkluzywnych usług, który leży u podstaw okrężnika.

Chociaż poziom AAA nie jest prawnie wymagany, osiągnięcie go w kryteriach takich jak 2.2.6 — które wymagają stosunkowo niewielkiego wysiłku wdrożeniowego (dodanie jednego, dokładnego komunikatu na formularzu), a jednocześnie przynoszą znaczące korzyści wrażliwym grupom użytkowników — stanowi praktykę dostępności na najwyższym poziomie. Organizacje, które chcą wykazać swoje zaangażowanie w inkluzję cyfrową na rynku tureckim lub przewidują zaostrzenie przyszłych regulacji, odnoszą korzyści, traktując 2.2.6 jako praktyczny cel wdrożeniowy, a nie opcjonalne aspiracje.