Obietnica i dla kogo
Masz 60 minut i chcesz wiedzieć, czy strona ma krytyczne problemy dostępnościowe oraz które poprawki priorytetować. Werdykt: wystarczy zestaw darmowych narzędzi (automaty + szybkie testy ręczne), aby wygenerować użyteczny, operacyjny raport — jeśli celem jest szybka decyzja biznesowa (priorytetyzacja napraw).
Szybkie pytania (i krótkie odpowiedzi)
Czy można ocenić dostępność bez kodu? Tak — automatyczne skany + proste testy ręczne dają szybki obraz, ale to nie pełna konformancja WCAG. ([webaim.org)
Czy darmowe narzędzia wystarczą? Na start tak — wykryją ~30–80% problemów zależnie od narzędzia; ręczne testy uzupełniają lukę. Jeśli potrzebujesz formalnego certyfikatu, przygotuj się na manualny audit. ([wsc.us.org)
Ile czasu zajmą poszczególne kroki? 60 minut: skan automatyczny (20–30 min), ręczne testy (15–20 min), zapis wyników i rekomendacje (10–15 min).
Czym jest test no-code (krótkie wyjaśnienie)
Test no-code to kombinacja darmowych narzędzi uruchamianych w przeglądarce plus prostych testów manualnych (np. nawigacja klawiaturą, szybkie sprawdzenie czytnika ekranu). W praktyce: używasz rozszerzeń i stron (Lighthouse/PageSpeed, WAVE, Axe/Accessibility Insights), a potem zapisujesz listę błędów i priorytetów. Podstawowym standardem odniesienia są wytyczne WCAG. ([w3.org)
Jak zacząć — krok po kroku (60 minut)
Przygotowanie (5–10 min)
Otwórz stronę, wyłącz rozszerzenia wpływające na wygląd (work in Incognito). Zapisz 3–5 reprezentatywnych adresów URL (strona główna, strona produktu, formularz).
Skan automatyczny (15–25 min)
Uruchom Lighthouse w Chrome DevTools lub PageSpeed Insights dla każdej URL. Eksportuj raporty PDF/HTML. Dlaczego: Lighthouse szybko wskazuje duże problemy (brak alt, kontrast, brak labeli). ([developer.chrome.com)
Dodatkowo uruchom WAVE lub rozszerzenie Axe DevTools w przeglądarce — WAVE daje wizualne oznaczenia na stronie, Axe podpowiada reguły i eksport. ([wave.webaim.org)
Szybkie testy ręczne (15–20 min)
Nawigacja klawiaturą: spróbuj przejść przez najważniejsze interakcje (menu, formy, CTA) bez myszy. Co to znaczy w praktyce: wszystkie istotne kontrolki muszą być dostępne tabami i wyraźnie fokusowane.
Czytnik ekranu (5–10 min): szybkie uruchomienie NVDA (Windows) lub VoiceOver (macOS) — sprawdź, czy kluczowe treści są czytane sensownie (nagłówki, etykiety formularzy). Jeśli nie masz czasu na full test, opisz co i gdzie sprawdzić w przyszłości. ([webaim.org)
Zapis i priorytety (10–15 min)
Eksport wyników z narzędzi, uzupełnij ręczne obserwacje, przypisz priorytety: P1 (blokujące dostęp), P2 (duże utrudnienia), P3 (usprawnienia). Na koniec 1-stronicowy raport z rekomendacjami.
Co to znaczy „priorytet P1” (krótko)
P1 — element uniemożliwiający wykonanie podstawowej akcji (np. brak labela w polu formularza wymaganym do zakupu). W praktyce: napraw to przed kolejną wersją produkcyjną.
Narzędzia (co użyć i dlaczego)
Poniżej krótkie zestawienie narzędzi, które w praktyce pozwolą wykonać audit bez kodu.
| Narzędzie | Co robi w 60 min | Mini-werdykt |
|---|---|---|
| Lighthouse (Chrome/PageSpeed) | Szybki, zautomatyzowany skan accessibility + punkty; łatwy eksport. | Dobry start. ([developer.chrome.com) |
| WAVE (WebAIM) | Wizualna analiza (ikony na stronie), dobra do edukacji i przeglądu elementów. | Praktyczne dla szybkich przeglądów. ([wave.webaim.org) |
| Axe DevTools (Deque) | Rozszerzenie z dokładnymi regułami, eksport i guidance; darmowa wersja pomaga wykryć krytyczne błędy. | Zalecane dla zespołów. ([deque.com) |
| Accessibility Insights | FastPass — szybkie wykrycie dużych problemów (mniej niż 5 min dla jednej strony). | Świetne do szybkiego screeningu. ([learn.microsoft.com) |
Fakt → Skutek → Werdykt (ważne informacje)
Fakt: Automatyczne narzędzia wykrywają tylko część problemów (Lighthouse ~30–40% typowych problemów, inne narzędzia zwiększają zasięg). ([wsc.us.org)
Skutek: Nie ufać jednemu skanowi jako dowodowi zgodności.
Werdykt: Użyj kombinacji narzędzi + prostych testów ręcznych; to minimalny akceptowalny workflow przy audycie 60-minutowym.Fakt: WCAG to formalne kryteria odniesienia (A/AA/AAA), stosowane jako standard. ([w3.org)
Skutek: Raport powinien odnosić się do poziomu konformancji (najczęściej AA).
Werdykt: W raporcie notuj który sukces kryterium WCAG został naruszony i daj link do dokumentacji. ([w3.org)
Typowe błędy, które znajdziesz w 60 minut
Brak alternatywnego tekstu dla obrazków krytycznych.
Niewystarczający kontrast tekstu względem tła.
Brak etykiet (label) w polach formularzy.
Elementy interaktywne nieosiągalne klawiaturą.
WebAIM i WAVE opisują, jak interpretować wyniki i które elementy wymagają manualnej weryfikacji. ([webaim.org)
Przykładowy szablon 1-stronicowego raportu (co wkleić)
Cel audytu, zakres (URL), data.
Najważniejsze 3 problemy (opis + dowód: screenshot + źródło z narzędzia).
Rekomendacja priorytetowa (P1/P2/P3) i estymowany wysiłek.
Linki do pełnych eksportów (Lighthouse JSON, WAVE/axe eksport).
Krótka lista „co sprawdzić dalej” (manualne testy, użytkownicy testowi).
Ograniczenia i jak je zweryfikować
Automaty nie zastąpią testów z prawdziwymi użytkownikami korzystającymi z czytników ekranu. Jeśli potrzebujesz formalnej certyfikacji zgodności z WCAG, zaplanuj pełny audit manualny lub zewnętrzną usługę audytorską. Możesz zweryfikować zakres automatycznego skanu, porównując listę błędów z instrukcjami WCAG (link w CTA). ([w3.org)
Plusy / minusy po takim 60-minutowym audycie
Plusy: szybki wgląd, niskie koszty (darmowe narzędzia), konkretne priorytety do backlogu.
Minusy: niepełna konkluzja o zgodności, potrzeba dodatkowych testów manualnych i testów z użytkownikami niepełnosprawnymi.
Podsumowanie: kiedy to ma sens, a kiedy nie
Idealne dla: właścicieli małych stron, PM-ów, zespołów marketingu, które chcą szybko zidentyfikować krytyczne problemy i zaplanować naprawy.
Będzie frustrować, wybierz inny sposób gdy: potrzebujesz formalnego orzeczenia zgodności z WCAG lub pracujesz na stronie rządowej/korporacyjnej z wymogami audytu — tu potrzebny pełny manualny audit.
Jednoznaczna puenta: Jeśli chcesz szybkie, praktyczne wyniki i plan naprawczy — zainwestuj 60 minut w kombinację Lighthouse + WAVE/Axe + ręczne testy. Jeżeli twoim celem jest certyfikacja prawna, potraktuj to jako pierwszy krok, nie koniec procesu. ([developer.chrome.com)
Źródła i narzędzia (do kliknięcia): WCAG — W3C. ([w3.org)
