Jak sprawdzić dostępność strony: darmowe narzędzia i testy ręczne

Często słyszymy taką historię. Ktoś uruchamia Lighthouse, dostaje zielone 100 za dostępność i zajmuje się czymś innym. Tydzień później klient pisze, że nie mógł zapłacić, bo do formularza karty nie da się dotrzeć klawiaturą. Obie rzeczy są prawdą. Test automatyczny wypadł pomyślnie, a strona i tak zawiodła prawdziwego człowieka.

Ten przewodnik pokazuje, jak rzetelnie testować przy małym budżecie: jakie bezpłatne narzędzia uruchomić, jak wygląda 15-minutowa rutyna ręcznych testów, jak zacząć z czytnikiem ekranu i kiedy zapłacić za audyt.

Czy narzędzie automatyczne powie mi, czy moja strona jest dostępna?

Nie. Narzędzia automatyczne szybko znajdują część problemów, ale na wiele pytań o dostępność musi odpowiedzieć człowiek. Gdy brytyjska Government Digital Service przetestowała 10 narzędzi na stronie ze 143 znanymi błędami, najlepsze znalazło 41%. W3C mówi wprost: narzędzia do oceny „nie mogą określić dostępności, mogą jedynie w tym pomóc”.

Test GDS (otwiera się w nowej karcie) pochodzi z lutego 2017 r., a jego 41% (wynik narzędzia Asqatasun) obejmowało podpowiedzi narzędzia dotyczące testów ręcznych. Narzędzia od tego czasu się poprawiły, ale luka ma tę samą przyczynę. Oprogramowanie wykryje, że obraz nie ma tekstu alternatywnego. Nie rozpozna jednak, że „czerwona sukienka” to zły opis zdjęcia niebieskiego garnituru, ani tego, czy kolejność fokusu ma sens.

Traktuj więc takie narzędzie jak czujnik dymu, a nie jak ekspertyzę budowlaną. Mimo to warto je uruchamiać: WebAIM Million 2026 (otwiera się w nowej karcie) wykrył błędy na 95,9% z miliona najpopularniejszych stron głównych, więc większość stron ma coś do szybkiej poprawy. Jak pisze W3C w przewodniku po wyborze narzędzi (otwiera się w nowej karcie): „Potrzebna jest ludzka ocena”.

Z jakich bezpłatnych narzędzi do testowania dostępności korzystać?

Użyj jednego lub dwóch narzędzi automatycznych, narzędzia do sprawdzania kontrastu i czytnika ekranu. Narzędzia stosują różne reguły i inaczej raportują wyniki, więc dwa zwykle wychwytują więcej niż jedno. Każde z poniższych ma bezpłatną wersję. Zanim na którymś się oprzesz, sprawdź aktualne warunki, bo nazwy, funkcje i ceny się zmieniają.

Co mogę sprawdzić ręcznie w 15 minut?

Całkiem sporo. Easy Checks (otwiera się w nowej karcie), czyli proste testy W3C, obejmują tytuły stron, teksty alternatywne, nagłówki, kontrast, linki pomijające, widoczny fokus klawiatury, język strony, powiększenie, napisy i etykiety pól formularzy. Wybierz jedną ważną stronę, np. stronę produktu albo formularz rezerwacji, i poświęć każdemu testowi minutę lub dwie. Znajdziesz rzeczy, których nie zgłosi żadne narzędzie.

W3C zaznacza, że te testy „obejmują tylko kilka zagadnień dostępności”, więc nie są pełną oceną. To i tak najlepiej wykorzystany kwadrans:

