Jak sprawdzić dostępność strony internetowej? Sprawdzone metody i narzędzia audytu, lista kontrolna, częste błędy, jak je wykryć?

Dostępność cyfrowa to nie tylko kwestia spełnienia wymagań prawnych (ustawa o dostępności cyfrowej, WCAG 2.1), lecz przede wszystkim dostarczenie wszystkim użytkownikom – także z niepełnosprawnościami – równego i komfortowego dostępu do treści. Audyt dostępności to proces kompleksowy: od zaplanowania zakresu testów, przez ich przeprowadzenie, aż po przygotowanie zrozumiałego raportu. Poniżej przedstawiamy ekspercki przewodnik, który pomoże Ci krok po kroku zorganizować i przeprowadzić skuteczną ocenę strony internetowej.

Definiowanie skali problemów

Metody ilościowe vs. jakościowe

• Ilościowo (procentowo) – wskazujesz, że np. „60 % przycisków na stronie głównej ma za niski kontrast”, „80 % formularzy jest niekompletnie opisanych”. Liczby pomagają osobom analitycznym i decydentom biznesowym uzmysłowić skalę problemu.
• Opisowo (wizualnie/subiektywnie) – formuły typu „większość funkcjonalności jest niedostępna”, „serwis w znacznym stopniu uniemożliwia korzystanie z klawiatury”. Taki przekaz trafia lepiej do osób, które oczekują szybkiej, narracyjnej oceny sytuacji.

Dobór metody

Poznaj odbiorców raportu: czy wolą konkretne dane, czy obraz typu „seryjna awaria”? Bywa, że najlepsze efekty daje połączenie obu stylów – najpierw procentowe zobiektywizowanie wniosków, a następnie podsumowanie wizualne czy opisowe.

Zakres i ścieżki użytkownika

Ustalenie ścieżek krytycznych

Zanim zaczniesz testy, zdecyduj, które procesy i podstrony są kluczowe dla użytkownika:

• strona główna (wejście bramą wielu odwiedzin)
• formularz rejestracji/logowania
• katalog produktów/artykułów
• proces zakupowy (dodanie do koszyka, checkout) lub proces składania wniosku
• regulaminy, polityki prywatności, dokumenty PDF

Testowanie powtarzalności błędów

Sprawdź, czy ten sam problem występuje:

• na różnych typach podstron (np. artykuły, produkty),
• w całym serwisie (wspólny szablon),
• jedynie w wybranych miejscach (indywidualne szablony).

Jeśli błąd jest globalny (np. za niski kontrast w nagłówku szablonu), poprawa jednego elementu szablonu naprawi go we wszystkich miejscach.

Testowanie techniczne

Przeglądarki i urządzenia

• Desktop: co najmniej trzy najpopularniejsze (Chrome, Firefox, Edge).
• Mobilne: Android (Chrome), iOS (Safari).
• Czytniki ekranu: NVDA/JAWS na Windows, VoiceOver na macOS/iOS.

Tip: pierwsze testy w nowej konfiguracji (przeglądarka × urządzenie) są najbardziej czasochłonne; kolejne powtórzenia tej samej ścieżki często idą szybciej.

Narzędzia wspomagające

• Rozszerzenia przeglądarki (np. WAVE, axe DevTools): szybka identyfikacja kontrastów, alt‑tekstu, struktury nagłówków.
• DevTools w Chrome/Firefox: inspekcja elementów, testowanie keyboard navigation (Tab Order), symulacja wad wzroku.
• Automatyczne skanery online (np. Lighthouse, Pa11y) – do wstępnego przeglądu.

Identyfikacja i klasyfikacja błędów względem WCAG

Priorytetyzacja

• Poziom A (absolutne minimum): zaburzona tabulacja (2.1.1), brak możliwości powiększenia tekstu do 200% (1.4.4), brak fokusowania padającego na elementy interaktywne.
• Poziom AA: niewystarczający kontrast (1.4.3), brak informacji o stanie elementu ARIA (aria-expanded), dynamiczne treści bez możliwości zatrzymania (2.2.2).
• Poziom AAA: dodatkowe wymagania, rzadziej krytyczne w podstawowym audycie.

