Audyt WCAG: cena, zakres i zlecenie rzetelnego badania

Audyt WCAG wycenia się według wielkości i złożoności strony lub aplikacji, badanych widoków, pełnych ścieżek oraz wymagań dotyczących testów. Dla wybranych, ograniczonych pakietów orientacyjny budżet wynosi od 3 750 do 15 000 zł netto z przyjętym buforem planistycznym 50%, a większy zakres wymaga indywidualnej wyceny.

WCAG, czyli Web Content Accessibility Guidelines, to wytyczne dostępności treści internetowych, wobec których ocenia się dostępność badanego produktu.

Dokładną kwotę można ustalić po określeniu produktu i wymagań. Pełne badanie potrzebuje też pracy eksperta: sam automatyczny skan pozostawia obszary wymagające ręcznej oceny. Przy zamawianiu usługi sprawdź więc badane procesy, sposób dokumentowania barier oraz warunki ponownego sprawdzenia poprawek.

Ile kosztuje audyt WCAG i skąd tak szerokie widełki?

Cena audytu WCAG bez uzgodnionego zakresu może być wyłącznie orientacją do planowania. Różne typy widoków, role użytkowników i platformy oznaczają różny zakres pracy, nawet gdy produkty mają podobną liczbę ekranów.

Tabela pokazuje szerokie budżety dla wybranych publicznych pakietów oraz granice takiego szacunku, według cenników sprawdzonych 12 października 2026 roku.

Podstawą są publiczne pakiety badania stron za 2 500 i 5 000 zł netto oraz publiczne pakiety badania aplikacji mobilnych od 3 000 do 10 000 zł netto. Przyjęty bufor planistyczny 50% oznacza pomnożenie tych cen przez 1,5: przykładowo 2 500 × 1,5 = 3 750 zł netto. Bufor jest założeniem planowania w tych widełkach; cenniki podają kwoty bazowe.

To obserwacje wybranych ofert o ograniczonym zakresie. Nie stanowią reprezentatywnego badania rynku ani cennika Crafton. Górna kwota tabeli również nie wyznacza maksymalnego kosztu rozbudowanego produktu.

Szczerze: porównywałbym oferty dopiero po sprawdzeniu, czy obejmują te same procesy i metody. Uzgodnij osobno wdrożenie napraw, ocenę dokumentów, dodatkowe role oraz retest, czyli ponowne badanie po poprawkach. Każdy z tych elementów może być częścią pakietu lub osobnego zlecenia. Rezerwa budżetowa sama w sobie nie określa, które prace wykonawca uwzględnił w cenie.

Przy porównywaniu kwot poproś też o opis raportu i omówienia wyników. Ustal, czy otrzymasz zalecenia oraz priorytety napraw, jakie środowiska obejmuje cena i które elementy produktu pozostają poza oceną. Te zapisy pozwolą porównać zawartość ofert.

Co obejmuje audyt WCAG strony, sklepu i aplikacji?

Zakres audytu WCAG obejmuje reprezentatywne widoki, ich stany i kompletne procesy. W aplikacji trzeba również uzgodnić platformy i elementy interfejsu.

Punkt wyjścia stanowi mapa produktu: szablony, formularze, funkcje po zalogowaniu i ścieżki prowadzące do wykonania zadania. Tabela zawiera przykłady elementów do uzgodnienia przy zamawianiu badania.

Liczba adresów URL nie określa samodzielnie zakresu ani zgodności. Tysiące podstron korzystających z tych samych szablonów mogą wymagać innego badania niż kilkanaście odmiennych procesów. W przykładowym sklepie koszyk, błędna płatność i potwierdzenie zakupu tworzą odrębne stany, które trzeba uwzględnić w scenariuszu.

Dobór próbki porządkuje metodyka WCAG-EM opracowana przez W3C, organizację publikującą WCAG. Jej wersja WCAG-EM 2.0 obejmuje także aplikacje. Najpierw ustala się zakres i poznaje produkt, następnie wybiera reprezentatywną próbkę, ocenia ją i dokumentuje wyniki. To sposób organizacji oceny; zastosowanie metodyki trzeba odróżnić od spełnienia samych kryteriów dostępności.

