Nowa norma EN 301 549 V4.1.1 wymaga, by strony, dokumenty i aplikacje szanowały ustawienia dostępności wybrane przez użytkownika w systemie, na przykład większy tekst czy wysoki kontrast. Tego wymagania nie ma w WCAG 2.2, więc nie obejmie go klasyczny audyt ograniczony do listy kryteriów WCAG ani żadne narzędzie automatyczne. Trzeba je sprawdzić na prawdziwym urządzeniu.
Ustawienia, które Twoi klienci już mają włączone
Spora część użytkowników zmienia ustawienia telefonu czy komputera, żeby lepiej widzieć ekran. Starsza osoba powiększa tekst. Ktoś z migreną włącza wysoki kontrast albo filtr kolorów. Ktoś ze słabszym wzrokiem powiększa kursor myszy.
Te ustawienia działają tylko wtedy, gdy Twoja strona lub aplikacja ich nie ignoruje. Nowa norma mówi to wprost w klauzulach 9.7 (strony), 10.7 (dokumenty) i 11.7 (oprogramowanie, w tym aplikacje): produkt ma respektować takie ustawienia, a nie je nadpisywać, chyba że nadpisanie jest niezbędne dla samej treści albo funkcji. Logo w barwach firmy nie jest takim uzasadnieniem dla całego interfejsu.
Norma wymienia między innymi filtry kolorów, kontrast, rozmiar tekstu, rozmiar wskaźnika i kursor tekstowy. Ograniczenie ruchu, które znasz z WCAG 2.3.3 i z zapytania prefers-reduced-motion, warto sprawdzić jako dobrą praktykę. W tych trzech klauzulach nie jest wypisane obok rozmiaru tekstu.
Jak to wygląda w praktyce
Wyobraź sobie aplikację sklepu, w której tekst ma stały rozmiar. Klient ustawił w telefonie największy tekst, bo inaczej nie przeczyta cen. We wszystkich innych aplikacjach tekst jest duży, a w Twojej malutki. Klient nie wie, że to błąd aplikacji, więc po prostu z niej rezygnuje.
Dlaczego automat tego nie sprawdzi
Narzędzia automatyczne, także Trop w wersjach Zwiad i Skan, badają kod strony w jednym, domyślnym ustawieniu. Nie zmieniają rozmiaru tekstu w systemie i nie porównują widoku przed zmianą i po niej.
Skan mówi, co widać w domyślnym oknie przeglądarki. Ustawienie „większy tekst” albo wysoki kontrast włączam na telefonie i na komputerze, a potem przechodzę tę samą ścieżkę jeszcze raz: czy cena się nie ucina, czy przycisk nie wyjechał poza ekran, czy fokus nadal widać. Bez tego porównania nowe wymaganie normy zostaje niesprawdzone, nawet jeśli automat nie zgłosił żadnego błędu.
Marcel Styła, tester dostępności
Jak to sprawdzamy w Trop Audyt
Trop Audyt łączy badanie automatyczne z pracą audytora. W opisie pakietu na stronie są: automatyczna synteza Trop, weryfikacja klawiaturą i czytnikiem ekranu, do 15 widoków i 3 ścieżek ustalanych z Tobą, podsumowanie dla zarządu i zalecenia dla zespołu. Czas to 3–7 dni, cena 2 490 zł netto.
Osobnej pozycji „test ustawień systemu” w tym opisie nie ma. Audytor i tak ogląda stronę na prawdziwym urządzeniu, więc większy tekst, kontrast i filtry kolorów da się włączyć do tych samych ścieżek. Jeśli to ma być w zakresie na pewno, wpisujemy to przy ustalaniu widoków, a nie zakładamy tego w ciszy.
Najpierw Trop przegląda serwis i znajduje błędy, które da się wykryć w kodzie. Potem audytor:
- weryfikuje wyniki automatu i odrzuca fałszywe alarmy,
- przechodzi kluczowe ścieżki: logowanie, formularze, koszyk,
- na tych ścieżkach sprawdza reakcję na ustawienia systemu: tekst, kontrast, kolory, wskaźnik,
- przygotowuje raport z priorytetami i podsumowaniem dla zarządu.
Sześć nowych kryteriów WCAG 2.2 opisujemy w tekście Czy Twoja strona spełnia WCAG 2.2?. Szersze omówienie klauzul 9.7, 10.7 i 11.7 jest na AccessibilityTeam.eu.
Twoja strona przeszła już badanie Trop? Zamów Trop Audyt za 2 490 zł netto.
Drużyna Dostępności