Dostępność strony internetowej najlepiej oceniać jako możliwość wykonania konkretnego zadania przez różne osoby, a nie jako wynik pojedynczego narzędzia. Właściciel firmy może przeprowadzić użyteczną kontrolę wstępną, jeśli obejmie nią reprezentatywne podstrony, interakcje i najważniejszą ścieżkę biznesową. Taka kontrola nie zastępuje formalnego audytu zgodności.
Krótka odpowiedź: Aby sprawdzić, czy strona jest dostępna dla osób z niepełnosprawnościami, połącz przegląd według kryteriów WCAG z ręcznym przejściem kluczowych funkcji oraz próbą obsługi bez myszy. Wynik automatycznego skanu traktuj wyłącznie jako materiał pomocniczy. O zgodności z WCAG rozstrzyga spełnienie właściwych kryteriów sukcesu w odniesieniu do konkretnej treści i funkcji.
Jak ustalić zakres wstępnego testu dostępności strony?
Zakres wstępnego testu powinien obejmować różne typy stron oraz funkcję, od której zależy kontakt, rezerwacja albo zakup. Nie ma potrzeby zaczynać od każdej podstrony, jeżeli wiele z nich korzysta z tego samego układu lub komponentów. Trzeba jednak uwzględnić miejsca, w których użytkownik wykonuje inne zadanie.
Przygotuj listę adresów i funkcji do sprawdzenia. W przypadku strony firmowej może to być strona główna, oferta, artykuł, kontakt i formularz. W sklepie dołącz listę produktu, koszyk oraz etap złożenia zamówienia. Jeśli strona udostępnia dokumenty lub materiały multimedialne, wpisz je do zakresu jako osobną pozycję, bez przesądzania na tym etapie o ich zgodności.
- Wybierz po jednym przykładzie każdego powtarzalnego szablonu.
- Wskaż elementy niestandardowe, takie jak rozwijane menu, okna dialogowe, kalkulator lub wyszukiwarka.
- Opisz jedno zadanie biznesowe od wejścia na stronę do jego zakończenia.
- Zapisz środowisko testu, na przykład używaną przeglądarkę i datę kontroli.
WCAG 2 jest międzynarodowym standardem W3C opisującym zwiększanie dostępności treści internetowych dla osób z niepełnosprawnościami. Dotyczy treści dynamicznych, multimediów i stron używanych na urządzeniach mobilnych. Przegląd WCAG 2 przygotowany przez W3C wskazuje, że standard obejmuje zarówno informacje na stronie, jak i kod lub znaczniki określające strukturę oraz prezentację.
Jak wykorzystać automatyczny skan bez mylenia go z audytem?
Automatyczny skan wykorzystaj jako roboczą listę miejsc do obejrzenia, a nie jako werdykt o dostępności strony. W ramach wewnętrznej procedury redakcyjnej dobrze jest rozdzielić wyniki na elementy do potwierdzenia, obserwacje wymagające decyzji i kwestie poza zakresem danego skanu. Przy każdym wpisie otwórz wskazaną stronę i sprawdź kontekst funkcji.
Nie zamieniaj liczby komunikatów na ocenę jakości strony. Ten sam komunikat może dotyczyć wielu elementów powielonych w szablonie, a pojedyncza przeszkoda w formularzu może mieć większy wpływ niż długa lista drobnych obserwacji. Zapisuj adres, element, opis sytuacji oraz to, co użytkownik próbował zrobić.
Podstawą oceny WCAG są testowalne kryteria sukcesu opisane przez W3C, a nie ogólny wynik narzędzia. Kryteria występują na poziomach A, AA i AAA, a ich spełnienie określa zgodność z WCAG. W3C porządkuje wytyczne wokół czterech zasad: postrzegalności, funkcjonalności, zrozumiałości i solidności. Ten układ pomaga przypisać problem do obszaru, zamiast tworzyć przypadkową listę uwag.
Jak przeprowadzić test strony samą klawiaturą?
Test klawiaturą polega na przejściu wybranej ścieżki bez używania myszy i zapisaniu każdego miejsca, w którym nie można rozpoznać położenia, przejść dalej lub ukończyć zadania. Jest to praktyczna kontrola działania interfejsu, a nie samodzielne potwierdzenie zgodności z WCAG.
Rozpocznij na stronie głównej i przemieszczaj się po elementach interaktywnych w kolejności, w której fokus przechodzi między nimi. Zwróć uwagę, czy wiadomo, który element jest aktualnie wybrany, czy można wejść do menu i z niego wyjść oraz czy da się dotrzeć do formularza. W formularzu sprawdź roboczo możliwość dojścia do pól, wysłania danych i zrozumienia komunikatu po próbie wysyłki.
Opis problemu powinien mówić o skutku, nie tylko o wyglądzie. Zamiast „fokus jest zły”, zapisz: „podczas przejścia do przycisku wysyłki nie wiadomo, który element jest aktywny; użytkownik nie może pewnie zakończyć formularza”. Formularze wymagają też osobnej oceny ich użyteczności; porównanie dostępnych rozwiązań opisuje artykuł o formularzach kontaktowych w WordPressie.
Jak ręcznie odnieść treść i interfejs do WCAG?
Ręczna kontrola powinna przyporządkować obserwacje do właściwych kryteriów sukcesu WCAG, zamiast ograniczać się do ogólnego wrażenia, że strona jest czytelna. Najpierw przejrzyj strukturę informacji i elementy, które przekazują znaczenie lub uruchamiają działanie. Następnie ustal, które kryterium wymaga dalszej weryfikacji.
W praktycznym przeglądzie można zanotować pytania pomocnicze dotyczące alternatyw tekstowych przy obrazach, struktury nagłówków, zrozumiałości tekstów linków, rozróżnialności elementów wizualnych oraz obecności multimediów. Nie są one zamiennikiem kryteriów sukcesu ani gotową listą formalnego audytu. Ich funkcją jest wychwycenie treści i komponentów, które trzeba ocenić dokładniej.
W przypadku widoku telefonu nie oceniaj wyłącznie estetyki lub dopasowania układu. Sprawdź tę samą funkcję, którą wybrano w zakresie testu, ponieważ WCAG może być stosowane do stron używanych na urządzeniach mobilnych. Zagadnienia projektowania responsywnego rozwija osobny materiał: mobile first w praktyce.
Jak sprawdzić kluczową ścieżkę kontaktu, rezerwacji lub zakupu?
Kluczową ścieżkę biznesową należy przejść od początku do końca jako jedno zadanie, ponieważ poprawność pojedynczych ekranów nie przesądza o możliwości ukończenia procesu. Dla firmy usługowej będzie to zwykle wysłanie zapytania. Dla sklepu będzie to przejście od produktu do złożenia zamówienia.
Przygotuj prosty scenariusz, na przykład: znaleźć usługę, wybrać wariant, przejść do formularza i wysłać wiadomość. Przechodząc scenariusz, zapisuj punkt rozpoczęcia, każde wymagane działanie, komunikat zwrotny oraz rezultat. Powtórz próbę w sposób użyty podczas testu klawiaturą.
| Etap | Co zapisać | Przykład wyniku |
|---|---|---|
| Wejście | Strona i cel użytkownika | Użytkownik otwiera ofertę i szuka kontaktu. |
| Działanie | Element oraz sposób użycia | Przejście do formularza bez myszy. |
| Przeszkoda | Miejsce, skutek i warunki | Nie można rozpoznać aktywnego pola. |
| Rezultat | Czy zadanie zakończono | Wiadomość wysłana albo proces przerwany. |
Nie oceniaj w tym teście szybkości, bezpieczeństwa płatności ani poprawności integracji jako takich. Celem jest dostępność drogi do wykonania zadania. Jeśli proces kończy się w zewnętrznym systemie, zaznacz granicę odpowiedzialności w notatce i nie przypisuj bez sprawdzenia problemu stronie firmowej.
Jak dokumentować problemy i ustalać kolejność poprawek?
Wyniki wstępnej kontroli zapisuj w rejest