Poproś o uzasadnienie wyboru ekranów oraz listę kompletnych procesów. Sama deklaracja liczby badanych podstron pozostawia pytanie, czy audyt dostępności obejmie funkcje ważne dla Twoich użytkowników.

W przykładowej aplikacji rejestracja może przechodzić przez formularz, komunikat błędu i potwierdzenie utworzenia konta. Opisz zadanie od początku do końca, także po stronie osoby zalogowanej. Przy elementach natywnych, czyli udostępnianych przez system mobilny, zaznacz platformę. Nie zakładaj, że ocena wersji na iOS obejmuje również Androida.

Jeśli potrzebujesz również szerszej diagnozy ścieżki sprzedaży, pomocny będzie audyt e-commerce. Bada on szerszy kontekst działania sklepu. Formalna ocena dostępności wymaga określonej podstawy oraz dowodów dotyczących badanych wymagań.

Czy automatyczny audyt WCAG wystarczy?

Sam automatyczny skan nie wystarcza do ustalenia dostępności produktu. W3C opisuje ograniczenia narzędzi do oceny dostępności: część aspektów wymaga osądu człowieka, a wyniki narzędzi mogą być mylące. Skan pomaga wykrywać potencjalne błędy i powtarzać kontrole po zmianach.

W ofercie rozróżnij metody oraz rodzaj dowodu, jaki dają:

• Skan automatyczny sygnalizuje problemy w zakresie obsługiwanym przez narzędzie; ekspert interpretuje wyniki i sprawdza trafność zgłoszeń.
• Ocena manualna obejmuje sprawdzenie kryteriów oraz działania interfejsu z uzgodnionymi technologiami asystującymi, na przykład czytnikiem ekranu.
• Badanie z użytkownikami pokazuje doświadczenie osób wykonujących zadania; uzupełnia ocenę i wymaga odrębnego uzgodnienia zakresu.

Przykład dydaktyczny: formularz ma przycisk wysyłki i miejsce na adres e-mail. Skan sygnalizuje brak etykiety pola. Podczas testu ręcznego audytor sprawdza kolejność fokusa, czyli wskazania aktualnie aktywnego elementu, oraz możliwość ukończenia formularza z czytnikiem ekranu. Przycisk wygląda poprawnie, ale użytkownik nadal może utknąć przy komunikacie błędu. Wygląd i możliwość wykonania zadania wymagają odrębnej oceny.

Poszczególne narzędzia mają różny zakres kontroli. Zielony wynik albo brak zgłoszonych błędów nie daje gwarancji zgodności. Gdy oferta opisuje „automatyczny audyt WCAG”, poproś o zakres ręcznej weryfikacji i sposób opracowania raportu. Udział użytkowników również nie zastępuje sprawdzenia wszystkich wymagań objętych oceną.

Przy odbiorze usługi zapytaj, które wnioski audytor potwierdził ręcznie i jakie ograniczenia pozostają. Taka informacja pokazuje, na czym oparto ocenę.

Jak ustalić wymagania przed wyceną badania?

Przed zamówieniem audytu dostępności cyfrowej uzgodnij wersję WCAG, poziom zgodności oraz osobno wymagania prawne lub umowne. Audyt WCAG 2.1 i badanie według WCAG 2.2 trzeba precyzyjnie opisać, wskazując poziom A, AA lub AAA. Ocena wybranych kryteriów ma zakres ograniczony. W3C rekomenduje wytyczne WCAG 2.2, ale rekomendacja techniczna sama nie zmienia polskich obowiązków prawnych. Jeśli wymagane jest EN 301 549, poproś o wskazanie wydania tej normy i zakresu badania.

Odrębne podstawy dotyczą stron i aplikacji podmiotów publicznych oraz produktów i usług objętych europejskim aktem o dostępności, określanym jako EAA. Polska ustawa o wymaganiach dostępności produktów i usług z 26 kwietnia 2024 roku obejmuje wskazane produkty i usługi, w tym konsumencki handel elektroniczny, i wyłącza usługi świadczone przez mikroprzedsiębiorców. Zakres obowiązków ustal dla konkretnego produktu i podmiotu. WCAG, EN 301 549 i ustawy są odrębnymi podstawami oceny. Do porównania ofert potrzebujesz zapisanej wersji, poziomu i zakresu; szczegółową analizę prawną uzgodnij osobno.

Po czym poznasz raport gotowy do wdrożenia?

