Audyt dostępności strony: jak wygląda, ile kosztuje

Zanim zapytacie, ile kosztuje audyt dostępności, warto zapytać, ile kosztuje jego brak. Najnowszy raport WebAIM Million, coroczna analiza miliona najpopularniejszych stron głównych na świecie, pokazuje, że 95,9% z nich ma wykrywalne błędy WCAG. To nie jest problem małych firm bez budżetu na jakość. To dziś norma, nawet wśród największych serwisów na świecie, prowadzonych przez zespoły, które formalnie mają proces jakości. Ten artykuł pokazuje, jak wygląda profesjonalny audyt dostępności krok po kroku, kto w organizacji powinien go zamówić jako pierwszy, co dostajecie w raporcie i ile to realnie kosztuje.

Ile błędów dostępności ma przeciętna strona, zanim zrobicie audyt

Warto zacząć od skali problemu, bo ona tłumaczy, dlaczego audyt rzadko kończy się pustą listą. Przeciętna strona główna w badaniu WebAIM Million miała 56,1 błędu dostępności, o 10% więcej niż rok wcześniej. To nie jest lista drobiazgów. Sześć kategorii błędów odpowiada za 96% wszystkich wykrytych problemów, więc naprawa nawet tylko tych sześciu obszarów realnie zmienia sytuację.

Żadna z tych sześciu kategorii nie wymaga przebudowy strony. Kontrast to zmiana koloru, tekst alternatywny to opisanie obrazów, etykiety formularzy to poprawienie kodu pola. Problem nie leży w trudności naprawy, tylko w tym, że nikt tych błędów nie widzi, dopóki ich celowo nie poszuka, a to jest właśnie zadanie audytu.

Warto rozłożyć trzy najczęstsze błędy, bo każdy ma inny mechanizm powstawania. Zbyt niski kontrast najczęściej wynika nie z celowej decyzji projektowej, tylko z tego, że designer testuje kolory na dużym, dobrze skalibrowanym monitorze, a użytkownik czyta tekst na telefonie w słońcu albo na starszym ekranie o słabszej reprodukcji barw. Brak tekstu alternatywnego rzadko jest zaniedbaniem, częściej efektem tempa: CMS albo system e-commerce dodaje zdjęcie produktu automatycznie, a pole alt zostaje puste, bo nikt go nie wypełnił przy imporcie danych. Brak etykiet formularza to zwykle pozostałość po komponencie, który wizualnie ma opis nad polem, ale technicznie nie jest z nim powiązany atrybutem for albo aria-label, więc dla czytnika ekranu pole zostaje bezimienne.

Audyt dostępności a testy dostępności: różnica, którą warto znać

Te dwa terminy używane są zamiennie, ale w praktyce oznaczają nieco inny zakres pracy. Audyt dostępności to jednorazowa, szeroka ocena produktu, zakończona raportem z priorytetami i rekomendacjami. Testy dostępności mogą być częścią audytu, ale mogą też być stałym elementem procesu QA: przy nowej funkcji, przy regresji, przy odbiorze wdrożenia. Audyt odpowiada na pytanie „gdzie dziś stoimy”, testy dostępności wpisane w proces odpowiadają na pytanie „czy nadal tam stoimy po ostatniej zmianie”.

W praktyce większość firm zaczyna od audytu, nie od procesu, i to jest właściwa kolejność. Trudno zaprojektować stały proces testowania dostępności, zanim ktoś pokaże, gdzie realnie są dziś dziury. Audyt daje mapę problemów i priorytetów. Dopiero na tej podstawie ma sens decyzja, czy dostępność wchodzi do kryteriów akceptacji, do regresji, czy do checklisty code review. Odwrócenie kolejności, czyli budowanie procesu bez wcześniejszej diagnozy, zwykle kończy się tym, że zespół pilnuje rzeczy, które nie były największym problemem, a te realne zostają nietknięte.