1. Tytuł strony (1 minuta). Czy karta przeglądarki mówi, czym jest strona, np. „Zarezerwuj stolik | Bistro u Zosi”, zamiast wszędzie „Strona główna”?
2. Obrazy (2 minuty). Wyświetl teksty alternatywne za pomocą WAVE lub podobnego narzędzia. Czy są trafne? Czy elementy dekoracyjne są pomijane?
3. Nagłówki (2 minuty). Wyświetl listę nagłówków i przeczytaj je osobno. Czy działają jak spis treści?
4. Kontrast (2 minuty). Sprawdź tekst główny, drobny szary tekst, tekst na przyciskach i tekst na obrazach.
5. Klawiatura (4 minuty). Odłóż mysz i przejdź przez stronę klawiszem Tab (więcej w następnej sekcji).
6. Powiększenie (2 minuty). Czy przy 200%, a potem 400% nadal da się wszystko przeczytać i korzystać z menu bez przewijania w bok?
7. Formularze i język (2 minuty). Kliknij etykietę każdego pola; w dobrze zbudowanym formularzu kursor przeskoczy do pola. Sprawdź w raporcie narzędzia, czy nie brakuje określenia języka strony.

Jak przetestować stronę klawiaturą?

Odłóż mysz. Naciskaj Tab, by przejść dalej, Shift+Tab, by wrócić, Enter, by otworzyć link, spację lub Enter, by nacisnąć przycisk, i strzałki w menu i przy przyciskach opcji. Każdy element interaktywny powinien być osiągalny, zawsze powinno być widać, gdzie jesteś, a utknąć nie powinno się nigdzie.

Na Macu Safari pomija linki przy naciskaniu Tab, dopóki w ustawieniach zaawansowanych nie włączysz opcji wyróżniania klawiszem Tab każdego elementu strony (w wersji angielskiej „Press Tab to highlight each item on a webpage”). Potem sprawdź:

• Czy zawsze widać, gdzie jesteś? Jeśli obrys fokusu znika, użytkownik klawiatury się gubi.
• Czy kolejność jest logiczna? Fokus powinien podążać za kolejnością czytania.
• Czy coś jest zasłonięte? Przyklejony nagłówek albo baner cookies, który zasłania element z fokusem, narusza kryterium Focus Not Obscured z WCAG 2.2.
• Czy da się wyjść? Otwórz każde menu, wyskakujące okno i kalendarz, a potem spróbuj je opuścić. Escape powinien zamykać okna dialogowe.
• Czy działa cała ścieżka? Dodaj produkt, zmień ilość, wpisz kod rabatowy i dojdź do płatności bez myszy.

Każdy błąd zapisuj precyzyjnie: „Na stronie produktu nie da się otworzyć wyboru rozmiaru klawiszem Enter ani spacją” zostanie naprawione znacznie szybciej niż „klawiatura nie działa”.

Jak po raz pierwszy przetestować stronę czytnikiem ekranu?

Zacznij od czytnika ekranu wbudowanego w Twoje urządzenie albo od NVDA na Windows i posłuchaj jednej strony. Nie próbujesz posługiwać się nim jak ekspert. Sprawdzasz, czy nagłówki, linki, przyciski, obrazy i pola formularzy są odczytywane z sensownymi nazwami i czy nic ważnego nie milczy.

• Mac: Command+F5 włącza i wyłącza VoiceOver; Control+Option+U otwiera pokrętło, czyli listę nagłówków, linków i kontrolek formularzy.
• Windows: w NVDA klawisz H przenosi między nagłówkami, a Insert+F7 wyświetla listę linków i nagłówków.
• Telefon: włącz VoiceOver (iPhone) lub TalkBack (Android) i przesuwaj palcem w prawo, by przechodzić między elementami. Najpierw naucz się, jak go wyłączyć.

Wsłuchaj się w to, co najważniejsze. W ankiecie WebAIM wśród użytkowników czytników ekranu z 2024 r. (otwiera się w nowej karcie) 71,6% respondentów odpowiedziało, że długą stronę przeglądają najpierw po nagłówkach, więc zacznij od nich. Potem otwórz listę linków: pięć linków „Czytaj więcej” nikomu nic nie mówi. „Dodaj do koszyka, granatowy sweter” to przydatny przycisk, samo „przycisk” już nie. Na koniec wypełnij formularz i sprawdź, czy każde pole i każdy błąd są odczytywane.

