Strony i sklepy
WCAG 2.2: jak sprawdzić, czy ze strony da się korzystać
Dostępność zaczyna się od zwykłej czynności: znalezienia informacji, wybrania opcji, wysłania pytania. WCAG pomaga opisać bariery i warunki ich usunięcia. Wynik jednego skanera nie odpowiada jednak na pytanie, czy cały proces działa dla różnych osób.
Wybierz proces i poziom oceny
WCAG 2.2 to standard W3C z kryteriami na poziomach A, AA i AAA. W briefie wskaż konkretną wersję i docelowy poziom. Nie traktuj ogólnego napisu „zgodne z WCAG” jako protokołu odbioru. Potrzebne są zakres, metoda oraz udokumentowane wyniki.
Zacznij od reprezentatywnych widoków i całych zadań: menu, wyszukiwania, produktu, koszyka oraz kontaktu. Uwzględnij błędy, stany po wysłaniu, elementy zewnętrzne i urządzenia mobilne. Same zrzuty ekranu nie pokażą, czy użytkownik potrafi przejść od jednego stanu do następnego.
Od czterech zasad do prawdziwego zadania
WCAG porządkuje wymagania wokół postrzegalności, funkcjonalności, zrozumiałości i kompatybilności. W praktyce warto zamienić te kategorie na pytania dotyczące jednego procesu. Czy klient może odebrać informację o usłudze? Czy potrafi wybrać wariant i przejść dalej? Czy rozumie warunki oraz komunikat o błędzie? Czy jego przeglądarka i technologie wspomagające otrzymują właściwe nazwy, role oraz stany elementów? Sama atrakcyjna wersja widoczna na ekranie projektanta nie odpowiada na wszystkie te pytania. Przetestuj działanie wraz z treścią.
Przykład: formularz zapisu ma czytelny tekst, ale po wybraniu terminu pojawia się nowe pole bez zrozumiałego opisu. Użytkownik czytnika ekranu może nie wiedzieć, co się zmieniło. Inna osoba widzi komunikat oznaczony wyłącznie kolorem, którego nie rozróżnia. Oba problemy dotyczą tego samego zadania, choć wymagają innych poprawek. Dlatego zapisuj scenariusz i rezultat oczekiwany przez człowieka, a dopiero potem przypisuj kryteria techniczne. Lista atrybutów w kodzie pomaga programiście, lecz opis wpływu pozwala właścicielowi strony ustalić priorytet i ocenić, czy naprawa rzeczywiście odblokowała korzystanie.
Co sprawdzić przy przejściu z WCAG 2.1 na 2.2
Wersja 2.2 dodaje dziewięć kryteriów do 2.1; kryterium 4.1.1 dotyczące parsowania zostało usunięte. Poszczególne wymagania mają poziomy A, AA lub AAA. Nie traktuj listy nowości jako całego audytu. Jeżeli strona miała błędy kontrastu czy klawiatury wcześniej, nadal wymagają pracy. W dokumentacji zamówienia zapisz wersję standardu, poziom, języki, badane procesy i środowiska. Sam zapis „strona zgodna z WCAG” jest zbyt nieprecyzyjny, żeby zaplanować sprawdzenie i rozliczyć jego wykonanie.
Szczególnie przyjrzyj się przyklejonym paskom, które mogą zasłaniać aktywny element, małym kontrolkom obok siebie, przeciąganiu oraz logowaniu. Kryterium 2.5.8 na poziomie AA wskazuje 24 × 24 piksele CSS jako minimum celu, z określonymi wyjątkami, między innymi dotyczącymi odstępu. To nie znaczy, że każdy przycisk warto projektować dokładnie na granicy. Przykład: niewielka ikona usuwania pozycji przy przycisku zwiększenia ilości może być formalnie oceniona w kontekście odstępów, ale nadal wymaga próby na telefonie. Projektuj przestrzeń działania tak, aby użytkownik nie musiał celować w sąsiednie, sprzeczne funkcje.
| Kryterium | Temat | Poziom |
|---|---|---|
| 2.4.11 | Niezasłonięty fokus - minimum | AA |
| 2.4.12 | Niezasłonięty fokus - rozszerzenie | AAA |
| 2.4.13 | Wygląd fokusa | AAA |
| 2.5.7 | Przeciąganie | AA |
| 2.5.8 | Rozmiar celu - minimum | AA |
| 3.2.6 | Spójna pomoc | A |
| 3.3.7 | Powtórne wprowadzanie danych | A |
| 3.3.8 | Dostępne uwierzytelnianie - minimum | AA |
| 3.3.9 | Dostępne uwierzytelnianie - rozszerzenie | AAA |
Przepis na sprawdzenie menu, okna i formularza
Zacznij od odświeżenia strony i odłóż mysz. Klawiszem Tab przejdź przez linki i kontrolki, a Shift+Tab sprawdź drogę powrotną. Obserwuj widoczny fokus, kolejność i możliwość pominięcia powtarzalnej nawigacji. Otwórz menu, rozwiń opcje, uruchom kontakt. Zwróć uwagę, czy elementy poza zamkniętym panelem nie pozostają przypadkowo aktywne. Testuj również krótsze okno przeglądarki, ponieważ pasek przyklejony do dołu może zakrywać dokładnie ten przycisk, na którym znajduje się fokus. Kryterium 2.4.11 dotyczy całkowitego zasłonięcia aktywnego komponentu przez treść autora.
W przykładzie okna dialogowego zapisz miejsce rozpoczęcia, sposób zamknięcia oraz to, dokąd wraca fokus. Nie wystarczy sprawdzić, czy krzyżyk wygląda jak przycisk. Spróbuj dotrzeć do wszystkich pól, wywołaj błąd i popraw go bez dotykania myszy. Jeżeli interfejs wymaga przeciągnięcia elementu, sprawdź także dostępną alternatywę bez przeciągania. W3C opisuje to w kryterium 2.5.7 z wyjątkami dla czynności niezbędnych lub obsługiwanych przez przeglądarkę. Samo dodanie obsługi klawiatury nie rozstrzyga wszystkich wymagań dotyczących wskaźnika, dlatego zapisz obie ścieżki w protokole testu.
Czytelność obejmuje kontrast, powiększenie i strukturę
Dla zwykłego tekstu kryterium 1.4.3 wymaga kontrastu co najmniej 4,5:1, a dla dużego 3:1, z opisanymi wyjątkami. Mierz rzeczywistą parę kolorów, także na obrazie, w ciemnym motywie i stanie błędu. Nie zakładaj, że odcień zatwierdzony na białym tle będzie odpowiedni na kolorowej karcie. Wynik pomiaru zapisz przy konkretnym zastosowaniu. Logo i tekst dekoracyjny mają inne warunki oceny niż akapit oferty, dlatego nie stosuj jednej automatycznej decyzji do wszystkich elementów.
Sprawdź także układ przy szerokości odpowiadającej 320 pikselom CSS; kryterium reflow ma wyjątki dla treści wymagających dwóch wymiarów, na przykład części tabel. Praktycznie oznacza to próbę odczytania całego akapitu bez ciągłego przesuwania strony na boki. Tabela może potrzebować własnego przewijania, ale nie powinna rozszerzać całej witryny. Skontroluj nagłówki, etykiety i kolejność czytania. Jeśli wizualne kolumny zmieniają kolejność na telefonie, sprawdź, czy sens argumentacji pozostał poprawny. Powiększenie tekstu nie może zamieniać krótkiej nazwy przycisku w ucięty fragment, którego znaczenia trzeba się domyślać.
Opisy obrazów i komunikaty sprawdzaj w kontekście
Alternatywa tekstowa powinna odpowiadać funkcji obrazu. Drzewo decyzyjne W3C odróżnia dekorację, treść informacyjną i obraz będący kontrolką. Przykład: zdjęcie faktury w instrukcji może wymagać opisania wskazanego pola, a ozdobna faktura papieru za nagłówkiem nie wnosi informacji. Nie oceniaj jakości wyłącznie przez obecność niepustego alt. Opis „zdjęcie numer trzy” nie wyjaśnia materiału, a powtórzenie całego sąsiedniego akapitu może utrudnić czytanie. Poproś redaktora o zapisanie tego, co z obrazu trzeba zrozumieć, aby przejść dalej.
W formularzach sprawdź etykiety, instrukcje przed wypełnieniem i wskazanie konkretnego problemu. Poradnik W3C o powiadomieniach pokazuje potrzebę zrozumiałych komunikatów związanych z polami. Przykład: po nieprawidłowym adresie e-mail użytkownik powinien wiedzieć, które pole poprawić, zamiast otrzymać jedynie czerwone obramowanie. Sprawdź także sukces: czy komunikat opisuje faktyczne przyjęcie danych, czy tylko wykonanie czynności w przeglądarce? Przetestuj pusty formularz, błędne dane i błąd serwera na danych testowych. Dopiero te próby pokażą, czy po błędzie użytkownik wie, co zrobić, i może kontynuować.
Logowanie i ponowne wpisywanie danych
Przy logowaniu sprawdź współpracę z menedżerem haseł oraz możliwość wklejania. W3C w kryterium 3.3.8 opisuje dostępne uwierzytelnianie, obejmując mechanizmy pomagające wykonać zadanie poznawcze lub odpowiednie alternatywy i wyjątki. Nie wyciągaj z tego prostego wniosku, że hasło jest zakazane. Pytanie brzmi, jak użytkownik może przejść proces bez niepotrzebnej konieczności zapamiętywania czy przepisywania. Przejdź cały proces: rejestrację, potwierdzenie, ponowne logowanie i odzyskanie dostępu. Bariera może pojawić się dopiero przy odzyskiwaniu konta.
Przykład: sklep pozwala wkleić hasło, ale blokuje wklejenie kodu weryfikacyjnego i wymaga ponownego wpisania wcześniej podanego adresu. Takie elementy trzeba ocenić osobno w rzeczywistym procesie. Zapisz, skąd pochodzi kod, ile kroków wykonuje człowiek i jakie instrukcje otrzymuje po nieudanej próbie. Nie rozwiązuj problemu usunięciem ochrony konta. Wspólnie z osobą odpowiedzialną za bezpieczeństwo wybierz dostępny sposób działania. Oddziel ocenę bezpieczeństwa od wygody, ale omawiaj je razem na etapie projektu. Naprawa jednego obszaru nie powinna przypadkiem osłabić drugiego ani przenosić trudności na kontakt telefoniczny z obsługą.
Raport, który pozwala naprawdę naprawić barierę
Dobry zapis problemu zawiera adres, stan strony, środowisko, kroki, spodziewany wynik i zaobserwowany rezultat. Dodaj wpływ na zadanie, odniesienie do kryterium oraz materiał pozwalający odtworzyć sytuację bez danych klientów. Przykład zgłoszenia: „Po otwarciu wyboru dostawy klawiaturą nie można wrócić do formularza; zakup pozostaje przerwany”. Taka informacja jest bardziej użyteczna niż sam napis „błąd ARIA”. Programista powinien wiedzieć, co naprawić, a osoba odbierająca jak sprawdzić efekt. Zrzut ekranu pomaga, lecz często nie pokazuje przebiegu interakcji.
Ustal priorytet według wpływu i zasięgu. Błąd wspólnego menu może dotyczyć wielu stron, a pojedynczy problem płatności blokować najważniejszy proces. Grupuj powtarzalne usterki, zachowując przykłady. Po poprawce powtórz cały zależny scenariusz, również w innych miejscach użycia komponentu. Nie zamykaj zgłoszenia wyłącznie dlatego, że kod się zmienił. W raporcie rozróżnij naprawione, nadal otwarte i niesprawdzone obszary. Brak testu nie oznacza braku problemu. Z raportu właściciel witryny powinien odczytać, które zadania już działają, a które nadal są zablokowane.
Włącz dostępność do kolejnych publikacji
Po audycie przygotuj krótkie zasady dla redakcji i projektowania: jak nazywać linki, dodawać zdjęcia, pisać etykiety i tworzyć nowe warianty komponentów. Przed zmianą koszyka, menu albo zewnętrznego widżetu wracaj do zapisanych scenariuszy. Automatyzacja jest pomocna w powtarzalnych kontrolach, ale potrzebujesz także oceny człowieka i, gdy to możliwe, udziału użytkowników z niepełnosprawnościami. Ich test nie jest automatycznie certyfikatem całego serwisu; daje wiedzę o konkretnych zadaniach i barierach, które mogą umknąć przy oglądaniu kodu.
Na początek wybierz ważny proces, przygotuj środowisko testowe i ustal osobę odpowiedzialną za naprawy. Zdefiniuj zakres audytu i oczekiwany raport, zanim zamówisz usługę. Przy kontakcie z DigiDraft podaj adres witryny, główne zadania klientów, używane zewnętrzne moduły i znane problemy. To pozwala omówić badanie odpowiadające rzeczywistej stronie. Wymagania prawne sprawdzaj osobno dla sytuacji firmy. WCAG jest standardem technicznym; sam pozytywny test narzędzia ani przygotowanie deklaracji nie potwierdzają wszystkich obowiązków. Najbardziej użyteczny rezultat to działający proces, udokumentowane poprawki i sposób sprawdzania, czy bariera nie wraca po następnej aktualizacji.
Pytania i odpowiedzi
Czy dobry wynik skanera potwierdza zgodność z WCAG 2.2?
Nie potwierdza zgodności całego serwisu. Skaner pomaga wykryć część problemów, ale potrzebne są także ręczne testy zadań, stanów błędu i działania z technologiami wspomagającymi. Raport powinien podawać wersję WCAG, poziom, zakres oraz metodę oceny.
Od czego zacząć sprawdzanie strony klawiaturą?
Odłóż mysz i przejdź klawiszem Tab przez menu, przyciski oraz formularz; Shift+Tab pozwala wrócić. Sprawdź, czy widzisz aktywny element, możesz otworzyć i zamknąć okno oraz poprawić błąd formularza. Zapisuj miejsce, w którym nie da się dokończyć zadania.
Co powinno znaleźć się w zgłoszeniu bariery dostępności?
Podaj adres, środowisko testu, kroki oraz to, co miało się wydarzyć i co faktycznie się wydarzyło. Opisz wpływ na użytkownika, na przykład brak możliwości wyboru dostawy. Po poprawce powtórz cały scenariusz, a nie tylko kontrolę zmienionego elementu.