Jest jeszcze trzeci scenariusz, rzadszy, ale wart nazwania: firma, która chce jedynie potwierdzenia zgodności do dokumentacji przetargowej albo raportu dla zarządu, bez planu wdrażania poprawek. To wciąż legalny powód zamówienia audytu, ale wtedy warto powiedzieć to wprost audytorowi na starcie, bo zmienia to formę raportu: więcej nacisku na jednoznaczną ocenę zgodności, mniej na szczegółowe instrukcje wdrożeniowe dla programistów. Dobry dostawca dopyta o ten cel, zamiast zakładać go za Was.

Jak wygląda audyt krok po kroku

Źródło: metodyka audytów dostępności Quality Island.

Kroki drugi i trzeci warto rozłożyć osobno, bo to one najczęściej są mylone jako to samo zadanie. Skan automatyczny trwa minuty i obejmuje całą domenę naraz, ale wykrywa wyłącznie błędy, które da się rozpoznać programowo: brak atrybutu, zbyt niski kontrast liczony matematycznie, pusty link. Nie wykryje, czy tekst alternatywny opisuje faktyczną treść zdjęcia, czy jest przypadkowym ciągiem znaków wygenerowanym przez CMS. Nie wykryje, czy komunikat błędu naprawdę pomaga użytkownikowi poprawić dane, czy tylko formalnie istnieje. Właśnie dlatego krok trzeci, testy manualne, jest tam, gdzie audytor faktycznie siada przy klawiaturze i czytniku ekranu, i przechodzi realny proces tak, jak zrobiłby to użytkownik zależny od tych narzędzi.

Krok czwarty, raport, jest momentem, w którym najczęściej rozstrzyga się, czy cały audyt był wart swojej ceny. Ten sam zestaw znalezisk, spisany jako sucha lista technicznych naruszeń, i ten sam zestaw, opisany z priorytetem biznesowym i konkretną rekomendacją, prowadzą do zupełnie różnych decyzji zarządu o tym, ile czasu deweloperskiego przeznaczyć na poprawki. Dlatego traktujemy raport nie jako formalność kończącą projekt, tylko jako właściwy produkt całej usługi.

Czas trwania audytu zależy od zakresu, nie od samej strony. Prosta strona firmowa bez procesów transakcyjnych sprawdza się szybciej niż sklep internetowy z checkoutem, kontem klienta i formularzem reklamacji, bo to właśnie te procesy, nie liczba podstron, decydują o czasie testów manualnych. Dlatego pierwszym pytaniem w wycenie zawsze jest zakres, nie sama domena.

Co zawiera dobry raport z audytu

Raport, który jest tylko listą naruszeń, nie pomaga zespołowi nic naprawić. Dobry raport opisuje każdy problem tak, żeby developer, designer i product owner rozumieli go bez dodatkowych pytań. Przykład: „użytkownik nie może zamknąć modala klawiaturą, ponieważ fokus zostaje uwięziony na przycisku potwierdzenia, a klawisz Escape nie zamyka okna. Wpływ: osoba korzystająca bez myszy nie może wrócić do procesu zakupowego. Rekomendacja: poprawne zarządzanie fokusem i obsługa zamknięcia klawiszem Escape.”

Taki opis ma cztery elementy, które powinny znaleźć się przy każdym zgłoszonym problemie: lokalizację i sposób odtworzenia, konkretne kryterium WCAG, którego dotyczy, wpływ na użytkownika i biznes, oraz rekomendację naprawy. Bez tych czterech elementów raport zostaje dokumentem do przeczytania, nie planem działania.

Priorytety w raporcie nie powinny być jednym workiem „do zrobienia”. Błąd, który blokuje cały proces zakupowy dla części użytkowników, to co innego niż błąd, który utrudnia, ale nie uniemożliwia zadania. Dobry audyt dzieli znalezione problemy na poziomy priorytetu, żeby zespół wiedział, co naprawić przed kolejnym wydaniem, a co może poczekać do następnego sprintu porządkowego.

