Audyt dostępności nie sprawdza, czy strona jest szybka i widoczna w Google - sprawdza, czy da się z niej korzystać bez myszki i bez wzroku. To zupełnie inna perspektywa niż w klasycznym przeglądzie technicznym, choć oba dokumenty nazywają się „audytem” i oba potrafią mieć podobną liczbę stron. Stąd większość nieporozumień przy wycenach: klient prosi o jedno, dostaje drugie, a różnicę widać dopiero wtedy, gdy ktoś naprawdę spróbuje przejść formularz samą klawiaturą.
Rozkładam więc temat na części: czym ten audyt różni się od zwykłego, z jakich etapów się składa, co realnie wpływa na jego cenę i jak odróżnić robotę człowieka od wydruku ze skanera. Jeśli szukasz szerszego kontekstu prac nad istniejącym serwisem, opisuję je na stronie o rozwoju i optymalizacji.
Czym audyt dostępności różni się od zwykłego audytu strony
Zwykły audyt techniczny odpowiada na pytanie „czy ta strona działa dobrze dla wyszukiwarki i dla przeciętnego użytkownika z myszką”. Sprawdza indeksację, szybkość, strukturę treści - tak jak opisuję to w tekście o tym, ile kosztuje audyt SEO i co musi zawierać. Wynik mówi o widoczności i wydajności. Jeśli chcesz najpierw przejść stronę samodzielnie, zanim zamówisz cokolwiek płatnego, rozpisałem to w tekście o tym, jak zrobić audyt WCAG krok po kroku.
Audyt dostępności pyta o coś innego: czy da się tę stronę obsłużyć, jeśli ktoś nie używa myszki, nie widzi ekranu albo widzi go słabo. Czy da się dojść do koszyka samym klawiszem Tab. Czy przycisk, który wygląda jak przycisk, jest przyciskiem także dla oprogramowania czytającego stronę na głos. Czy komunikat „coś poszło nie tak” w formularzu w ogóle dociera do osoby, która go nie zobaczy w czerwonej ramce.
To ważne rozróżnienie, bo strona może mieć znakomite wyniki Core Web Vitals i być kompletnie nieobsługiwalna bez myszki. Szybkość i dostępność mierzą różne rzeczy i naprawia się je innymi narzędziami.
Z czego składa się rzetelny audyt dostępności
Porządny audyt ma cztery warstwy i żadna z nich nie zastępuje pozostałych.
- Część automatyczna - skanery przelatują kod i wyłapują to, co da się sprawdzić maszynowo: za słaby kontrast tekstu do tła, obrazki bez opisu alternatywnego, pola formularza bez etykiety, błędy w strukturze nagłówków. To szybki i tani etap, ale wyłapuje tylko wycinek problemów. Skaner sprawdzi, czy obrazek ma opis - nie sprawdzi, czy ten opis cokolwiek znaczy.
- Część ręczna - ktoś odkłada myszkę i przechodzi stronę samą klawiaturą. Czy da się dojść do każdego elementu. Czy widać, gdzie aktualnie jest kursor (to ten obrys wokół aktywnego elementu). Czy kolejność przeskakiwania jest logiczna, czy skacze z nagłówka do stopki i z powrotem. Czy okno pop-up da się zamknąć bez myszki, czy zamyka użytkownika w pułapce. Czy błędy w formularzu są opisane słowami, a nie samym kolorem.
- Test z czytnikiem ekranu - przejście kluczowych ścieżek z włączonym oprogramowaniem, które czyta stronę na głos. Tu wychodzą rzeczy niewidoczne w kodzie: linki czytane jako „kliknij tutaj, kliknij tutaj, kliknij tutaj”, tabele bez nagłówków, dynamiczne fragmenty strony, które zmieniają się w ciszy.
- Przegląd treści - język komunikatów, sensowne opisy linków, transkrypcje i napisy do materiałów wideo, czytelność instrukcji. To warstwa, której żadne narzędzie nie oceni za człowieka.
Proporcja jest mniej więcej taka: automat daje punkt startu, reszta to praca ręczna. Oferta zbudowana wyłącznie na pierwszym punkcie to nie audyt, tylko eksport.
Poziomy WCAG A, AA i AAA po ludzku
WCAG to międzynarodowy zestaw wytycznych opisujący, co znaczy „strona dostępna”. Formalnie przepisy nie odsyłają do niego wprost, tylko do europejskiej normy technicznej, a ta przenosi WCAG w wersji 2.1 na poziomie AA - i to jest punkt odniesienia, którym warto się posługiwać w rozmowie o ofercie. Jeśli dopiero sprawdzasz, kogo w ogóle dotyczy obowiązek dostępności, zacznij od tamtego tekstu. Same wytyczne mają trzy poziomy.
A to absolutne minimum - bez tego części osób strona jest zwyczajnie zamknięta. Obrazki mają opisy, wideo ma napisy, da się przejść stronę klawiaturą.
AA to poziom, o którym mówi się w praktyce i który przyjmuje się jako cel w normalnych projektach. Dochodzą tu wymagania mierzalne i konkretne: odpowiedni kontrast tekstu, czytelność po powiększeniu, widoczny wskaźnik focusu, spójna nawigacja, sensowna obsługa błędów w formularzach. Gdy ktoś pisze „strona zgodna z WCAG”, niemal zawsze ma na myśli AA.
AAA to poziom najwyższy i w całości rzadko osiągalny - część wymagań jest nierealna dla typowego serwisu firmowego (na przykład bardzo restrykcyjne progi kontrastu czy język tekstu na poziomie prostszym niż branża w ogóle używa). Pojedyncze kryteria AAA warto wdrażać punktowo tam, gdzie dają realną korzyść, ale cel „całe AAA” to zwykle marnowanie budżetu.
Wniosek praktyczny: rozmawiaj o AA. Wykonawca, który sprzedaje „pełne AAA”, albo nie wie, co obiecuje, albo liczy, że nikt nie sprawdzi.
Ile kosztuje audyt dostępności strony internetowej - co wpływa na cenę
Nie ma jednej stawki, bo nie ma jednej strony. Za to jest kilka czynników, które przesuwają wycenę w górę i w dół - i warto je znać, zanim poprosisz o ofertę.
- Liczba unikalnych szablonów, nie liczba podstron - to najczęstsze nieporozumienie. Sklep z tysiącem produktów ma jeden szablon karty produktu. Audytuje się szablony i typy widoków (strona główna, lista, karta, formularz, koszyk, panel klienta), nie każdy adres z osobna.
- Złożoność funkcji - statyczna wizytówka to jedna liga, koszyk z wieloetapowym checkoutem, logowaniem, kalendarzem rezerwacji czy konfiguratorem to zupełnie inna. Każdy interaktywny element trzeba przeklikać, przetabować i przesłuchać osobno.
- Stan kodu - strona zbudowana na porządnym, semantycznym kodzie wymaga mniej analizy niż warstwa wizualnych nakładek, gdzie każdy przycisk to sztucznie ostylowany kwadrat. Ten sam czynnik podbija potem koszt napraw.
- Sam raport czy raport plus wdrożenie - to dwa różne produkty. Raport kończy się dokumentem, pakiet z wdrożeniem obejmuje realne poprawki w kodzie i ponowne sprawdzenie po zmianach.
- Dokument o dostępności - podmioty publiczne publikują deklarację dostępności, a firmy prywatne opisują spełnienie wymagań w informacji o usłudze i w warunkach jej świadczenia. W obu przypadkach ktoś musi to przygotować na podstawie wyników audytu, a nie skleić z szablonu. To osobna pozycja w wycenie.
Modele rozliczenia widuje się trzy: za szablon (stawka razy liczba unikalnych widoków), za dzień pracy (przy większych serwisach) albo pakiet raport plus wdrożenie z jedną kwotą za całość. Każdy z nich jest uczciwy - byle był policzony po obejrzeniu serwisu.
Co pomaga: zanim poprosisz o wycenę, spisz listę unikalnych typów stron w swoim serwisie (główna, lista, karta, formularz kontaktowy, koszyk, panel klienta) i zaznacz te, na których dzieje się coś interaktywnego. Ta jedna kartka skraca rozmowę o wycenie z tygodnia do jednego maila i sprawia, że dostajesz kwotę za swój serwis, a nie za wyobrażenie o nim.
Jak czytać oferty i co powinno być na wyjściu
Trzy sygnały ostrzegawcze wracają regularnie. Pierwszy: raport, który jest wydrukiem ze skanera - poznasz go po tym, że wszystkie znaleziska da się odtworzyć darmowym narzędziem w pięć minut, a żadne nie opisuje realnej ścieżki użytkownika. Drugi: brak priorytetów, czyli lista dwustu uwag bez wskazania, co blokuje ludzi naprawdę, a co jest kosmetyką. Trzeci: wycena podana od ręki, bez obejrzenia serwisu - nikt nie wie, ile pracy wymaga strona, której nie widział.
Na wyjściu powinieneś dostać jedno: listę znalezisk uporządkowaną wagą, gdzie każdy punkt ma opisany problem, skutek dla konkretnego użytkownika („osoba korzystająca z klawiatury nie dojdzie do przycisku Zamawiam”), sposób naprawy i szacowany nakład pracy. Do tego kolejność prac - co robimy w pierwszej kolejności, co w drugiej, co może poczekać. Dokument, z którego nie da się ułożyć harmonogramu, nie jest planem.
Od czego zacząć, jeśli budżet jest mały
Nie trzeba zaczynać od pełnego audytu całego serwisu. Sensowna kolejność przy ograniczonym budżecie wygląda tak: najpierw jedna ścieżka, która realnie zarabia albo generuje kontakty - u sklepu droga od karty produktu do zamówienia, u firmy usługowej droga od strony głównej do wysłanego formularza. Sprawdzenie i naprawa tej jednej ścieżki daje więcej niż komplet uwag do stopki i regulaminu.
Drugi krok to dokładnie te rzeczy, które wyłapał skaner w pierwszej warstwie - tanie w naprawie, a działające na całym serwisie naraz. To zwykle godziny pracy, nie tygodnie. Dopiero potem ma sens pełny przegląd wszystkich szablonów.
Jeśli poprawki wchodzą przy okazji większych zmian, warto je wpiąć w istniejący zakres - przy przebudowie strony dostępność kosztuje ułamek tego, co dokładanie jej później do gotowego frontu. U mnie projekty fixed-bid mieszczą się zwykle w przedziale 5000-10000 zł netto, a bieżące poprawki po wdrożeniu obsługuję w ramach miesięcznej opieki (Basic 1000 zł, Pro 2000 zł, Premium 3500 zł netto). Na start nic nie musisz decydować - bezpłatna diagnoza pokaże, co realnie blokuje Twoją stronę.
Najczęstsze pytania
Ile kosztuje audyt dostępności strony internetowej? Zależy przede wszystkim od liczby unikalnych szablonów i od tego, ile na stronie jest interaktywnych funkcji - a nie od liczby podstron. Rozliczenie bywa za szablon, za dzień pracy albo pakietowe z wdrożeniem, ale każda uczciwa wycena zaczyna się od obejrzenia serwisu, nie od cennika.
Czy wystarczy darmowy skaner dostępności? Jako pierwszy sygnał tak, bo pokaże kontrast, brakujące opisy i część błędów kodu. Ale największe problemy - pułapki klawiaturowe, bezsensowna kolejność focusu, komunikaty o błędach niewidoczne dla czytnika ekranu - wychodzą dopiero w teście ręcznym.
Jaki poziom WCAG wybrać? W praktyce AA - i tak przyjmuje się go jako standard w projektach. Poziom A to minimum, poniżej którego części osób strona jest po prostu zamknięta, a pełne AAA jest dla typowego serwisu firmowego nieosiągalne i nieopłacalne.
Czy audyt dostępności naprawia stronę? Nie - audyt to diagnoza, naprawia dopiero wdrożenie. Dlatego przed zamówieniem warto zapytać wprost, kto wykona poprawki i ile będą kosztować, żeby nie zostać z listą problemów i pytaniem, co dalej.
Masz to u siebie i nie wiesz, od czego zacząć? Przyspieszam i naprawiam istniejące strony i sklepy - Core Web Vitals, awarie, rozbudowa o funkcje, których brakuje. Napisz, co się dzieje, a dostaniesz konkretną wycenę z terminem.