Opis przykładowych błędów

1. Pułapka klawiaturowa: modal wymaga zamknięcia myszą – użytkownik klawiatury nie może „wyjść” z warstwy dialogowej.
2. Zbyt szybki slider: automatyczna karuzela zmienia slajdy co 3 s, bez przycisku PAUZA.
3. Niedostateczny kontrast tekstu: biały tekst (#FFFFFF) na jasnożółtym tle (#FFFFCC) – stosunek < 3:1.
4. Nieczytelny overlay mobilny: po wejściu na stronę główną baner modalny zasłania cały ekran i nie daje się zamknąć klawiaturą.
5. Brak deklaracji dostępności: instytucja publiczna nie zamieściła w stopce linku do deklaracji; przepis o co rocznej aktualizacji jest ignorowany.

Dokumentacja i raportowanie

Struktura dokumentu

1. Strona tytułowa
2. Spis treści
3. Wstęp: zakres audytu, data, zespół testujący, narzędzia.
4. Metodologia: opis środowisk testowych, grupy docelowej, kryteriów WCAG.
5. Najważniejsze wnioski (Top 3): opis problemu, screenshot, kryterium WCAG, wpływ na użytkownika.
6. Średni poziom problemów (Top 5)
7. Pozostałe błędy: tabela lub lista z odwołaniami do kryteriów.
8. Rekomendacje: konkretne wskazówki naprawcze, fragmenty kodu, odnośniki do dokumentacji.
9. Podsumowanie i harmonogram: które usprawnienia pilne (do miesiąca), które mogą poczekać.

Język i styl

• Zakładaj brak wiedzy technicznej po stronie odbiorcy.
• Tłumacz skróty i pojęcia (np. „WCAG to Wytyczne dla dostępności treści internetowych”).
• Wykorzystaj proste przykłady: „osoba niewidoma używa czytnika ekranu, więc bez poprawnego ARIA-label nie wie, co robi przycisk X”.
• Graficzne ilustracje – zrzuty ekranu z oznaczeniami problemów.

Case study: błąd z długością adresu IP na iPhone’ach

Podczas wdrożenia platformy e‑commerce dedykowanej klientom amerykańskim wykryto, że po zalogowaniu w Safari na iPhonie generowany jest błąd bazy danych. Przyczyna: iPhone dostarczał adres IP o długości 45 znaków, podczas gdy tabela w bazie przyjmowała maksymalnie 32. Testowanie na Chrome/Firefox w Androidzie i desktopie niczego nie wykazało. Rozwiązanie: rozszerzenie pola w bazie i testy na iOS z VoiceOver.

Wnioski:

• Uwzględnij specyfikę urządzeń i konfiguracji używanych przez grupę docelową.
• Zadbaj o testy na urządzeniach mobilnych (iOS/Android) oraz na różnych przeglądarkach.

Rekomendacje końcowe

1. Regularne testy w CI/CD – na przykład integracja z Lighthouse CI.
2. Edukacja zespołu – krótkie warsztaty dla deweloperów o najczęstszych błędach.
3. Kultura dostępności – wprowadzenie checklisty WCAG na każdym etapie projektu.
4. Feedback loop – formularz zgłaszania błędów dostępności otwarty dla użytkowników.
5. Monitorowanie deklaracji dostępności – coroczna aktualizacja i automatyczne powiadomienie zespołu.

Podsumowanie

Audyt dostępności to proces wieloetapowy: od planowania ścieżek użytkownika, przez testy na różnych środowiskach, po przygotowanie zrozumiałego raportu. Kluczem jest trafne zdiagnozowanie barier (zarówno ilościowe, jak i jakościowe), ich priorytetyzacja względem WCAG oraz dostarczenie konkretnych, wykonalnych rekomendacji. Dzięki temu każdy projekt stanie się bardziej użyteczny, zgodny z przepisami i przyjazny dla najszerszego grona odbiorców.