Wnioski formułuj ostrożnie. Jeśli coś brzmi dla Ciebie źle, prawdopodobnie jest źle; jeśli brzmi dobrze, to jeszcze nie dowód. Jak naprawdę pracują doświadczeni użytkownicy, opisujemy w artykule jak osoby z niepełnosprawnościami korzystają z internetu.

Jak sprawdzić powiększenie, dopasowanie do ekranu i odstępy w tekście?

Powiększ widok w przeglądarce do 200% i sprawdź, czy tekst się powiększa bez ucinania i nachodzenia na inne elementy. Potem przetestuj dopasowanie do ekranu: przy powiększeniu 400% w oknie o szerokości 1280 pikseli treść powinna się mieścić bez przewijania w bok. Na koniec zwiększ odstępy między literami, wyrazami, wierszami i akapitami i sprawdź, czy nic się nie psuje ani nie znika.

Odpowiadają temu kryteria WCAG 1.4.4 Zmiana rozmiaru tekstu, 1.4.10 Dopasowanie do ekranu (otwiera się w nowej karcie) i 1.4.12 Odstępy w tekście (otwiera się w nowej karcie). Dopasowanie do ekranu opiera się na szerokości 320 pikseli CSS, co według W3C „odpowiada początkowej szerokości okna 1280 pikseli CSS przy powiększeniu 400%”. Kryterium odstępów wymaga, by nic nie ginęło, gdy czytelnik ustawi wysokość wiersza na 1,5 rozmiaru czcionki, odstęp między akapitami na dwukrotność rozmiaru czcionki, odstęp między literami na 0,12, a między wyrazami na 0,16 rozmiaru czcionki.

Bookmarklet do testowania odstępów, czyli mały skrypt zapisany jako zakładka, jednym kliknięciem stosuje wszystkie cztery wartości. Szukaj tekstu, który wylewa się z przycisków, i etykiet uciętych przy krawędzi. Przy powiększeniu 400% laptop pokazuje mniej więcej to, co mały telefon, więc dobrze zbudowana strona responsywna w dużej mierze przejdzie te testy.

Jak sprawdzić formularze, komunikaty o błędach i proces zamówienia?

Wypełnij każdy ważny formularz trzy razy: raz poprawnie, raz z wszystkimi polami pustymi i raz z celowymi błędami. Każde pole powinno mieć widoczną etykietę, każdy błąd powinien być wyjaśniony słowami przy swoim polu, a w pola hasła i kodu weryfikacyjnego powinno dać się wklejać.

• Błędy. Czerwone „Nieprawidłowe dane” nie wystarczy. „Wpisz datę ważności w formacie MM/RR” przy polu już tak. Po wysłaniu formularza fokus powinien przejść do podsumowania błędów albo do pierwszego błędnego pola.
• Logowanie i kody. Zgodnie z kryterium dostępnego uwierzytelniania (otwiera się w nowej karcie) z WCAG 2.2 blokowanie wklejania lub menedżerów haseł nie spełnia wymagań, chyba że istnieje inny sposób logowania.
• CAPTCHA i limity czasu. W ankiecie WebAIM użytkownicy czytników ekranu uznali CAPTCHA za najbardziej problematyczny element internetu. Sprawdź, czy jest dostępna alternatywa i czy limity czasu da się przedłużyć.

Pełniejszą listę dla sklepów, łącznie z banerami cookies i wyskakującymi oknami, zawiera nasza lista kontrolna dostępności strony.

Co obejmuje profesjonalny audyt dostępności i kiedy jest potrzebny?