Warto zestawić tę tabelę z listą dziewięciu nowych kryteriów WCAG 2.2, którą opisaliśmy szczegółowo w osobnym artykule. W naszych audytach problemy na styku logowania i formularzy najczęściej lądują w kategorii krytycznej albo wysokiej, bo tam błąd nie jest niedogodnością, tylko realną blokadą całego procesu. Problemy kosmetyczne, takie jak drobne niedociągnięcia kontrastu na elementach pomocniczych, zwykle trafiają do kategorii średniej lub niskiej, bo utrudniają, ale nie uniemożliwiają wykonania zadania.

Kto w organizacji powinien zamówić audyt jako pierwszy

Audyt dostępności rzadko zaczyna się od jednej osoby z jasnym mandatem. Najczęściej inicjuje go dział, który pierwszy poczuje presję: prawną, sprzedażową albo wizerunkową. W firmach objętych przetargami publicznymi to zwykle dział sprzedaży albo prawny, bo dostępność zaczyna pojawiać się w specyfikacjach zamówień. W e-commerce to częściej product owner albo Head of QA, którzy widzą porzucone koszyki i szukają przyczyny. W większych organizacjach, opisanych szerzej w naszym artykule o wymaganiach WCAG 2.2, decyzję najczęściej podejmuje CTO, bo to on odpowiada za ryzyko kary i wykluczenia z zamówień.

Branża zmienia to, co jest stawką najwyższą. W bankowości i sektorze regulowanym audyt dostępności rzadko jest osobną inicjatywą, częściej wchodzi w skład szerszego audytu zgodności, obok bezpieczeństwa i ochrony danych. W e-commerce stawką jest wprost konwersja, więc audyt zamawia się razem z testami użyteczności, nie osobno. W sektorze publicznym i u dostawców startujących w przetargach stawką jest formalna kwalifikacja do udziału w postępowaniu, więc audyt musi zakończyć się dokumentem, który da się dołączyć do oferty. Te trzy scenariusze wymagają tego samego procesu technicznego, ale różnego sposobu prezentacji wyniku.

Niezależnie od tego, kto inicjuje, warto zacząć od tych samych miejsc: strony logowania, procesu płatności i głównego formularza kontaktowego lub rejestracyjnego. To trzy procesy, w których błąd dostępności najszybciej przekłada się na utraconą sprzedaż albo utracony kontrakt, więc to one, nie cała witryna naraz, powinny wejść do pierwszego, ograniczonego zakresu audytu.

Audyt jednorazowy czy cykliczny

Pierwszy audyt niemal zawsze jest jednorazowy, bo trzeba najpierw poznać punkt startowy. Problem pojawia się rok później, kiedy produkt przeszedł kilka wydań, dostał nowe komponenty i formularze, a nikt nie sprawdził, czy dostępność przetrwała te zmiany. Strona, która przeszła audyt i naprawiła wszystkie błędy w marcu, może w grudniu mieć zupełnie nowe problemy, wprowadzone razem z nowym komponentem karuzeli albo przeprojektowanym checkoutem, o których nikt formalnie nie wiedział, bo nikt tego nie sprawdzał.

Dlatego firmy, które traktują dostępność poważnie, po pierwszym pełnym audycie przechodzą na model lżejszy: walidacja po każdej istotnej zmianie interfejsu, zamiast czekania na kolejny duży audyt za rok albo dwa. To jest dokładnie ta sama logika, którą opisaliśmy w artykule o WCAG 2.2 przy okazji standardu projektowego: jednorazowy audyt daje zdjęcie stanu w jednym momencie, proces daje pewność, że to zdjęcie się nie starzeje.

Ile kosztuje audyt dostępności

Audyt strony do 10 podstron, od 2 700 zł, to najniższy próg wejścia wśród wszystkich usług QA w naszej ofercie, bo to jedyna usługa, za którą stoi konkretny, już obowiązujący termin prawny, opisany szerzej w naszym artykule o wymaganiach WCAG 2.2. Po audycie certyfikat zgodności jest wliczony w cenę, nie jest osobną pozycją do dokupienia.