Raport z audytu WCAG powinien łączyć barierę z jej miejscem, dowodem, skutkiem dla użytkownika i zaleceniem naprawy. Taki zapis pomaga zespołowi odtworzyć problem, przypisać pracę i sprawdzić rezultat poprawki.

Przebieg badania oraz dalszych prac uzgodnij w kolejności:

1. Zakres i dostęp. Opisz produkt, wymagania i role, przygotuj konta oraz środowisko testowe pozwalające wykonać uzgodnione zadania.
2. Próbka i scenariusze. Wybierz z wykonawcą reprezentatywne widoki, stany i kompletne procesy; zapisz granice oceny.
3. Skan i testy ręczne. Ustal metody oraz środowiska, w których zostaną sprawdzone kryteria dostępności.
4. Raport i omówienie. Odbierz dowody, zalecenia i priorytety oraz wyjaśnij z audytorem wątpliwości zespołu wdrażającego.
5. Naprawy i retest. Przypisz odpowiedzialny zespół, wdrożenie i ponowną weryfikację; te prace mogą stanowić osobne zlecenia.

Ministerstwo Cyfryzacji publikuje zalecenia dotyczące raportu z audytu eksperckiego. Na ich podstawie sprawdź przy odbiorze:

• zakres, próbkę, badane procesy i datę oceny;
• użyte metody, urządzenia, przeglądarki oraz technologie asystujące;
• lokalizację barier, odniesienia do kryteriów i wpływ na użytkowników;
• priorytety oraz rekomendacje umożliwiające zaplanowanie napraw;
• ograniczenia badania i warunki ponownego sprawdzenia.

Przykładowy rekord dotyczy formularza kontaktowego, w którym komunikat walidacji nie jest czytelny dla użytkownika. Powinien pokazać ekran i kroki odtworzenia, opisać barierę oraz zalecenie, wskazać kryterium dobrane przez audytora i status po reteście. Sam zrzut ekranu pozostawia zespołowi za mało informacji do weryfikacji naprawy.

Przy poprawkach zachowaj odniesienie do zgłoszonej bariery i ustal, jak zespół udokumentuje jej ponowne sprawdzenie. W przykładowym formularzu powtórz scenariusz błędnie wypełnionego pola oraz sprawdzenie komunikatu z czytnikiem ekranu. Zapis wyniku retestu powinien wskazać, co ponownie oceniono i czy bariera nadal występuje.

I jeszcze jedna rzecz do ustalenia: testy z osobami z niepełnosprawnościami. Zapisz, czy obejmuje je audyt dostępności, jakich zadań mają dotyczyć i jak zostaną udokumentowane. Samo określenie „testy użytkowników” pozostawia te decyzje otwarte.

Jak zlecić audyt WCAG

Żeby zlecić audyt WCAG, zacznij od opisu produktu, wymagań i procesów ważnych dla użytkowników. Wiadomość do wyceny powinna pozwolić ustalić granice badania, w tym funkcje dostępne dopiero po zalogowaniu.

Przygotuj informacje, które da się przełożyć na zakres prac:

• adres strony albo opis aplikacji wraz z platformami, na których działa;
• liczbę typów widoków oraz ważne ścieżki, na przykład kontakt, rejestrację lub zakup;
• role użytkowników, sposób logowania i możliwość udostępnienia środowiska testowego;
• urządzenia i technologie asystujące, których uwzględnienie chcesz uzgodnić;
• wersję WCAG, poziom, wymaganą normę oraz znaną podstawę prawną lub umowną;
• dokumenty i wersje językowe, które mają zostać objęte badaniem;
• oczekiwany termin zakończenia oraz daty zmian produktu istotnych dla zakresu;
• oczekiwany raport, omówienie, retest i ewentualne wdrożenie poprawek.

Jeśli brakuje Ci pełnej listy widoków, opisz zadania użytkowników i zaznacz brakujące informacje. Dla przykładowej aplikacji wystarczy zacząć od informacji, że użytkownik zakłada konto, loguje się i wysyła formularz; szczegóły ekranów wymagają dalszego ustalenia. Taki opis daje punkt wyjścia do rozmowy o próbce i wymaganiach.

Poproś, aby oferta audytu dostępności cyfrowej określała również wyłączenia oraz sposób odbioru wyników.