Dostępność cyfrowa to nie jednorazowe „odhaczanie” WCAG, lecz świadome projektowanie serwisu tak, by był używalny dla jak najszerszej grupy osób – także użytkowników z niepełnosprawnościami, korzystających z klawiatury, czytników ekranu i urządzeń mobilnych.
Dobrze przygotowana checklista dostępności (a11y) zamienia abstrakcyjne kryteria WCAG na konkretne, powtarzalne kroki do sprawdzenia na każdej stronie i w każdym kluczowym procesie serwisu.
Na czym oprzeć checklistę – WCAG i zasady POUR
Podstawą większości checklist są wytyczne WCAG (Web Content Accessibility Guidelines), w praktyce najczęściej stosowany poziom WCAG 2.1 AA.
WCAG opiera się na czterech zasadach POUR (Perceivable, Operable, Understandable, Robust – Postrzegalność, Funkcjonalność, Zrozumiałość, Solidność):
- Postrzegalność – treść musi dać się odebrać różnymi zmysłami (np. tekst alternatywny dla obrazów);
- Funkcjonalność – interfejs da się obsłużyć różnymi metodami (klawiatura, czytnik ekranu, urządzenia mobilne);
- Zrozumiałość – treść i interfejs są przewidywalne, logiczne, pisane zrozumiałym językiem;
- Solidność – kod współpracuje z różnymi technologiami asystującymi (czytniki ekranu, lupy ekranowe itp.).
Poziom dostępności strony określa się, badając wybrane widoki pod kątem wszystkich odpowiednich kryteriów sukcesu WCAG 2.1 AA. Niektóre organizacje stosują uproszczone checklisty – np. 14 kluczowych kryteriów pokrywających ok. 50% wymagań WCAG 2.1 AA – jako szybki screening najważniejszych problemów.
W Polsce dostępne są gotowe listy kontrolne do samodzielnego badania dostępności, przygotowane m.in. przez administrację publiczną. Prowadzą krok po kroku przez ocenę strony (np. klawiatura, kontrast, multimedia).
Zanim sięgniesz po checklistę – przygotowanie audytu
Wybierz zakres – które podstrony i procesy są kluczowe
Zacznij od wyboru kluczowych podstron i procesów, przez które przechodzą realni użytkownicy:
- strony startowe i strony wejścia z wyszukiwarki (np. landing page, artykuły),
- procesy biznesowe: rejestracja, logowanie, zakup, złożenie zamówienia, kontakt, płatność, wysłanie formularza itp.,
- typowe szablony: artykuł, lista produktów, karta produktu, formularz kontaktowy.
Skup się na widokach istotnych dla ukończenia zadania (np. dokończenie zakupu), zamiast próbować testować „cały serwis” naraz.
Przygotuj środowisko testowe i narzędzia
Do rzetelnych testów dostępności przygotuj poniższy zestaw narzędzi i środowisk:
- przeglądarki desktop – co najmniej Chrome, Firefox, Edge;
- przeglądarki mobilne – np. Chrome na Androidzie i Safari na iOS;
- czytniki ekranu – NVDA lub JAWS na Windows oraz VoiceOver na macOS/iOS;
- narzędzia automatyczne – WAVE i axe do analizy błędów dostępności w przeglądarce, ARC Toolkit jako rozszerzenie do Chrome, a także wbudowane audyty w narzędziach deweloperskich;
- walidator HTML – do weryfikacji poprawności składni jako wskaźnik „solidności” kodu.
Automatyczne skanowanie to tylko jeden krok – potrzebne są także testy manualne oraz – jeśli to możliwe – badania z użytkownikami z niepełnosprawnościami.
Zespół i proces
Dobrą praktyką jest zaangażowanie kilku ról, aby spojrzeć na dostępność z różnych perspektyw:
- programistów (frontend / backend),
- projektantów UX/UI,
- osób odpowiedzialnych za treści,
- osób z niepełnosprawnościami, które przetestują serwis z perspektywy własnych potrzeb.
Regularne, iteracyjne testy i poprawki na bieżąco pozwalają wychwycić problemy, które łatwo przeoczyć na etapie developmentu.
Checklista dostępnej strony – obszary, które trzeba sprawdzić
Poniższa checklista łączy praktyczne testy manualne, wybrane punkty z publicznych list kontrolnych oraz dobre praktyki audytowe. Każdy punkt zawiera co sprawdzić i jak to przetestować w praktyce.
Struktura i semantyka HTML
Cel – strona ma logiczną strukturę, zrozumiałą dla czytników ekranu i technologii asystujących.
Co sprawdzić:
- tytuł strony – jest jeden, unikalny i opisuje zawartość (
<title>); - hierarchia nagłówków – poprawna kolejność
<h1>–<h6>bez przeskoków poziomów; - landmarki – właściwe znaczniki sekcji, np.
<main>,<nav>,<header>,<footer>,<aside>; - listy i tabele – listy z
<ul>/<ol>/<li>, a tabele wyłącznie do danych, nie do layoutu.
Jak testować: uruchom czytnik ekranu (np. NVDA) i przejdź po nagłówkach oraz regionach – struktura powinna „czytać się” jak spis treści; następnie użyj walidatora HTML, aby wykryć błędy składni i nieprawidłowe użycie elementów.
Nawigacja klawiaturą i fokus
Jednym z najprostszych, a zarazem najważniejszych testów jest test klawiatury (TAB).
Co sprawdzić:
- pełna obsługa bez myszy – przy użyciu
Tab,Shift+Tab,Enter,Spacjai strzałek; - dostępność elementów aktywnych – linków, przycisków, pól formularzy, list rozwijanych itp.;
- widoczny fokus – wyraźny wskaźnik na aktualnie aktywnym elemencie;
- logiczna kolejność fokusu – zgodna z wizualnym układem strony.
Jak testować:
- Odłóż myszkę. Używaj tylko klawiatury.
- Przechodź po stronie klawiszem
Tab, aktywuj elementyEnter/Spacja. - Zapisz miejsca, w których:
- fokus „znika” (brak widocznego wskaźnika),
- nie możesz wejść w jakiś element (np. pseudo-przycisk jako
divbez obsługi klawiatury), - nie da się zamknąć modala czy menu bez użycia myszy.
Jeśli strony nie da się w pełni obsłużyć klawiaturą, jest niedostępna.
Skalowanie, responsywność i powiększanie do 200%
Dostępność to także komfort przy dużym powiększeniu treści, zwłaszcza dla osób słabowidzących.
Co sprawdzić:
- powiększenie do 200% – layout pozostaje używalny, a tekst nie ucieka poza ekran;
- przewijanie poziome – jest ograniczone do minimum, główne funkcje pozostają dostępne;
- działanie mobilne – poprawne renderowanie i nawigacja w przeglądarkach na Androidzie i iOS.
Jak testować: na desktopie powiększ stronę do 200% i sprawdź treści oraz interakcje; następnie przejrzyj kluczowe podstrony w Chrome na Androidzie i Safari na iOS, ze szczególnym uwzględnieniem elementów interaktywnych.
Kontrast kolorów i czytelność
Słaby kontrast utrudnia korzystanie z serwisu osobom z osłabionym wzrokiem i w trudnych warunkach oświetleniowych.
Co sprawdzić:
- kontrast tekstu – zgodność z wymaganiami WCAG AA względem tła;
- kontrast elementów UI – teksty na obrazach, ikony, przyciski;
- kolor jako nośnik – nie jest jedynym nośnikiem informacji (wspierają go ikony/opisy).
Jak testować: użyj wtyczek (WAVE, axe, ARC Toolkit) do automatycznego wykrycia części problemów z kontrastem; ręcznie sprawdź newralgiczne miejsca (CTA, linki w treści, komunikaty o błędach) przy różnych powiększeniach.
Obrazy, ikony, infografiki – tekst alternatywny
Dla użytkowników czytników ekranu obrazy są „niewidoczne”, jeśli nie mają odpowiedniego opisu.
Co sprawdzić:
- teksty alternatywne – wszystkie istotne obrazy mają atrybut
altopisujący zawartość; - obrazy dekoracyjne – mają pusty
alt(alt=""), by były pomijane; - grafiki funkcjonalne – alternatywa opisuje funkcję („Dodaj do koszyka”), nie wygląd („ikona koszyk”).
Jak testować: przejdź po grafikach czytnikiem ekranu i oceń sensowność opisów; następnie użyj narzędzi automatycznych (WAVE, axe), by wykryć brakujące alt.
Materiały edukacyjne podkreślają, że tekst alternatywny powinien:
dokładnie opisać, co mamy na obrazku
Multimedia – wideo, audio, animacje
Multimedia bez alternatyw (napisy, transkrypcje) są niedostępne dla osób niesłyszących i niewidomych.
Co sprawdzić:
- napisy do wideo – co najmniej z dialogami;
- obsługa klawiaturą – start/stop, przewijanie;
- dostępność odtwarzacza – poprawne etykiety i kolejność fokusu dla czytnika ekranu;
- transkrypcja – dostępna, jeśli materiał wideo jest kluczowy merytorycznie.
Jak testować: uruchom film i obsłuż go wyłącznie klawiaturą (Tab, Enter, Spacja); włącz czytnik ekranu i sprawdź nazwy przycisków oraz dostęp do wszystkich funkcji.
Formularze – etykiety, błędy, walidacja
Formularze to częste źródło krytycznych problemów z dostępnością.
Co sprawdzić:
- etykiety pól – każde pole ma jednoznaczną etykietę (
<label>) opisującą oczekiwaną treść; - powiązanie etykiet – etykieta powiązana z polem (np.
for/id) i widoczna dla czytnika ekranu; - oznaczenie wymagalności – w sposób inny niż sam kolor (np. tekst „pole wymagane”);
- komunikaty o błędach – spełniają kluczowe warunki:
W komunikatach o błędach potwierdź, że:
- pojawiają się blisko pola, którego dotyczą,
- są opisowe (np. „Podaj poprawny adres e‑mail”),
- są dostępne dla czytników ekranu.
Jak testować: wypełnij formularz błędnie (pusty, z niewłaściwym formatem), a potem sprawdź czytelność i dostępność komunikatów; następnie przejdź cały formularz wyłącznie klawiaturą, upewniając się, że fokus się nie gubi, a przyciski działają pod Enter/Spacja.
Wytyczne frameworków front-endowych podkreślają, że każdy element kontrolujący formularz powinien mieć etykietę opisaną w sposób przystępny i czytelną dla czytników ekranu.
Język, nagłówki i treść
Czytelność treści jest równie ważna jak techniczna poprawność.
Co sprawdzić:
- język dokumentu – ustawiony na każdej stronie (np.
lang="pl"); - nagłówki – jasno opisują sekcje i nie służą wyłącznie do stylowania;
- teksty linków – są zrozumiałe (np. „Pobierz raport PDF”, a nie „kliknij tutaj”).
Zweryfikuj to, „odsłuchując” stronę czytnikiem ekranu i oceniając, czy treść jest zrozumiała bez kontekstu wizualnego.
Interaktywne komponenty i ARIA
Nowoczesne aplikacje webowe wykorzystują złożone komponenty (modale, dropdowny, karuzele). W kluczowych miejscach liczy się solidność i poprawna współpraca z technologiami asystującymi.
Co sprawdzić:
- natywne elementy HTML – preferuj
<button>,<a>,<input>zamiastdiv/spanudających przyciski; - atrybuty ARIA – dla niestandardowych komponentów rola i stan są opisane poprawnie;
- zarządzanie fokusem – po otwarciu modalnego okna fokus trafia do modala, po zamknięciu wraca w logiczne miejsce.
Jak testować: przejdź po komponentach klawiaturą i z czytnikiem ekranu, weryfikując role, etykiety i aktywację; porównaj zachowanie z natywnymi odpowiednikami (np. <select>).
Prawidłowe użycie semantyki HTML i ARIA jest kluczowe, by strona była „solidna” i współpracowała z różnymi technologiami.
Migające elementy i bezpieczeństwo dla osób z padaczką
Niektóre efekty wizualne mogą wywoływać ataki u osób z padaczką fotosensytywną. Wykonaj następujące kontrole:
- elementy błyskające na czerwono – zidentyfikuj je i oceń ich intensywność;
- częstotliwość błysków – jeśli występuje 3 lub więcej błysków w ciągu sekundy, strona jest uznawana za niedostępną;
- gwałtowne zmiany jasności – sprawdź, czy występują i czy nie dominują w odbiorze;
- powierzchnia zmian – jeśli zajmują ponad 25% powierzchni strony, to poważny problem dostępności.
To kryteria, które można bezpośrednio odhaczyć w checklistach udostępnianych przez administrację publiczną.
Łączenie checklisty z narzędziami automatycznymi
Checklisty są najskuteczniejsze, gdy łączysz je z automatycznymi skanerami i testami manualnymi.
Co wykryją narzędzia automatyczne
Narzędzia takie jak WAVE, axe czy ARC Toolkit pomagają wykryć m.in.:
- brak tekstu alternatywnego przy obrazach,
- brak etykiet przy polach formularzy,
- część problemów z kontrastem,
- błędy w strukturze nagłówków,
- niektóre nieprawidłowości w ARIA.
Automatyczne skanowanie kodu pozwala szybko zidentyfikować typowe problemy przeoczone w trakcie developmentu.
Czego nie wykryją automaty
Narzędzia automatyczne nie odpowiedzą na pytania:
- czy tekst alternatywny jest sensowny i adekwatny,
- czy opis błędu jest zrozumiały dla użytkownika,
- czy kolejność fokusu jest naprawdę logiczna,
- czy użytkownik z czytnikiem ekranu jest w stanie wykonać zadanie „od A do Z”.
Dlatego niezbędne są również:
- testy manualne – klawiatura, powiększenie, scenariusze end‑to‑end;
- testy z czytnikiem ekranu – w kluczowych scenariuszach;
- testy z udziałem realnych użytkowników – jeśli to możliwe, z różnymi niepełnosprawnościami.
„Szybka” checklista – prosty audyt w 1–2 godziny
Chcesz szybko zorientować się w poziomie dostępności? Skorzystaj z wybranych, kluczowych kryteriów. Sprawdź kilka podstawowych widoków (np. strona główna, artykuł, formularz kontaktowy, koszyk) pod kątem ok. 14 krytycznych kryteriów, pokrywających ok. 50% WCAG 2.1 AA.
Przykładowy skrócony zestaw kroków do wykonania na każdej wybranej podstronie:
- Nawigacja klawiaturą – pełna obsługa bez myszy, widoczny fokus.
- Kontrast tekstu i ważnych elementów – brak rażąco niskiego kontrastu.
- Powiększenie do 200% – treść nie ucieka poza ekran, strona jest używalna.
- Nagłówki i tytuł – logiczna struktura, sensowny tytuł strony.
- Obrazy – istotne mają sensowny
alt, dekoracyjne – pustyalt. - Formularze – etykiety, komunikaty o błędach, obsługa klawiaturą.
- Multimedia – napisy do wideo, obsługa z klawiatury.
- Czytnik ekranu – test minimum jednego scenariusza (np. znalezienie kontaktu) z użyciem NVDA.
Takie „proste audyty” to świetny pierwszy krok dla organizacji zaczynających pracę z dostępnością.
Jak dokumentować wyniki checklisty
Dobrze udokumentowany audyt pozwala przełożyć checklistę na konkretne zadania. Poniżej rekomendowana struktura dokumentu:
- Strona tytułowa – zakres audytu, badana wersja serwisu, zespół testujący, użyte narzędzia;
- Metodologia – opis środowisk testowych (przeglądarki, czytniki ekranu), grup docelowych i kryteriów WCAG, na których opierasz checklistę;
- Najważniejsze wnioski (Top 3) – opis najpoważniejszych problemów (np. brak obsługi klawiaturą w koszyku), z informacją:
W ramach Top 3 doprecyzuj:
- gdzie występują,
- które kryterium WCAG naruszają,
- jaki mają wpływ na użytkownika.
- Średni poziom problemów (Top 5) – np. słabszy kontrast w niektórych miejscach, drobne błędy etykiet;
- Pozostałe błędy – lista problemów z lokalizacją i odniesieniem do kryteriów WCAG;
- Rekomendacje – konkretne wskazówki naprawcze, ewentualnie z fragmentami kodu lub odwołaniami do dokumentacji (np. jak poprawnie powiązać
labelzinput).
Tak przygotowany dokument ułatwia planowanie prac naprawczych i osadza dostępność na stałe w procesie developmentu.
Checklista jako element procesu, nie jednorazowa akcja
Doświadczenia zespołów technicznych pokazują, że dostępność wymaga regularnych testów – tak jak bezpieczeństwo czy wydajność.
W praktyce oznacza to m.in.:
- checklistę a11y w DoD – włącz jej podstawową wersję do definicji „gotowe do wdrożenia”;
- okresowe audyty – np. raz w roku, z użyciem rozbudowanych list kontrolnych i narzędzi;
- ciągłe doskonalenie – reagowanie na zgłoszenia użytkowników i stałe poprawianie aplikacji.
Na rynku znajdziesz wiele gotowych checklist i zestawów narzędzi, agregowanych przez serwisy branżowe i portale o dostępności cyfrowej. Traktuj je jako żywe dokumenty, które ewoluują wraz z projektem i kolejnymi wersjami standardów (np. WCAG 2.2 i kolejne).
Dobrze zbudowana, dostosowana do Twojego serwisu checklista sprawia, że „zgodność z a11y” staje się zbiorem konkretnych, powtarzalnych kroków do wykonania przy każdym wdrożeniu.