Cena wyjściowa rośnie w trzech sytuacjach. Więcej niż dziesięć podstron w zakresie, obecność procesów transakcyjnych wymagających dłuższych testów manualnych, oraz potrzeba testów z realnymi użytkownikami czytników ekranu, nie tylko z automatem. Warsztat developerski i szkolenie zespołu to pozycje opcjonalne, dobierane wtedy, gdy raport ma nie tylko wskazać problemy, ale też nauczyć zespół, żeby te same błędy nie wracały przy następnym komponencie.

Trzy pozycje w cenniku, strona, aplikacja mobilna i dokumenty PDF, to nie warianty tej samej usługi z inną nazwą, tylko różne warsztaty testowe. Audyt strony sprawdza kod HTML, CSS i JavaScript pod kątem semantyki i interakcji. Audyt aplikacji mobilnej sprawdza natywne mechanizmy dostępności systemu (VoiceOver na iOS, TalkBack na Androidzie), które działają inaczej niż czytniki ekranu w przeglądarce. Audyt PDF sprawdza strukturę tagów dokumentu, kolejność odczytu i to, czy tekst jest realnym tekstem, a nie zeskanowanym obrazem. Firma, która ma stronę, aplikację i regulaminy do pobrania jako PDF, potrzebuje w praktyce trzech różnych kompetencji audytorskich, nie jednej.

Nasza perspektywa: dlaczego cena audytu to nie jest właściwe pytanie

Najczęściej zadawane pytania o audyt dostępności

Czym różni się audyt dostępności od testów dostępności?

Audyt to jednorazowa, szeroka ocena produktu zakończona raportem z priorytetami. Testy dostępności mogą być częścią audytu albo stałym elementem procesu QA, wykonywanym przy każdej istotnej zmianie interfejsu.

Ile trwa audyt dostępności strony?

Czas zależy od zakresu, nie od liczby podstron. Strona firmowa bez procesów transakcyjnych sprawdza się szybciej niż sklep z checkoutem, kontem klienta i formularzami, bo to właśnie te procesy wymagają dokładnych testów manualnych.

Co dostajemy w raporcie z audytu?

Raport z lokalizacją każdego problemu, wskazaniem konkretnego kryterium WCAG, opisem wpływu na użytkownika i biznes, oraz rekomendacją naprawy. Dobry raport jest planem działania dla zespołu, nie tylko listą naruszeń.

Czy audyt gwarantuje zgodność z WCAG?

Audyt pokazuje, gdzie dziś stoicie i co trzeba zmienić. Sama zgodność zależy od tego, czy rekomendacje zostaną wdrożone, dlatego warto od razu zaplanować walidację po poprawkach, nie kończyć procesu na samym raporcie.

Czy audyt obejmuje też aplikację mobilną i dokumenty PDF?

Tak, to osobne pozycje w cenniku: audyt aplikacji mobilnej od 3 300 zł, audyt dokumentów PDF do 10 plików od 2 000 zł. Zakres ustalacie razem z audytorem przed startem prac.

Czy audyt warto zamówić przed redesignem, czy dopiero po nim?

Najlepiej przed, na etapie makiet i projektu, bo wtedy poprawki kosztują najmniej i nie wymagają cofania gotowego kodu. Jeśli redesign już trwa albo się skończył, audyt i tak warto zrobić od razu po wdrożeniu, zanim błędy zdążą się powielić w kolejnych komponentach budowanych na tej samej podstawie.

Ile kosztuje audyt dostępności strony?

Audyt strony internetowej do 10 podstron zaczyna się od 2 700 zł. Pełny cennik, w tym testy manualne, walidacja po poprawkach i szkolenie zespołu, jest w sekcji cen wyżej. Cena rośnie wraz z liczbą podstron i liczbą procesów transakcyjnych wymagających dokładnych testów manualnych.

Powiązane na blogu Quality Island

• WCAG 2.2: wymagania, zmiany i kogo obowiązują
• Testowanie dostępności, jak, kiedy, narzędzia i tipy
• 7 obszarów dostępności, które musisz przetestować

Pełna lista źródeł

• WebAIM, The WebAIM Million 2026
• W3C, Web Content Accessibility Guidelines (WCAG) 2.2
• Biznes.gov.pl, Kto ma obowiązek zapewniać dostępność produktów i usług