Najważniejsze wnioski
- Automatyczny skan jest użytecznym etapem audytu, ale nie oceni wielu barier związanych z klawiaturą, focusem, logiką interfejsu i przebiegiem zadania użytkownika.
- Zakres audytu WCAG powinien obejmować nie tylko stronę główną, lecz także reprezentatywne szablony, formularze, komunikaty błędów oraz kluczowe procesy biznesowe, takie jak koszyk i płatność.
- Raport z audytu jest wartościowy wtedy, gdy opisuje barierę, jej wpływ na użytkownika, właściwe kryterium, miejsce występowania i rekomendowaną naprawę źródłową.
- Widget dostępności może szybko dodać funkcje wspierające użytkownika, jednak nie zastępuje audytu WCAG, testów ani trwałych poprawek w kodzie i treści.
- WCAG, EN 301 549 i wymagania ustawowe mają różne role. Przed zleceniem audytu należy jasno nazwać standard, poziom, zakres produktu i wyłączenia.
Dla zarządzającego
Audyt WCAG pomaga podjąć decyzję, gdzie bariery wpływają na obsługę klienta i ryzyko operacyjne. Największą wartość daje połączenie listy usterek z planem napraw, właścicielami zadań oraz kontrolą kluczowych ścieżek użytkownika.
Dla sprzedaży
Dostępny formularz kontaktowy, katalog, koszyk i płatność ograniczają sytuacje, w których użytkownik nie może samodzielnie wykonać działania. Zespół sprzedaży powinien przekazywać zgłoszenia o barierach do zespołu odpowiedzialnego za stronę i nie obiecywać pełnej zgodności na podstawie samego widgetu.
Audyt WCAG odpowiada na praktyczne pytanie: czy użytkownik może samodzielnie znaleźć informację, wypełnić formularz, dodać produkt do koszyka i zakończyć płatność? Nie jest nim samo uruchomienie skanera. Narzędzie automatyczne wykryje część błędów technicznych, ale nie sprawdzi rzetelnie między innymi kolejności fokusu, sensu komunikatu, działania okna modalnego ani tego, czy użytkownik czytnika ekranu potrafi przejść przez proces zakupu.
Jeżeli prowadzisz e-commerce, usługę cyfrową albo rozwijasz stronę firmową, potraktuj audyt jako podstawę planu napraw. Najpierw ustal, co badacie i po co. Następnie połącz wyniki automatu, testów ręcznych oraz testów najważniejszych zadań. Dopiero wtedy można rozsądnie zdecydować, które bariery usunąć w pierwszej kolejności i gdzie funkcje wspierające dostępność mogą pomóc użytkownikowi już teraz.
Najważniejsze wnioski
- Audyt WCAG powinien oceniać zadania użytkownika, a nie wyłącznie pojedyncze widoki i fragmenty kodu.
- Automatyczne testy są potrzebne, ale nie zastępują testów klawiaturą, czytnikiem ekranu i oceny komponentów dynamicznych.
- W sklepie internetowym priorytet mają bariery blokujące wyszukiwanie, wybór wariantu, formularz, koszyk, logowanie oraz płatność.
- Raport audytowy ma prowadzić do naprawy źródłowej, czyli poprawy kodu, treści, projektu lub procesu redakcyjnego.
- WCAGbot może być szybkim pierwszym krokiem do dodania funkcji wspierających użytkownika, lecz nie jest zamiennikiem audytu ani gwarancją zgodności.
Czym jest audyt WCAG?
Audyt WCAG to udokumentowana ocena dostępności cyfrowej względem wcześniej ustalonego zakresu. Zwykle obejmuje wybrane kryteria sukcesu WCAG, wskazany poziom zgodności, reprezentatywną próbę widoków oraz określone procesy użytkownika. Jego wynikiem powinien być raport, który umożliwia zespołowi naprawę problemów i późniejszą weryfikację zmian.
Dobry audyt nie ogranicza się do komunikatu „strona jest zgodna” albo „strona nie jest zgodna”. Opisuje konkretną barierę: gdzie występuje, kogo może dotyczyć, w jakiej sytuacji blokuje zadanie, z którym kryterium jest związana oraz jak można ją usunąć.
Audyt nie jest listą błędów dla dokumentacji. Jest mapą decyzji, które przywracają użytkownikowi możliwość samodzielnego wykonania zadania.
Warto odróżnić trzy pojęcia. WCAG to wytyczne W3C dotyczące dostępności treści internetowych. EN 301 549 to europejska norma dotycząca wymagań dostępności produktów i usług ICT. Przepisy krajowe określają natomiast, kogo i w jakich warunkach obowiązują konkretne wymagania. Zakres zlecenia nie powinien automatycznie utożsamiać tych trzech warstw.
Więcej o praktycznym układaniu działań po diagnozie przeczytasz w materiale WCAG w praktyce: plan działania dla właściciela strony.
Dlaczego automatyczny skan nie wystarcza?
Automaty są bardzo przydatne do wychwytywania powtarzalnych problemów, takich jak część brakujących etykiet, deklaracja języka dokumentu, niektóre błędy nazw i ról czy niektóre konflikty kontrastu. Badanie WebAIM Million 2025 pokazuje, że wykrywalne automatycznie błędy wystąpiły na 94,8% z miliona analizowanych stron głównych. Ten wynik nie oznacza jednak, że automat ocenił pełną zgodność tych serwisów. Autorzy badania wyraźnie ograniczają zakres do problemów możliwych do wiarygodnego wykrycia narzędziowo.
To ważne zwłaszcza w e-commerce. Skan może wskazać brak etykiety pola, ale nie odpowie, czy po błędnym wpisaniu kodu pocztowego komunikat jest zrozumiały, ogłoszony przez czytnik ekranu i nie znika zbyt szybko. Nie oceni też, czy otwarte menu, filtr produktów albo okno płatności poprawnie przejmuje fokus i pozwala wrócić do miejsca, z którego użytkownik rozpoczął działanie.
WCAGbot Accessibility Path: od diagnozy do kontroli
W badaniu WebAIM sześć podstawowych kategorii odpowiadało za 96% wykrytych błędów. Wśród nich znalazły się niski kontrast, brak tekstów alternatywnych, brak etykiet formularzy, puste linki i przyciski oraz brak języka dokumentu. To dobry argument, aby audyt zaczynać od fundamentów, a nie od przypadkowego dodawania atrybutów ARIA.
Praktyczne instrukcje dla tych obszarów znajdziesz w artykułach: Kontrast strony: jak testować i poprawiać, Tekst alternatywny ALT: jak opisywać obrazy oraz ARIA w praktyce: kiedy wspiera dostępność strony.
Co powinien obejmować audyt WCAG strony lub sklepu?
Zakres zależy od celu, technologii i ryzyka biznesowego. Nie ma jednego zestawu podstron, który rzetelnie opisze każdy serwis. Są jednak elementy, których nie warto pomijać, gdy użytkownik wykonuje na stronie ważne działania.
| Obszar audytu | Co należy sprawdzić | Przykładowe ryzyko dla użytkownika |
|---|---|---|
| Struktura treści | Język strony, tytuły, nagłówki, regiony, link „przejdź do treści” | Trudność w szybkim znalezieniu potrzebnej informacji |
| Nawigacja klawiaturą | Kolejność fokusu, widoczny fokus, brak pułapek, obsługa menu i dialogów | Brak możliwości przejścia do kolejnego kroku bez myszy |
| Formularze | Etykiety, instrukcje, wymagane pola, walidacja, komunikaty błędów | Niemożność wysłania zapytania, założenia konta lub zakupu |
| Komponenty dynamiczne | Karty, akordeony, filtry, autouzupełnianie, powiadomienia, modale | Nieczytelna zmiana stanu lub utrata miejsca na stronie |
| Treści i media | Teksty alternatywne, napisy, nazwy przycisków, instrukcje obrazowe | Utrata informacji albo niezrozumiała funkcja elementu |
| Ścieżka zakupowa | Produkt, wariant, koszyk, dostawa, płatność, potwierdzenie | Przerwanie procesu tuż przed finalizacją transakcji |
W przypadku sklepu szczególnie przydatny jest osobny scenariusz testowy dla zakupu. Rozwinięcie tego podejścia opisuje tekst WCAG dla e-commerce: jak ułatwić zakupy online.
Jak wygląda WCAGbot Accessibility Path?
WCAGbot Accessibility Path porządkuje działania po audycie tak, aby nie mylić doraźnego wsparcia użytkownika z trwałą poprawą produktu.
- Ustal cel. Nazwij, czy chodzi o przygotowanie do przebudowy, kontrolę przed publikacją, ocenę sklepu, wewnętrzny standard jakości czy analizę wymagań kontraktowych.
- Wybierz próbę. Uwzględnij wszystkie ważne szablony oraz stany: pusty koszyk, błąd walidacji, ładowanie wyników, brak wyników wyszukiwania i sukces po wysłaniu formularza.
- Połącz metody. Wykonaj skan automatyczny, testy klawiaturą, ocenę semantyki i testy czytnikiem ekranu. W razie możliwości włącz testy z użytkownikami.
- Ustal priorytety. Najpierw usuń bariery blokujące zadanie, następnie problemy powtarzalne w szablonach, a później ulepszenia zwiększające komfort.
- Napraw źródło problemu. Zmień komponent, kod, treść, projekt lub proces publikacji. Nie maskuj bariery wyłącznie ustawieniem po stronie użytkownika.
- Wykonaj retest. Zweryfikuj, czy poprawka działa na docelowych urządzeniach i nie pogorszyła innej części procesu.
Jak testować klawiaturą i czytnikiem ekranu?
Test klawiaturą warto zacząć bez specjalistycznych narzędzi. Odśwież stronę, używaj klawisza Tab, Shift+Tab, Enter, Spacji oraz strzałek tam, gdzie komponent ich wymaga. Obserwuj, czy fokus jest zawsze widoczny, czy porusza się w logicznej kolejności i czy można zamknąć okno dialogowe bez użycia myszy.
Automatyczny skan a audyt WCAG
Następnie sprawdź kluczową ścieżkę z czytnikiem ekranu. Nie wystarczy odczytać strony od góry do dołu. Należy przejść po nagłówkach, znaleźć formularz, sprawdzić etykiety pól, potwierdzić komunikaty błędów i zweryfikować, czy zmiana stanu interfejsu została przekazana technologii asystującej. Badanie użytkowników czytników ekranu WebAIM wskazuje między innymi na problemy z CAPTCHA, menu, kartami, dialogami, niejasnymi nazwami elementów i obsługą klawiatury.
Przygotuj zespół do podstawowego testu według poradnika Nawigacja klawiaturą: jak testować stronę zgodnie z WCAG. Dla formularzy zastosuj osobną checklistę z artykułu Dostępny formularz: jak projektować i testować.
Mini-scenariusz: audyt koszyka w sklepie internetowym
Scenariusz ilustracyjny — nie jest wynikiem wdrożenia u klienta. Sklep ma poprawny wynik części automatycznych kontroli na stronie głównej. Zespół zakłada więc, że koszyk również jest dostępny. Podczas testu ręcznego okazuje się jednak, że po otwarciu koszyka bocznego fokus pozostaje na przycisku w tle. Użytkownik klawiatury przechodzi dalej po elementach niewidocznej strony, zamiast po koszyku. Dodatkowo przycisk usunięcia produktu jest ogłaszany jedynie jako „ikona”.
Naprawa wymaga zmiany komponentu koszyka: przeniesienia fokusu do otwartego panelu, utrzymania go w dialogu do chwili zamknięcia, przywrócenia fokusu do elementu wywołującego oraz nadania przyciskowi zrozumiałej nazwy, na przykład „Usuń produkt: [nazwa produktu]”. Tego typu problem może nie zostać właściwie oceniony przez prosty skan, a jednocześnie blokuje samodzielne zakupy.
Jak wybrać wykonawcę audytu WCAG?
Przed wyborem wykonawcy poproś o opis metody, nie tylko cenę i deklarację sprawdzenia „całej strony”. Warto zadać konkretne pytania:
- Jaka wersja WCAG i jaki poziom zgodności będą oceniane?
- Jak zostanie dobrana próba podstron, komponentów i procesów?
- Czy audyt obejmie wersję mobilną oraz elementy działające po JavaScript?
- Czy będą wykonane testy klawiaturą i czytnikiem ekranu?
- Jak raport opisze wpływ bariery na użytkownika i rekomendację naprawy?
- Czy wykonawca przewiduje retest po wdrożeniu poprawek?
- Jakie elementy będą wyłączone z zakresu, na przykład zewnętrzna bramka płatności albo dokumenty PDF?
Właściciele stron WordPress i Shopify powinni dodatkowo sprawdzić, które bariery pochodzą z motywu, edytora, aplikacji, wtyczki albo własnych modyfikacji. Pomocne będą materiały: Dostępność WordPress: plan testów i poprawek oraz Dostępność Shopify: jak testować sklep i wybierać motyw.
Gdzie w tym procesie jest widget dostępności?
Widget dostępności może wspierać użytkownika od razu po wdrożeniu. WCAGbot pozwala dodać jedną linią kodu funkcje takie jak tryby kontrastu, ustawienia typografii, czytanie treści, większy kursor, podświetlanie elementów, zatrzymywanie animacji czy profile wspierające różne potrzeby. To rozsądny pierwszy krok, gdy firma chce poprawić komfort korzystania ze strony bez przebudowy serwisu.
Granica jest istotna: widget nie naprawi źródłowo błędnej kolejności fokusu, nie nada pełnego sensu złożonemu procesowi płatności i nie zastąpi redakcyjnej decyzji, czy tekst alternatywny rzeczywiście opisuje ważną grafikę. Automatyczne uzupełnianie wykrywalnych atrybutów może pomóc w części przypadków, ale wymaga kontroli w kontekście strony.
Przykładowa mapa testu koszyka
Więcej o tej granicy wyjaśnia artykuł Widget dostępności WCAGbot: możliwości i ograniczenia. Możesz też otworzyć panel WCAGbot na własnej stronie, przetestować kontrast lub zwiększyć tekst i sprawdzić, które funkcje będą pomocne dla Twoich użytkowników.
Podsumowanie dla zarządzającego i sprzedaży
Audyt WCAG ma wartość wtedy, gdy prowadzi do decyzji: co naprawić, kto odpowiada za zmianę, kiedy wykonać retest i jak zapobiec powrotowi błędu. Dla zarządzającego jest to narzędzie porządkowania ryzyka oraz jakości usługi cyfrowej. Dla sprzedaży i obsługi klienta jest sposobem na zmniejszenie liczby sytuacji, w których użytkownik musi prosić o pomoc, aby wykonać podstawowe działanie.
Nie zaczynaj od deklaracji pełnej zgodności ani od przypadkowej listy narzędzi. Zacznij od zakresu, realnych ścieżek użytkownika i napraw źródłowych. Następnie wykorzystaj funkcje wspierające dostępność jako uzupełnienie tych działań.
Dodaj funkcje dostępności swojej strony i przetestuj WCAGbot na własnym przykładzie. Dodaj funkcje dostępności.
FAQ: audyt WCAG
Czy automatyczny tester wystarczy do audytu WCAG?
Nie. Tester automatyczny pomaga wykryć część błędów technicznych, ale nie zastępuje testów klawiaturą, oceny dynamicznych komponentów, czytnika ekranu ani kontroli całej ścieżki użytkownika.
Ile podstron powinien obejmować audyt WCAG?
Nie ma jednej właściwej liczby. Próba powinna obejmować wszystkie istotne typy szablonów, komponenty oraz procesy, które użytkownik wykonuje na stronie. W sklepie zwykle obejmuje to katalog, kartę produktu, koszyk, logowanie, formularze i płatność.
Czy audyt WCAG obejmuje formularze?
Powinien obejmować formularze, które są dostępne w badanym zakresie. Sprawdza się między innymi etykiety, instrukcje, pola wymagane, kolejność fokusu, walidację i komunikaty błędów.
Czy trzeba testować stronę na telefonie?
Jeżeli strona lub usługa działa na urządzeniach mobilnych, test mobilny powinien być częścią zakresu. Warto sprawdzić obsługę dotykową, zmianę orientacji, skalowanie oraz działanie z technologiami asystującymi właściwymi dla urządzeń mobilnych.
Czym różni się audyt WCAG 2.2 od audytu WCAG 2.1?
WCAG 2.2 zachowuje większość struktury WCAG 2.1 i dodaje kryteria dotyczące między innymi fokusu, przeciągania, rozmiaru celów, uwierzytelniania i powtarzalnego wprowadzania danych. Zakres należy jasno opisać przed audytem.
Czy audyt WCAG oznacza zgodność z EN 301 549?
Nie zawsze. WCAG i EN 301 549 mają różne zakresy. Raport powinien wyraźnie wskazywać, według jakiego standardu przeprowadzono ocenę oraz jakich produktów, platform i funkcji dotyczy.
Czy widget dostępności zastępuje audyt WCAG?
Nie. Widget może wspierać użytkowników przez funkcje kontrastu, czytelności, powiększania tekstu czy czytania treści, ale nie zastępuje oceny dostępności ani trwałej naprawy barier w kodzie, treści i projekcie.
Co powinien zawierać raport z audytu WCAG?
Raport powinien zawierać zakres badania, metodę, opis bariery, lokalizację problemu, odniesienie do kryterium, wpływ na użytkownika, priorytet oraz rekomendację naprawy. Przydatne są też przykłady, zrzuty ekranu i kryteria retestu.
Czy po poprawkach trzeba wykonać retest?
Tak. Retest potwierdza, czy dana bariera została rzeczywiście usunięta i czy zmiana nie spowodowała problemu w innym miejscu. Powinien obejmować zarówno poprawiony komponent, jak i kluczowy proces, w którym komponent działa.
Czy audyt WCAG jest poradą prawną?
Nie. Audyt techniczny i ekspercki opisuje dostępność badanego zakresu względem ustalonych kryteriów. Ocena indywidualnych obowiązków prawnych firmy wymaga analizy jej sytuacji, usługi, rynku i właściwych przepisów.
