Dostosowanie strony do WCAG 2.1: cena i zakres prac
Ile kosztuje dostosowanie strony do WCAG 2.1, co realnie podbija wycenę i dlaczego nakładka dostępności nie zamyka tematu ani technicznie, ani prawnie.
Krótka odpowiedź: dostosowanie strony do WCAG 2.1 na poziomie AA kosztuje tyle, ile kosztuje praca nad szablonami, a nie nad podstronami. Przy prostej stronie firmowej o kilku szablonach realny zakres to zwykle kilka dni roboczych, przy sklepie z koszykiem, logowaniem i płatnością liczy się to w tygodniach. Wtyczka ani nakładka nie zamykają tematu, bo połowa kryteriów dotyczy sensu treści, a nie składni kodu, a polski przepis wymaga przeprowadzenia oceny zgodności, nie zainstalowania skryptu.
Ten tekst dotyczy tego, co dzieje się PO badaniu: zakresu prac, kolejności i pieniędzy. Jeżeli jesteś dopiero przed badaniem i nie wiesz, które kryteria Twoja strona łamie, zacznij od audytu WCAG, bo bez listy usterek każda wycena jest zgadywaniem. Jeżeli natomiast strona jest stara, wolna i zbudowana na wysłużonym szablonie, warto policzyć oba warianty, bo bywa, że budowa nowej strony zgodnej z WCAG wychodzi taniej niż łatanie starej.
Dlaczego liczba podstron nie ma wpływu na cenę
To najczęstsze nieporozumienie w rozmowie o wycenie. Klient podaje, że ma osiemset podstron, i spodziewa się rachunku proporcjonalnego do tej liczby. Tymczasem osiemset kart produktu zbudowanych z jednego szablonu poprawia się raz, w jednym pliku, i poprawka działa od razu na wszystkich ośmiuset. Kosztuje więc tyle co jedna strona.
Naprawdę liczą się trzy rzeczy. Pierwsza to liczba unikalnych szablonów: strona główna, lista kategorii, karta produktu, wpis blogowy, koszyk, formularz kontaktowy to sześć osobnych układów, każdy z własnym zestawem błędów. Druga to liczba ścieżek transakcyjnych, bo każdą trzeba przejść samą klawiaturą i odsłuchać czytnikiem ekranu, a to praca ręczna, której nie da się przyspieszyć. Trzecia to treść: opisy alternatywne zdjęć, nagłówki i komunikaty pisze człowiek znający produkt, więc ta część zwykle zostaje po stronie klienta i albo kosztuje jego czas, albo osobne zlecenie redakcyjne.
| Element | Typowy nakład | Kto to zwykle robi |
|---|---|---|
| Kontrast kolorów i stany aktywne | kilka godzin, jednorazowo w stylach | wykonawca strony |
| Obsługa klawiaturą i widoczne zaznaczenie | od kilku godzin do kilku dni, zależnie od menu i modali | wykonawca strony |
| Etykiety pól i komunikaty błędów w formularzach | pół dnia na formularz | wykonawca strony |
| Hierarchia nagłówków i struktura dokumentu | godziny w szablonach, dłużej w treściach | wykonawca plus redakcja |
| Teksty alternatywne zdjęć | kilka minut na zdjęcie, ale zdjęć bywają tysiące | zespół klienta |
| Napisy i transkrypcje nagrań | koszt rośnie z minutą materiału | zespół klienta lub podwykonawca |
| Dokumenty PDF na stronie | często najdroższa pozycja, bo każdy plik osobno | zespół klienta |
| Wtyczki i widgety zewnętrzne | nieprzewidywalne, czasem wymaga wymiany narzędzia | wykonawca, decyzja klienta |
Czy wystarczy wtyczka albo nakładka dostępności
Nie, i warto wiedzieć, dlaczego, zanim ktoś sprzeda Ci abonament za coś, co nie zamyka sprawy. Nakładki to skrypty doklejane do strony, obiecujące automatyczne doprowadzenie jej do zgodności. W styczniu 2025 r. amerykańska Federalna Komisja Handlu wystąpiła przeciwko producentowi jednego z najgłośniejszych takich narzędzi, zarzucając mu, że obietnica automatycznej zgodności z WCAG 2.1 na poziomie AA była nieprawdziwa. Zarzut był bardzo konkretny: wtyczka nie uczyniła dostępnymi menu nawigacyjnego, pól formularzy ani opisów obrazów, czyli akurat tych rzeczy, od których wszystko zależy. Sprawa skończyła się kwotą miliona dolarów, a decyzja stała się ostateczna w kwietniu 2025 r.
Do tego dochodzi argument czysto polski i czysto prawny. Art. 32 ust. 1 ustawy z 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze brzmi: "Usługodawca przeprowadza ocenę zgodności usługi z wymaganiami dostępności". Ocena zgodności jest czynnością, a nie oprogramowaniem. Zainstalowanie skryptu nie jest oceną i nie stanowi dowodu, którego art. 32 ust. 2 pkt 7 każe udzielić na żądanie Prezesa Zarządu PFRON albo organu nadzoru rynku. Widget bywa natomiast sensowny w innej roli: jako panel preferencji użytkownika, pozwalający powiększyć tekst albo wyłączyć animacje. To jest udogodnienie, nie zgodność, i tak należy je opisywać.
Wtyczka WordPressa a dostępność motywu
Skoro większość polskich stron firmowych stoi na WordPressie, warto rozdzielić trzy rzeczy, które w rozmowach ciągle się zlewają. Wtyczka do dostępności to zwykle wspomniana wyżej nakładka i dotyczy jej wszystko, co napisano akapit wyżej. Motyw to co innego: to on generuje nagłówki, kontrast, kolejność elementów i obsługę klawiaturą, więc to on decyduje o większości wyniku audytu. Trzecia rzecz to wtyczki funkcjonalne, czyli formularze, wyszukiwarki, karuzele i kreatory stron, które wstawiają własny kod, często niedostępny, i to poza kontrolą motywu.
Praktyczny wniosek jest taki, że przy WordPressie największą pojedynczą decyzją jest motyw. Jeżeli obecny generuje niepoprawną strukturę nagłówków i nie obsługuje menu z klawiatury, poprawianie go plik po pliku bywa droższe niż zmiana motywu, a przy tym każda aktualizacja potrafi cofnąć poprawki. Druga decyzja dotyczy kreatora stron: rozbudowane kreatory generują dużo zagnieżdżonego kodu i bywa, że najprostszą drogą do dostępnego formularza jest wymiana wtyczki formularza na taką, która poprawnie łączy etykietę z polem. Trzecia sprawa to zwykła inwentaryzacja. Zanim ktokolwiek wyceni prace, trzeba wiedzieć, jakie oprogramowanie firma faktycznie ma i czy nadal jest wspierane, bo wtyczka porzucona przez producenta nie dostanie już żadnej poprawki dostępności, a połowa niespodzianek w takich projektach bierze się z komponentu, o którym nikt nie pamiętał, że wciąż siedzi na stronie.
Kolejność poprawek, czyli jak nie wydać pieniędzy na nie to
Raport z audytu potrafi mieć dwieście pozycji i pierwszym odruchem jest zrobić wszystko naraz. To najdroższa możliwa kolejność. Sensowna jest inna.
Najpierw blokady, czyli usterki, przez które użytkownik nie może dokończyć tego, po co przyszedł: nie da się przejść przez koszyk klawiaturą, nie da się zamknąć okna modalnego, formularz nie mówi, które pole jest błędne. Tych zwykle jest kilkanaście i to one odpowiadają za realną szkodę, także wizerunkową, bo to o nie ludzie piszą skargi. Potem błędy powtarzalne w szablonie, bo jedna poprawka zdejmuje z listy setki wystąpień i to tutaj raport najszybciej się kurczy. Dopiero na końcu pojedyncze usterki w treści, których jest najwięcej, ale każda dotyczy jednego miejsca i żadna nie blokuje niczego.
Ta kolejność ma jeszcze jedną zaletę. Po pierwszych dwóch etapach da się już uczciwie opisać stan strony w wymaganym oświadczeniu, wskazując, co zostało zrobione i co jest zaplanowane, zamiast czekać z publikacją do dnia, w którym raport będzie pusty. Przepisy nie wymagają doskonałości od pierwszego dnia, wymagają oceny, działań naprawczych i rzetelnej informacji.
Ile to trwa i kiedy zacząć
Przy prostej stronie firmowej o czterech, pięciu szablonach i jednym formularzu prace naprawcze to zwykle od trzech do siedmiu dni roboczych, licząc kod i style, plus czas Twojego zespołu na opisy zdjęć i teksty. Przy sklepie z pełną ścieżką zakupową rozmowa toczy się o dwóch do sześciu tygodniach, bo koszyk, logowanie i płatność bada się i poprawia osobno, a każda zmiana wymaga powtórnego przejścia całej ścieżki. Najdłużej ciągną się dwie pozycje spoza kodu: dokumenty PDF, bo każdy trzeba poprawić z osobna, i nagrania wideo, bo napisy kosztują proporcjonalnie do minut materiału.
Moment startu warto wybrać świadomie. Najtaniej jest przy okazji przebudowy albo zmiany motywu, bo wtedy struktura i tak powstaje od nowa i dostępność jest wymaganiem projektowym, a nie poprawką. Najdrożej jest w trybie awaryjnym, po skardze albo po pytaniu z organu nadzoru, kiedy termin narzuca ktoś inny. Między tymi skrajnościami jest zwykły, spokojny wariant: audyt, dwa etapy poprawek rozłożone na kwartał i krótkie sprawdzenie po każdej większej zmianie w serwisie.
Kto ile ma zrobić: wykonawca, Twój zespół, podwykonawca
Rozdzielenie tego przed startem oszczędza najwięcej nerwów, bo w połowie projektów sporne staje się nie to, ile kosztuje praca, tylko czyja ona jest. Wykonawca strony odpowiada za wszystko, co wynika z kodu i stylów: kontrast, zaznaczenie klawiaturą, strukturę nagłówków w szablonach, poprawne etykiety i komunikaty w formularzach, obsługę okien modalnych, kolejność wczytywania. Twój zespół odpowiada za treść, bo tylko on wie, co jest na zdjęciu, co znaczy skrót branżowy i jak brzmi poprawna nazwa produktu. Podwykonawcy przypadają zwykle napisy do wideo i przebudowa dokumentów PDF, o ile nie chcesz ich po prostu zastąpić zwykłymi podstronami, co bywa najlepszym rozwiązaniem i najtańszym naraz.
Ostatnia rzecz do zapisania w umowie: kto pilnuje, żeby stan nie cofnął się za pół roku. Art. 32 ust. 2 pkt 4 i 5 wspomnianej ustawy każą uwzględniać zmiany w usłudze i w normach oraz podejmować działania naprawcze, gdy zgodność przestaje być zachowana. Bez ustalonego trybu sprawdzania każde nowe wdrożenie odbudowuje listę usterek, a rok później płacisz drugi raz za tę samą pracę. Wystarczy krótka kontrola po każdej większej zmianie i jedno pełne badanie w cyklu rocznym.
Na co uważać w ofertach
Oferty na dostosowanie strony do WCAG rozjeżdżają się bardziej niż oferty na samą stronę, bo zakres jest trudniejszy do opisania. Trzy sygnały ostrzegawcze powtarzają się najczęściej. Pierwszy to cena podana bez obejrzenia strony, bo bez wiedzy o liczbie szablonów i ścieżek jest to liczba wzięta z sufitu, która w trakcie projektu urośnie. Drugi to obietnica pełnej zgodności w abonamencie za kilkadziesiąt złotych miesięcznie, która niemal zawsze oznacza doklejenie nakładki. Trzeci to słowo "certyfikat" użyte tak, jakby chodziło o dokument urzędowy, podczas gdy żaden polski organ nie wydaje certyfikatów zgodności stron z WCAG, a to, co dostajesz, jest raportem prywatnego wykonawcy.
Zdrowa oferta wygląda inaczej: wymienia zbadane szablony i ścieżki, rozdziela pracę wykonawcy od pracy Twojego zespołu, podaje etapy z terminami i kwotami oraz mówi wprost, czego nie obejmuje. Jeżeli po audycie chcesz porównać kilka wycen, wyślij wszystkim ten sam raport i tę samą listę pytań, bo dopiero wtedy te dokumenty da się w ogóle zestawić. Ten sam mechanizm opisaliśmy szerzej przy zlecaniu wykonania strony internetowej, a formę zapytania przy formularzu zapytania ofertowego.
Co zrobić w tym tygodniu, jeśli nie masz jeszcze budżetu
Są trzy rzeczy, które nic nie kosztują i zdejmują z listy zaskakująco dużo. Pierwsza: przejdź swoją stronę samym tabulatorem, bez dotykania myszki, od nagłówka do wysłania formularza. Jeżeli nie widzisz, gdzie jesteś, albo utykasz w menu, masz już pierwszy priorytet i nie potrzebujesz do tego żadnego narzędzia. Druga: sprawdź kontrast tekstu na tle w miejscach, gdzie projektant użył szarości na białym, bo to najczęstszy pojedynczy błąd w polskich serwisach firmowych. Trzecia: uzupełnij opisy alternatywne przy zdjęciach niosących treść, na przykład przy zdjęciach produktów i grafikach z liczbami, pomijając ozdobniki.
To nie zastąpi badania i nie jest oceną zgodności w rozumieniu przepisu, ale ustawia rozmowę z wykonawcą na konkretach i zwykle obniża wycenę, bo część pracy jest już zrobiona. Kiedy będziesz gotowy na pełne badanie, wróć do audytu WCAG, a jeżeli prowadzisz podmiot publiczny, zacznij od tego, czy w ogóle masz opublikowaną deklarację dostępności, bo jej brak jest jedyną rzeczą w tym obszarze karaną wprost i niezależnie od stanu samej strony.
Potrzebujesz strony dla swojej firmy?
Skonfiguruj podgląd w Studiu Projektu i zamów online. Stała cena, gwarantowany termin.