Audyt dostępności to uporządkowany przegląd przeprowadzany przez specjalistę według wskazanej normy, zwykle WCAG 2.1 lub 2.2 na poziomie AA. Łączy skany automatyczne z ręcznymi testami i testami z użyciem technologii wspomagających na kluczowych szablonach i ścieżkach, a kończy się raportem z priorytetami. Potrzebujesz go, gdy obejmują Cię przepisy, przed dużym wdrożeniem albo gdy klienci proszą o dowody.

Zanim uzgodnisz cenę, zapytaj:

• Według jakiej normy, wersji i poziomu będziecie testować?
• Jakie szablony i ścieżki obejmuje audyt? W przypadku sklepu: strona główna, kategoria, produkt, koszyk, zamówienie, konto i formularze.
• Czy testujecie ręcznie czytnikami ekranu, klawiaturą i powiększeniem, a jeśli tak, na jakich przeglądarkach i urządzeniach?
• Czy raport szereguje problemy według wagi, wskazuje, gdzie występują, i proponuje poprawki?
• Czy ponowny test jest w cenie?

Ceny bardzo się różnią w zależności od wykonawcy, kraju i zakresu, więc porównuj to, co obejmują. Jeśli podlegasz Europejskiemu aktowi w sprawie dostępności, audyt jest też podstawą Twojej publicznej deklaracji; kogo obejmuje akt, wyjaśnia nasz przewodnik po EAA.

Dlaczego warto testować z udziałem osób z niepełnosprawnościami?

Bo spełnianie normy i łatwość obsługi to nie to samo. Proces zamówienia może spełniać każde kryterium WCAG, a mimo to zajmować użytkownikowi czytnika ekranu dwadzieścia minut. W3C pisze, że ocena z udziałem użytkowników z niepełnosprawnościami „wskazuje problemy z użytecznością, których nie wykrywa sama ocena zgodności”, a do tego pokazuje zespołowi, jak ludzie naprawdę korzystają ze strony.

Nie potrzebujesz laboratorium. Kilka sesji poświęconych najważniejszemu zadaniu, np. znalezieniu produktu i zapłacie, nauczy Cię więcej niż kolejna runda skanów. Uczestników szukaj przez organizacje osób z niepełnosprawnościami, agencje badawcze albo wśród własnych klientów i płać im za poświęcony czas. Pozwól im korzystać z własnych urządzeń i ustawień. Praktyczną stronę opisuje przewodnik W3C o angażowaniu użytkowników w ocenę (otwiera się w nowej karcie).

Co zrobić z wynikami?

Uporządkuj problemy według tego, jak bardzo blokują ludzi i gdzie występują, napraw je we własnym kodzie i treściach strony, przetestuj ponownie i zapisz, co pozostało do zrobienia. Pole bez etykiety w procesie zamówienia jest ważniejsze niż drobny problem z kontrastem w stopce, a poprawka we wspólnym szablonie naprawia każdą stronę, która z niego korzysta.

1. Ustal priorytety. Najpierw blokery na kluczowych ścieżkach (zamówienie, rezerwacja, rejestracja), potem wspólne szablony, na końcu pojedyncze strony.
2. Naprawiaj u źródła. Zmieniaj motyw, komponent lub treść, a nie tylko objaw.
3. Testuj ponownie. Powtórz te same testy, zarówno ręcznie, jak i narzędziami.
4. Dokumentuj. Wypisz znane problemy z datami w deklaracji dostępności. Nowsze kryteria wyjaśnia nasz przewodnik po WCAG 2.2.
5. Powtarzaj. Dodaj test klawiaturą i skan do każdego wydania.

Jeśli korzystasz z widżetu dostępności, także naszego, testuj przy zamkniętym panelu. Panel taki jak SiteAccessible daje odwiedzającym dodatkowe sposoby dostosowania strony, ale WCAG ocenia, czy strona działa w stanie domyślnym. Niektóre systemy audytu nie oceniają stron, na których działa skrypt nakładki, więc najpierw ustal to z audytorem.