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 rejestrze, który umożliwi odtworzenie problemu po poprawce. Jest to praktyczne zalecenie redakcyjne dla właściciela strony, a nie wymagany format audytu WCAG. Dobry wpis pozwala osobie wdrażającej znaleźć element i zrozumieć, dlaczego utrudnia on wykonanie zadania.
- Podaj adres strony albo nazwę widoku.
- Opisz element i kroki prowadzące do problemu.
- Wskaż wpływ na użytkownika oraz przerwane zadanie.
- Dodaj roboczy priorytet: blokuje, poważnie utrudnia albo wymaga oceny.
- Po poprawce powtórz ten sam scenariusz i oznacz wynik.
Najpierw kieruj do poprawy przeszkody blokujące kontakt, rezerwację lub zakup. Potem zajmij się problemami powtarzającymi się w szablonach i materiałami często używanymi przez odbiorców. Taki porządek nie zastępuje oceny kryteriów sukcesu, ale pomaga rozsądnie planować pracę, gdy lista usterek jest długa.
Kiedy wstępna kontrola nie wystarcza?
Pogłębiony audyt ma uzasadnienie, gdy strona zawiera rozbudowane procesy, niestandardowe komponenty, sklep, liczne dokumenty albo gdy wstępny test wykazał przeszkody trudne do jednoznacznej oceny. Jest potrzebny również wtedy, gdy firma chce uporządkować wymagania względem określonego poziomu WCAG, a nie tylko usunąć zauważone problemy.
European Accessibility Act jest dyrektywą, której celem jest poprawa funkcjonowania rynku wewnętrznego dla dostępnych produktów i usług przez ograniczanie barier wynikających z różnych zasad w państwach UE. Komisja Europejska wymienia wśród objętych kategorii między innymi e-commerce. Informacja Komisji Europejskiej o European Accessibility Act nie oznacza jednak, że każda strona firmowa lub każdy sklep podlega identycznemu zakresowi obowiązków.
Ocena obowiązków wymaga odniesienia do konkretnego produktu lub usługi oraz właściwego kontekstu prawnego. Wstępny test techniczny nie jest interpretacją prawną i nie powinien być przedstawiany jako potwierdzenie spełnienia wymagań przez firmę.
Najczęstsze pytania
Dlaczego strona internetowa jest niedostępna?
Strona może być niedostępna dla części osób, mimo że otwiera się i wygląda poprawnie dla zespołu firmy. Problem pojawia się wtedy, gdy sposób przekazania informacji albo wykonania działania nie pozwala użytkownikowi samodzielnie osiągnąć celu. Przyczynę trzeba ustalić w konkretnej treści lub funkcji, odnosząc ją do kryteriów sukcesu WCAG, a nie tylko do ogólnego wrażenia z korzystania.
Co zrobić, gdy strona internetowa nie działa?
Niedziałanie strony jest problemem technicznym innym niż dostępność cyfrowa. Jeżeli serwis nie ładuje się, nie trzeba na tej podstawie wyciągać wniosku o zgodności lub niezgodności z WCAG. Najpierw przywróć możliwość korzystania ze strony w ramach obsługi technicznej. Dopiero po jej uruchomieniu wykonaj odrębny test dostępności treści i interfejsu.
Dlaczego strona internetowa się nie otwiera?
Brak możliwości otwarcia strony może wynikać z technicznej niedostępności serwisu, lecz ten artykuł nie służy do diagnozowania awarii. W kontekście dostępności warto odnotować, czy problem występuje na wybranej stronie lub w określonej ścieżce testu. Nie należy jednak utożsamiać błędu otwarcia z oceną według WCAG bez osobnej analizy.
Dlaczego strona internetowa jest zablokowana?
„Zablokowana” strona może oznaczać różne sytuacje techniczne lub organizacyjne, dlatego samo określenie nie pozwala ocenić dostępności. Jeśli blokada uniemożliwia wejście do serwisu, potraktuj ją jako temat dla osoby odpowiedzialnej za utrzymanie strony. W rejestrze dostępności można jedynie zaznaczyć, że danej funkcji nie dało się sprawdzić i test wymaga powtórzenia.
Jak ustalić kolejność poprawek dostępności?
Najpierw usuń przeszkody, które blokują kontakt, rezerwację albo zakup. Następnie zajmij się problemami powtarzającymi się w szablonach oraz w często używanych materiałach. Przy każdym zgłoszeniu zapisz wpływ na użytkownika i wynik ponownego testu po wdrożeniu poprawki.
Jak powinna wyglądać strona internetowa?
Strona dostępna nie ma jednego obowiązkowego wyglądu. W ocenie dostępności ważniejsze od stylu są informacje i funkcje, które można zrozumieć oraz wykorzystać w realnym zadaniu. Estetyczny projekt nie jest dowodem spełnienia kryteriów WCAG. Dlatego ocenę najlepiej oprzeć na reprezentatywnych widokach, interakcjach i udokumentowanych wynikach testu.
Jeśli wstępna kontrola ujawnia problemy w formularzu, procesie zakupu, menu lub niestandardowych komponentach, WEBEO może pomóc uporządkować zakres prac i wdrożyć poprawki podczas projektowania stron internetowych. Ma to szczególny sens przy przebudowie serwisu lub tworzeniu nowej strony, gdy dostępność można uwzględnić w strukturze i interfejsie.
