- Poziom
- A
- Od wersji
- WCAG 2.0
- Pozycje
- 1 / 193
2.2.1 Dostosowanie czasu
Gdy strona wyznacza limit czasu, użytkownik musi móc go wyłączyć, dostosować albo przedłużyć, chyba że limit należy do wydarzenia na żywo, jest istotny albo trwa dłużej niż 20 godzin.
/ Czego wymaga
Wszystko, co dzieje się po ustalonym czasie bez udziału użytkownika, jest limitem czasu: sesja, która wylogowuje po okresie bezczynności, koszyk zwalniany w trakcie zamówienia, test z odliczaniem, strona, która sama się odświeża albo przekierowuje, komunikat, który znika, zanim da się go przeczytać. Osoby niewidome poznające stronę czytnikiem ekranu, osoby słabowidzące, z ograniczoną sprawnością rąk albo z niepełnosprawnością poznawczą lub językową mogą potrzebować kilka razy więcej czasu, niż założył projektant. Gdy czas się kończy, tracą swoją pracę albo treść, którą czytały.
Dla każdego limitu czasu ustalonego przez treść musi być spełniona jedna z możliwości. Użytkownik może wyłączyć limit, zanim na niego trafi; albo dostosować go wcześniej w szerokim zakresie, co najmniej dziesięciokrotności wartości domyślnej; albo dostaje ostrzeżenie przed upływem czasu, co najmniej 20 sekund na przedłużenie prostą czynnością i możliwość przedłużenia co najmniej dziesięć razy. Zostają trzy wyjątki: wydarzenie na żywo, na przykład aukcja, gdy alternatywa nie jest możliwa, limit istotny, bo jego przedłużenie unieważniłoby czynność, oraz limit dłuższy niż 20 godzin. Timer nie jest limitem, gdy ta sama informacja jest dostępna inną drogą, a treść ruchomą, taką jak karuzela, obejmuje kryterium 2.2.2.
/ Jak strony go nie spełniają
- Serwis informacyjny co kilka minut odświeża się przez meta refresh i odsyła czytelnika na początek strony.
- Strona z podziękowaniem po dziesięciu sekundach przenosi na stronę główną za pomocą meta http-equiv="refresh" content="10; url=/".
- Sesja po zalogowaniu kończy się po okresie bezczynności bez ostrzeżenia, a wypełniany formularz przepada.
- Przed wygaśnięciem sesji pojawia się ostrzeżenie, ale ma tylko przycisk Wyloguj albo samo znika po kilku sekundach.
- Test ćwiczeniowy ma odliczanie, którego nie da się wstrzymać, przedłużyć ani wyłączyć, choć nic w tej czynności nie zależy od czasu.
/ Jak sprawdzić samodzielnie
- Wypisz wszystkie limity czasu w serwisie: wygaśnięcie sesji, wylogowanie po bezczynności, odliczania, rezerwacje w koszyku, automatyczne odświeżanie, przekierowania z opóźnieniem i komunikaty, które znikają same.
- Otwórz źródło strony i wyszukaj http-equiv="refresh". Opóźnienie większe od zera, z adresem albo bez, to limit, nad którym użytkownik nie panuje, chyba że przekracza 20 godzin.
- Zostaw zalogowaną stronę bez ruchu i zmierz, po jakim czasie pojawia się ostrzeżenie albo wylogowanie. Ostrzeżenie musi dawać co najmniej 20 sekund i przedłużać sesję jedną prostą czynnością, i musi to działać dziesięć razy.
- Poszukaj przed rozpoczęciem zadania z limitem ustawienia, które wyłącza limit albo podnosi go co najmniej do dziesięciokrotności wartości domyślnej.
- Powtórz test ostrzeżenia samą klawiaturą i z czytnikiem ekranu, żeby sprawdzić, czy ostrzeżenie jest odczytywane, a do przycisku przedłużenia da się dojść na czas.
/ Jak to naprawić
- Usuń meta refresh. Przekierowuj odpowiedzią HTTP 301 albo 302 zamiast strony z opóźnieniem, a zmieniającą się treść pozwól odświeżać przyciskiem.
- Przed końcem sesji otwórz okno, które mówi, ile czasu zostało, i ma przycisk Przedłuż sesję, czekaj na odpowiedź co najmniej 20 sekund, a po naciśnięciu odnów sesję po stronie serwera.
- Na początku zadania z limitem daj ustawienie, które wyłącza limit albo mnoży go przez dziesięć.
- Komunikaty i powiadomienia typu toast zostawiaj na ekranie, dopóki użytkownik ich nie zamknie, albo udostępnij tę samą informację w innym miejscu, na przykład na liście powiadomień.
- Zapisuj dane z formularza na bieżąco, w sessionStorage albo na serwerze, żeby wygaśnięcie sesji nie wyrzucało pracy użytkownika.
/ Co sprawdza nasz skaner
HTML_CodeSniffer działa na wyrenderowanej stronie i zgłasza element meta z http-equiv="refresh", którego atrybut content zaczyna się cyfrą od 1 do 9: technikę F40, gdy content zawiera też url=, i F41, gdy strona odświeża samą siebie. Opóźnienie 0 przechodzi. Test zgłasza też opóźnienie dłuższe niż wyjątek 20 godzin i nie widzi timerów w skryptach, wygasania sesji ani przekierowań wysyłanych przez serwer.
/ Kto je łamie, według naszych pomiarów
| Podmiot | Sektor | Wystąpienia | Wynik |
|---|---|---|---|
| Detroit | city · US | 1 | 40 |
Jedna strona na podmiot, mierzona automatycznie w tygodniowym cyklu. Jeśli podmiot coś naprawił od ostatniego pomiaru, zmiana będzie widoczna przy następnym, a każdy podmiot może odpowiedzieć na swojej stronie.
/ Pytania o to kryterium
Ile czasu musi dawać ostrzeżenie przed wygaśnięciem sesji?
Co najmniej 20 sekund na reakcję prostą czynnością, na przykład naciśnięciem przycisku albo spacji, a użytkownik musi móc przedłużyć limit co najmniej dziesięć razy. Dwie pozostałe drogi to pozwolić mu wyłączyć limit albo ustawić go co najmniej na dziesięciokrotność wartości domyślnej, zanim na niego trafi.
Czy limity sesji ze względów bezpieczeństwa są zwolnione z 2.2.1?
Nie automatycznie. W3C traktuje limit dodany ze względów bezpieczeństwa jako ustalony przez treść, więc musi spełniać kryterium, zwykle przez ostrzeżenie z możliwością przedłużenia. Niektóre limity bezpieczeństwa mogą być uznane za istotne, na przykład jednorazowy kod ważny przez określony czas. Limity ustalane poza treścią, przez przeglądarkę albo sieć, nie są odpowiedzialnością autora, ale limity ustalane przez serwery serwisu już tak.
Czy meta refresh narusza WCAG 2.2.1?
Tak, jeśli ma opóźnienie. Techniki błędów W3C F40 i F41 opisują przekierowanie i odświeżenie z opóźnieniem zrobione przez meta refresh. Opóźnienie zero przekierowuje od razu i nie ustala limitu czasu. Nie ustala go też przekierowanie serwera ze statusem 3xx, które jest czystszym sposobem przeniesienia odwiedzającego pod inny adres.