Audyt WCAG – cennik 2026, co zawiera i jak zamówić

Audyt WCAG to techniczna ocena strony internetowej pod kątem zgodności z wytycznymi Web Content Accessibility Guidelines. W 2026 obowiązują dwa standardy referencyjne: WCAG 2.1 AA (do którego odnosi się polska ustawa o dostępności cyfrowej z 2019 roku) oraz nowszy WCAG 2.2 AA opublikowany przez W3C w październiku 2023, który dodaje 9 nowych kryteriów sukcesu. Audytor sprawdza, czy każdy element interfejsu (treści, formularze, multimedia, nawigacja, koszyk, checkout) jest dostępny dla osób z niepełnosprawnością wzroku, ruchu, słuchu i poznawczą, a wynik dostarcza w postaci raportu PDF z listą issue, priorytetami i rekomendacjami napraw. W Polsce żyje około 14 milionów osób z różnymi formami niepełnosprawności – to grupa, która bez audytu i wdrożenia WCAG nie korzysta swobodnie z Twojej strony, sklepu czy aplikacji. Konsekwencje wykraczają poza etykę: kary administracyjne w polskiej ustawie sięgają 10-krotności przeciętnego wynagrodzenia plus 10% rocznego obrotu, a po wdrożeniu EAA do reżimu sektorowego kary mogą rosnąć do 4% obrotu rocznego – analogicznie do RODO.

E-commerce B2C i sklepy internetowe

Każdy sklep internetowy obsługujący konsumentów jest objęty Aktem o dostępności od 28 czerwca 2025. Dotyczy to platform na WooCommerce, Shopify, PrestaShop, Magento i każdym innym silniku, niezależnie od skali obrotu (małe sklepy mają wydłużone okresy przejściowe, ale obowiązek istnieje). Najczęstsze problemy to brak labels w formularzach checkout, niski kontrast cen promocyjnych, brak alt text w zdjęciach produktów i koszyk niedostępny z klawiatury. W praktyce audyt dla sklepu z 50 produktami i 15 podstronami statycznymi mieści się w pakiecie Standard. Więcej o samych kosztach i checkliście wdrożeniowej dla sklepu znajdziesz na stronie usługi WCAG.

Sektory szczególnie objęte EAA

Banki, ubezpieczenia, transport pasażerski (kolej, lotnictwo, bus), telekomy i operatorzy energii mają zaostrzone wymogi. Tutaj pakiet Pro z certyfikatem zgodności jest praktycznie obowiązkowy, bo regulator (UKE, KNF, UTK w zależności od sektora) może zażądać dokumentacji audytowej w każdej chwili. Audyt obejmuje również aplikację mobilną i bramki płatności – warto to uwzględnić w briefie.

Sektor publiczny i jednostki samorządu

Urzędy, szkoły, biblioteki, szpitale i NGO finansowane ze środków publicznych mają obowiązek WCAG od 2019 roku, ale większość deklaracji dostępności została wystawiona na sucho, bez prawdziwego audytu. W 2026 roku NIK i Ministerstwo Cyfryzacji przyglądają się temu krytycznie – audyt zewnętrzny daje twardy dowód, że jednostka traktuje dostępność poważnie. Warto powiązać go z procesem aktualizacji deklaracji dostępności, który jest obowiązkowy raz w roku – szczegóły obowiązków formalnych opisujemy w poradniku Akt o dostępności 2025 i na stronie deklaracja dostępności.

Firmy powyżej 10 mln EUR obrotu lub 50 pracowników

Próg unijny wyłącza mikroprzedsiębiorstwa z części obowiązków, ale każda firma powyżej tej granicy jest traktowana tak samo jak duża korporacja. To często moment, kiedy spółka rosnąca z 30 do 60 osób nagle wpada w obowiązek – audyt warto wtedy przeprowadzić zanim regulator lub kontrahent o niego poprosi.

European Accessibility Act (EAA, Dyrektywa 2019/882) zaczął obowiązywać w państwach członkowskich Unii Europejskiej 28 czerwca 2025. W Polsce został wdrożony Ustawą o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze z 26 kwietnia 2024 roku. Dyrektywa to nie jest kosmetyczny obowiązek dla działu compliance – to konkretny reżim, który ma swojego polskiego nadzorcę (Państwowy Fundusz Rehabilitacji Osób Niepełnosprawnych, PFRON, oraz wojewódzkie inspektoraty Inspekcji Handlowej) i konkretne sankcje finansowe. Pełna lista wymogów dla producentów i operatorów usług jest dostępna w portalu Komisji Europejskiej – European Accessibility Act – dostępność produktów i usług.

Kogo dotyczy EAA – pełna lista sektorów

EAA obejmuje siedem grup produktów i usług oferowanych konsumentom po 28 czerwca 2025: sprzęt komputerowy ogólnego przeznaczenia (laptopy, smartfony, tablety), terminale samoobsługowe (bankomaty, biletomaty, kioski check-in), e-czytniki, usługi łączności elektronicznej (telefonia, internet), usługi medialne (VOD, IPTV), usługi bankowe konsumenckie (bankowość internetowa i mobilna) oraz – kluczowe dla większości naszych klientów – usługi handlu elektronicznego, czyli każdy sklep internetowy B2C. Dodatkowo regulator obejmuje transport pasażerski (informacja o połączeniach, sprzedaż biletów online, mobile self-service) oraz książki elektroniczne i ich oprogramowanie. Pełną listę po polsku można sprawdzić na stronie gov.pl – dostępność cyfrowa.

Wyłączenia – mikroprzedsiębiorstwa i okresy przejściowe

Z obowiązków EAA wyłączone są mikroprzedsiębiorstwa świadczące usługi (mniej niż 10 osób zatrudnionych oraz obrót poniżej 2 mln EUR rocznie). Wyłączenie nie dotyczy jednak produktów – jeśli mikrofirma sprzedaje sprzęt, podlega pełnym wymogom. Dodatkowo dyrektywa przewiduje okres przejściowy do 28 czerwca 2030 roku dla terminali samoobsługowych już istniejących oraz dla umów o świadczenie usług zawartych przed 28 czerwca 2025 (te kończą się naturalnie). To nie znaczy, że można czekać – każda nowa funkcjonalność, nowa wersja sklepu i nowa kampania marketingowa już musi być dostępna.

Kary za niezgodność w polskim porządku prawnym

Polska ustawa wdrażająca EAA przewiduje kary administracyjne nakładane przez PFRON i Inspekcję Handlową. W zależności od skali naruszenia kara może sięgnąć do 10-krotności przeciętnego miesięcznego wynagrodzenia (czyli ~80 000 zł w 2026) za pojedyncze naruszenie. Dla powtarzających się i poważnych naruszeń (np. systematyczna sprzedaż niedostępnego produktu konsumentowi z niepełnosprawnością) ustawa otwiera drogę do kar do 10% rocznego obrotu firmy. Komisja Europejska w swoich wytycznych wzorcowych dla państw członkowskich sugeruje pułap zbliżony do RODO, czyli do 4% rocznego obrotu globalnego. W praktyce wysokość kary zależy od skali firmy, długości naruszenia i tego, czy firma posiada raport audytu i deklarację dostępności – brak dokumentacji jest sam w sobie czynnikiem obciążającym.

Ryzyko poza karami – pozew zbiorowy i utrata kontraktu

Sankcje administracyjne to tylko jedna ścieżka ryzyka. Druga, równie kosztowna, to powództwa cywilne – osoba z niepełnosprawnością, która nie mogła zrobić zakupu w sklepie, ma prawo żądać odszkodowania na podstawie kodeksu cywilnego i ustawy antydyskryminacyjnej z 2010 roku. W praktyce ryzyko jest najwyższe w przypadku usług o charakterze publicznym (bilety, banki, e-recepta) i powtarzalnych transakcjach. Trzecia ścieżka to utrata kontraktu B2B – większe podmioty (zwłaszcza skarb państwa, korporacje europejskie i wielkie sieci handlowe) wpisują zgodność z WCAG do warunków SLA i mogą zerwać współpracę bez wypowiedzenia, jeśli partner nie spełnia obowiązków. Wartość utraconego kontraktu często wielokrotnie przekracza wartość audytu i wdrożenia.

Wytyczne WCAG 2.2 są zbudowane wokół czterech zasad fundamentalnych, w skrócie POUR: Perceivable (postrzegalność), Operable (funkcjonalność), Understandable (zrozumiałość) i Robust (kompatybilność). Każda zasada zawiera grupy wytycznych, a każda wytyczna ma od kilku do kilkunastu kryteriów sukcesu na trzech poziomach: A (minimum), AA (standard prawny dla większości krajów) i AAA (poziom rozszerzony). W 2026 standard prawny w UE i Polsce to AA, czyli łącznie 50 kryteriów sukcesu w WCAG 2.2 AA. Pełna specyfikacja techniczna z przykładami i testami jest dostępna w oryginalnym dokumencie WCAG 2.2 – W3C Recommendation, a polskie tłumaczenie z komentarzem branżowym znajdziesz na stronie WCAG KC Mobile.

Zasada 1: Perceivable (postrzegalność) – 30 kryteriów

Pierwsza zasada wymaga, żeby treść i komponenty interfejsu były prezentowane użytkownikom w sposób, który mogą postrzegać. Cztery wytyczne: 1.1 alternatywy tekstowe (alt dla obrazów, transkrypcje audio), 1.2 multimedia (napisy, audiodeskrypcja), 1.3 możliwość adaptacji (struktura semantyczna, kolejność czytania, prezentacja sensoryczna), 1.4 wyróżnialność (kontrast tekstu 4.5:1 AA, zmiana rozmiaru, obrazy tekstu, kontrast komponentów). Najczęstsze problemy w polskich sklepach to brak alt w zdjęciach produktów (1.1.1), brak napisów w filmach produktowych (1.2.2), niski kontrast cen promocyjnych (1.4.3) oraz brak responsywności tekstu przy zoom 200% (1.4.4).

Zasada 2: Operable (funkcjonalność) – 29 kryteriów (w tym 9 nowych z 2.2)

Druga zasada wymaga, żeby komponenty interfejsu i nawigacja były funkcjonalne. Pięć wytycznych: 2.1 dostępność z klawiatury, 2.2 wystarczający czas, 2.3 ataki padaczki (limit błysków), 2.4 możliwość nawigacji (focus state, page title, breadcrumb, kontekst linku) i 2.5 modalności wejścia. WCAG 2.2 dodała tu większość nowych kryteriów: 2.4.11 Focus Not Obscured (Minimum, AA – focus widoczny mimo paska sticky), 2.4.12 Focus Not Obscured (Enhanced, AAA), 2.4.13 Focus Appearance (AAA, grubość minimum 2 px), 2.5.7 Dragging Movements (AA – alternatywa dla drag-and-drop, np. w upload plików), 2.5.8 Target Size Minimum (AA – minimum 24x24 px dla każdego klikalnego elementu).

Zasada 3: Understandable (zrozumiałość) – 17 kryteriów

Trzecia zasada wymaga, żeby treść i działanie interfejsu były zrozumiałe. Trzy wytyczne: 3.1 czytelność (atrybut lang, słownik, skróty), 3.2 przewidywalność (focus i input nie zmieniają kontekstu nagle), 3.3 pomoc przy wprowadzaniu danych (etykiety, sugestie błędów, prewencja błędów dla transakcji prawnych i finansowych). WCAG 2.2 dodała tu 3.3.7 Redundant Entry (AA – nie zmuszaj użytkownika do wpisywania tych samych danych dwa razy w jednym procesie) i 3.3.8 Accessible Authentication Minimum (AA – nie wymagaj testów rozpoznawania obrazów lub liczb przy logowaniu, akceptuj password manager).

Zasada 4: Robust (kompatybilność) – 4 kryteria

Czwarta zasada wymaga, żeby treść była dostatecznie odporna, aby mogła być interpretowana przez różne agenty użytkownika, w tym technologie wspomagające. Dwie wytyczne: 4.1 kompatybilność (poprawny HTML, name/role/value komponentów ARIA, status messages). To najmniejsza ale technicznie najgłębsza zasada – wymaga, żeby każdy custom komponent (datepicker, modal, tab panel, autocomplete) miał poprawnie zaimplementowane atrybuty ARIA, semantyczne tagi i był dostępny dla wszystkich screen readerów. Tu najczęściej kładą się projekty na frameworkach SPA bez SSR – React i Vue z domyślną konfiguracją wymagają dodatkowej pracy nad ARIA i routerem.

Zamiast hasła wycena indywidualna pokazujemy konkretne widełki dopasowane do skali strony. Pakiety różnią się głębokością audytu, liczbą podstron, formatem raportu i czasem realizacji. Wszystkie ceny są netto, do każdej doliczamy 23% VAT. Pełny cennik audytu z formularzem zamówienia znajdziesz na stronie pakiety i ceny audytu – tam też możesz wybrać wariant i wypełnić brief w 5 minut.

Pakiet Ekspres – 999 zł netto

Wybierz Ekspres, gdy masz mały landing, wizytówkę firmową lub stronę portfolio do 5 podstron. Audyt łączy narzędzia automatyczne (axe DevTools, WAVE, Lighthouse) z podstawowym manualnym sprawdzeniem nawigacji klawiaturą i kontrastów. Raport PDF 5–7 stron zawiera TOP 10 issue ze screenshotami, ale bez szczegółowych rekomendacji wdrożeniowych – to czysta diagnoza, nie plan naprawy. To dobry start dla freelancera, mikrofirmy lub wewnętrznego pre-audytu przed pełnym Standard.

Pakiet Standard – 2 999 zł netto (najczęściej wybierany)

Standard to złoty środek dla sklepów internetowych, korpo stron i dashboardów SaaS w przedziale 15–20 podstron. Audyt manualny obejmuje testy z czytnikami ekranu NVDA i JAWS na Windows, VoiceOver na macOS i iOS oraz pełną nawigację klawiaturą każdego elementu interaktywnego. Dostajesz raport 30–50 stron z opisami issue, priorytetami P0/P1/P2, rekomendacjami napraw i screen recordingiem 5–10 minut pokazującym wybrane problemy w akcji. To wariant rekomendowany dla większości firm objętych EAA.

Pakiet Pro – od 5 999 zł netto

Pro to opcja dla sektora publicznego, banków i firm objętych szczególnym nadzorem regulatora. Pokrywa 30+ podstron, pełny WCAG 2.2 AA i częściowo AAA (kontrast 7:1, znajomość kontekstu wymagana itd.), plan naprawy z estymacją godzinową dla deweloperów, szkolenie zespołu (2–4 godziny online) i certyfikat zgodności po reaudyt. To również jedyny pakiet, w którym standardowo testujemy z realnymi użytkownikami z niepełnosprawnością wzroku i ruchu. Cena startowa to 5 999 zł netto, ale przy 50+ podstronach lub aplikacji mobilnej rośnie do 9 999–15 000 zł.

Profesjonalny raport WCAG ma stałą strukturę, którą rekrutujący w dziale compliance powinien rozpoznać niezależnie od dostawcy. Poniżej rozkładamy raport pakietu Standard sekcja-po-sekcji – Ekspres ma uproszczoną wersję, Pro dorzuca dodatkowe załączniki, ale szkielet pozostaje ten sam. Tym właśnie dobry audyt różni się od darmowego skanu Lighthouse za pięć minut: kontekstem biznesowym, manualnym review screen readerem i konkretnymi rekomendacjami pod warstwę kodu, nie tylko czerwoną listą błędów. Pełna oferta audytu i to, co zawiera każdy pakiet, opisana jest na stronie cennika audytu WCAG.

Streszczenie wykonawcze i score zgodności

Pierwsza strona raportu jest dla zarządu – maksymalnie jedna strona z trzema liczbami: % zgodności z WCAG 2.2 AA, liczba issue krytycznych (P0) i szacowany czas naprawy w godzinach. Druga sekcja to heatmapa pokazująca, które obszary strony są najgorsze (zwykle checkout, formularze rejestracji i komponenty tabeli danych). Manager nie musi czytać 50 stron, żeby zrozumieć skalę problemu i ustalić priorytety budżetowe.

Lista issue z opisem, kodem HTML i screenshotem

Każdy wykryty problem dostaje osobny wpis z numerem kryterium WCAG (np. 1.4.3 kontrast tekstu), opisem problemu zrozumiałym dla nietechnicznego managera, screenshotem z zaznaczonym elementem, fragmentem kodu HTML do naprawy, propozycją rozwiązania i priorytetem (P0 = blokujące, P1 = ważne, P2 = nice-to-have). Średnio sklep e-commerce ma 60–120 issue, z czego 5–15 to P0.

Roadmap napraw i quick wins

Sekcja praktyczna dla zespołu deweloperskiego: kolejność wdrożenia napraw zoptymalizowana pod stosunek kosztu do efektu. Quick wins (atrybuty alt, lang=pl, focus state w CSS) zamykasz w jeden sprint. Strukturalne naprawy (refactor formularzy, ARIA w komponencie nawigacji, redesign kontrastu) wymagają osobnych zadań w backlogu. Roadmap sugeruje sekwencję, dzięki której deklaracja dostępności może być uczciwa już po 4–6 tygodniach pracy.

Dane techniczne i załącznik z deklaracją

Raport zawiera listę narzędzi użytych w audycie, wersje przeglądarek (Chrome, Firefox, Safari, Edge), urządzenia (Windows 11, macOS, iOS, Android) oraz wersje screen readerów (NVDA 2024.x, JAWS 2024, VoiceOver 17). Dorzucamy też draft deklaracji dostępności gotowy do uzupełnienia danymi kontaktowymi i opublikowania w stopce strony – to oszczędza dwa dni pracy compliance officera.

Najpopularniejsze pytanie od klientów brzmi: skoro Lighthouse daje wynik 95 na 100, czy nie wystarczy mi to jako audyt? Krótka odpowiedź: nie. Według badań WebAIM (publikowanych corocznie w raporcie WebAIM Million) narzędzia automatyczne wykrywają od 25% do 35% wszystkich faktycznych problemów dostępności. Reszta to issue, które wymagają kontekstu biznesowego, testowania z czytnikami ekranu i zrozumienia intencji użytkownika – tego algorytmy nie potrafią. Profesjonalny audyt to mieszanka trzech warstw: automatyzacja (40%), manualny przegląd ze screen readerem (50%) i testy z prawdziwymi użytkownikami (10% przy pakiecie Pro).

Co wykrywa automatyczny skaner – Lighthouse, axe, WAVE

Automatyczne narzędzia są świetne w wykrywaniu mierzalnych defektów technicznych: brakujący atrybut alt, niski kontrast koloru (algorytm WCAG), brak label w polu formularza, hierarchia nagłówków, brak atrybutu lang, niepoprawnie ułożona struktura ARIA. To są tzw. 30% bottom – defekty kodu, które da się sprawdzić bez interakcji. Lighthouse Accessibility – dokumentacja Google wprost mówi, że narzędzie nie zastępuje manualnego audytu i pokazuje jedynie subset issue. To samo dotyczy axe DevTools od Deque oraz WAVE WebAIM – wszystkie trzy są częścią naszego pipeline'u, ale tylko jako pierwsza warstwa filtra.

Czego automat nie zobaczy – kontekst, sens, intencja

Automat zobaczy alt='zdjęcie' i powie OK – ale człowiek wie, że taki opis jest bezużyteczny dla osoby niewidomej. Automat zobaczy poprawny kontrast 4.5:1 między tekstem a tłem, ale nie zauważy, że tekst jest niewidoczny po wjechaniu na hover albo że w trybie ciemnym Windows znika cały footer. Automat nie sprawdzi, czy ścieżka klikalna w koszyku ma sens po pełnym Tab przez 47 elementów. Te problemy wymagają audytora, który manualnie przejdzie scenariusz użytkownika – rejestracja, dodanie do koszyka, checkout, kontakt – z włączonym NVDA, JAWS lub VoiceOver.

Screen reader testing – NVDA, JAWS, VoiceOver, TalkBack

NVDA (NonVisual Desktop Access) to darmowy open source screen reader na Windows, używany przez ponad 30% niewidomych użytkowników na świecie. JAWS to płatne, profesjonalne narzędzie korporacyjne (subskrypcja od ~1500 USD/rok), wciąż dominujące w sektorze rządowym i bankowym. Na macOS używamy wbudowanego VoiceOver (Cmd+F5), na iPhone i iPad też VoiceOver (Ustawienia → Dostępność), na Androidzie TalkBack. W audycie Standard testujemy minimum trzy z tych narzędzi – screen readery różnią się sposobem czytania ARIA i obsługą formularzy, więc poleganie tylko na jednym daje fałszywe poczucie zgodności.

Siteimprove i corporate-grade monitoring

Dla większych organizacji rekomendujemy Siteimprove Accessibility jako narzędzie do ciągłego monitoringu po wdrożeniu napraw. Siteimprove skanuje stronę codziennie, agreguje issue do dashboardu compliance, integruje się z Jira/ServiceNow i pozwala działowi PMO śledzić KPI dostępności w czasie. W audycie pakietu Pro standardowo konfigurujemy Siteimprove lub alternatywę open source (Pa11y Dashboard) w infrastrukturze klienta – to przekształca jednorazowy audyt w żywy proces compliance.

Najczęstsze pytanie po pierwszym kontakcie brzmi: ile w sumie zapłacę, jeśli zlecę cały proces od audytu do certyfikatu? Poniżej trzy realistyczne scenariusze oparte na projektach, które prowadziliśmy w 2025 i 2026 roku. Każdy z nich zawiera audyt, wdrożenie napraw, reaudyt i deklarację dostępności – czyli pełną pętlę compliance, której wymaga regulator. Końcowe koszty są zaokrąglone do najbliższej setki, ceny netto, do każdej doliczamy 23% VAT.

Scenariusz 1: mały landing – ~3 000 zł netto

Klient ma jednostronnicowy landing z formularzem kontaktowym, sekcją usług i mapą Google. Audyt Ekspres (999 zł) ujawnia 8–12 issue, z czego 2–3 P0 (focus state, kontrast CTA, brak label w formularzu). Wdrożenie zajmuje deweloperowi 6–8 godzin pracy (1 500 zł). Po wdrożeniu reaudyt potwierdza, że P0 zostały naprawione (500 zł). Razem proces zamyka się w ~3 000 zł netto i 2–3 tygodniach – mała firma jest zgodna z EAA bez przesadnej inwestycji. To wariant rekomendowany dla freelancerów, mikrofirm i jednorazowych kampanii.

Scenariusz 2: średni sklep WooCommerce – ~10 500 zł netto

Sklep z 15 produktami, 20 podstronami statycznymi (regulamin, polityka, FAQ, blog) i pełnym lejkiem zakupowym. Audyt Standard (2 999 zł) zwykle ujawnia 80–120 issue, z czego 8–15 to P0 (koszyk z klawiatury, label w checkoutie, kontrast cen, alt zdjęć produktów, focus state). Wdrożenie napraw to 30–50 godzin pracy dewelopera plus 5–10 godzin pracy designera, czyli budżet ~6 000 zł netto. Reaudyt zoptymalizowany pod sklep ~1 500 zł. Razem ~10 500 zł, 4–6 tygodni od briefingu do certyfikatu. To najczęstszy scenariusz dla małego i średniego e-commerce – pełna analiza budżetu i ROI jest w cennikach audyt WCAG i wdrożenie WCAG.

Scenariusz 3: duży serwis korpo + aplikacja – ~40 000 zł netto

Korpo z 50+ podstronami, dashboardem SaaS, aplikacją mobilną iOS/Android i integracjami płatności (Stripe, PayU, BLIK). Audyt Pro (9 999 zł przy aplikacji mobilnej w zakresie) ujawnia 200–400 issue. Wdrożenie wymaga zespołu 3–5 osób przez 6–10 tygodni (~25 000 zł netto, w tym refactor komponentów React/Vue, integracja ARIA w design system, testy z real users). Reaudyt z certyfikatem zgodności ~5 000 zł. Razem ~40 000 zł netto, kalendarz 3–4 miesiące. Cena wysoka, ale przy obrocie 50 mln zł rocznie to koszt ekwiwalentny 1–2 dniom pracy zespołu marketingu i pozwala uniknąć kar do 4% obrotu, czyli potencjalnie ~2 mln zł.

Z naszych ostatnich 30 audytów (sklepy, dashboard SaaS, sektor publiczny) wynika, że pewne błędy powtarzają się jak refren – ponad 80% audytowanych stron ma podobny zestaw issue. Poniżej dziesięć najczęstszych problemów z numerem kryterium WCAG i krótkim instruktażem, co zrobić. To checklista, którą warto przejść samodzielnie przed zamówieniem płatnego audytu – wyeliminujesz najtańsze defekty i zaoszczędzisz w pakiecie Standard.

1. Brak alt w obrazach informacyjnych (1.1.1)

Screen reader pomija obraz bez atrybutu alt albo czyta ścieżkę pliku, co dla użytkownika brzmi jak losowy ciąg znaków. Obrazy dekoracyjne powinny mieć pusty alt='', a informacyjne – krótki opis (do 125 znaków) zawierający kontekst, nie tylko nazwę przedmiotu. To problem, który dotyczy 95% audytowanych sklepów internetowych przy pierwszym podejściu.

2. Niski kontrast tekstu (1.4.3)

Standardowy próg WCAG AA to 4.5:1 dla zwykłego tekstu i 3:1 dla dużego tekstu (powyżej 18pt lub 14pt bold). Pakiet Pro (poziom AAA) wymaga 7:1. Najczęstsze winowajcy: szare etykiety formularzy na białym tle, ceny promocyjne w jasnoczerwonym kolorze, podpisy ikon w stopce. Naprawa to zwykle 2–3 zmiany w CSS variables, ale wymagają zatwierdzenia przez dział brandingu.

3. Brak widocznego focus state (2.4.7)

Każdy element interaktywny powinien mieć wyraźny ramki lub kolor focus, gdy użytkownik nawiguje klawiaturą. Standardowy outline przeglądarki bywa wyłączany przez globalny reset CSS (outline: none) i nikt nie wraca, żeby zaprojektować zastępczy stan. Bez focus state użytkownik klawiatury gubi się na stronie po pierwszych dwóch Tabach – to jeden z najczęstszych P0 w audytach.

4. Formularze bez labels (3.3.2)

Pole input bez tagu label albo bez atrybutu aria-label jest dla screen readera nieme – użytkownik nie wie, czy wpisuje email czy numer telefonu. Placeholdery NIE zastępują label (znikają po wpisaniu znaku, mają niski kontrast, niektóre screen readery je pomijają). Naprawa polega na dodaniu widocznego labelu nad każdym polem – możesz go ukryć wizualnie klasą sr-only, ale musi być w DOM.

5. Linki bez kontekstu kliknij tutaj (2.4.4)

Linki typu kliknij tutaj, więcej, czytaj dalej łamią kryterium 2.4.4 – screen reader czytający listę linków na stronie usłyszy 30 razy więcej, co jest bezużyteczne. Naprawa to kontekstowe nazewnictwo: zamiast więcej daj zobacz pełen cennik audytu WCAG. Daje to efekt podwójny – screen reader rozumie kontekst, a SEO poprawia się przez relevant anchor text.

6. Hierarchia nagłówków z dziurami (1.3.1)

Strona ma jeden H1, potem H3 i H5 bez H2 i H4 – screen reader, który nawiguje po nagłówkach, traci orientację i nie wie, gdzie kończy się sekcja. Naprawa to pełna inwentaryzacja nagłówków na każdej stronie i przebudowa do logicznej drabinki H1 → H2 → H3. Częsty efekt uboczny: poprawa SEO o 5–15% impressions w GSC, bo Google rozumie strukturę treści lepiej.

7. Brak atrybutu lang i mieszanie języków (3.1.1, 3.1.2)

bez atrybutu lang=pl każe screen readerowi czytać polski tekst angielską wymową – dla niewidomego użytkownika to jak słuchanie zniekształconej rozmowy. Drobne wstawki obcojęzyczne (np. anglosaskie nazwy produktów, łacińskie zwroty prawnicze) powinny być oznaczone lokalnie, np. checkout. To dwuminutowa naprawa, ale zwykle pomijana.

8. Tabele bez nagłówków th i scope (1.3.1)

Tabele danych bez tagów th i atrybutu scope tracą strukturę – użytkownik niewidomy nie wie, czy 120 zł to cena, marża czy podatek. Dotyczy to zwłaszcza tabel cennikowych i tabel z wynikami filtrów w sklepie. Naprawa: każda komórka pierwszego wiersza/kolumny musi być th, a atrybut scope='col' lub scope='row' wskazuje screen readerowi kontekst.

9. Niedostępne komponenty SPA i ARIA misuse (4.1.2)

Modale, dropdown, autocomplete i tabs zbudowane bez aria-expanded, aria-haspopup i aria-controls są dla screen readerów niewidzialne. Dodatkowo wiele projektów ma za dużo ARIA tam, gdzie wystarczy semantyczne – ARIA misuse wprowadza w błąd, nie pomaga. Naprawa wymaga refactoru komponentów i czasem zmiany frameworka design system.

10. Brak target size 24x24 px na mobile (2.5.8, nowe w WCAG 2.2)

Nowe kryterium WCAG 2.2 AA wymaga, żeby każdy klikalny element miał minimum 24x24 px (powierzchnia kliknięcia, nie sama ikona). Drobne ikony w nagłówku (lupa, koszyk, menu), małe przyciski close w modal i social icons w footerze najczęściej łamią ten próg. Naprawa to zwykle dodanie padding 8–12 px lub przerobienie komponentu na większy touch target. Wymóg obowiązuje dla wszystkich nowych projektów po październiku 2023.

Pytanie audyt własny czy agencja jest analogiczne do pytania prawnik czy ChatGPT – odpowiedź zależy od stawki, kompetencji wewnętrznych i tolerancji ryzyka. Poniżej praktyczna macierz decyzyjna, której używamy w rozmowach z klientami szukającymi tańszego wariantu. Najtańszy nie zawsze znaczy najgorszy – w przypadku mikrofirmy z prostym landingiem audyt samodzielny po naszym poradniku może być wystarczający, podczas gdy dla średniego sklepu próba zaoszczędzenia 2 999 zł kosztuje zwykle 4–5 razy więcej w przeoczonych issue.

Kiedy audyt samodzielny ma sens

Wybierz audyt własny, jeśli: 1) masz mały landing do 3 podstron bez sklepu i formularzy płatności, 2) twój zespół zawiera dewelopera lub designera z doświadczeniem WCAG (minimum certyfikat IAAP CPACC), 3) ryzyko regulacyjne jest niskie (mikroprzedsiębiorstwo świadczące usługi nieobjęte EAA), 4) traktujesz to jako rozgrzewkę przed pełnym audytem za 6 miesięcy. Toolkit: axe DevTools (free), WAVE bookmarklet, Lighthouse w Chrome, NVDA, Pa11y CLI. Plan: po 4 godzinach masz listę 30–50 issue, wystarczającą do podstawowej naprawy.

Kiedy bezwzględnie potrzebujesz audytu agencji

Zewnętrzny audyt jest praktycznie obowiązkowy, jeśli: 1) prowadzisz e-commerce B2C objęty EAA, 2) jesteś jednostką sektora publicznego (urząd, szkoła, szpital), 3) działasz w sektorze regulowanym (bank, telekom, transport, energia), 4) twoja firma ma ponad 50 pracowników lub 10 mln EUR obrotu, 5) podpisałeś kontrakt B2B z klauzulą WCAG (skarb państwa, korporacje), 6) zostałeś już wezwany przez regulator lub konsumenta do udowodnienia zgodności. W tych scenariuszach raport zewnętrznego audytora jest dokumentem prawnym, którego nie zastąpi własna ocena – brak takiego raportu w razie kontroli jest sam w sobie czynnikiem obciążającym.

Wariant hybrydowy – audyt pre + agencja

Najlepszy stosunek kosztu do efektu daje wariant hybrydowy: zrób audyt samodzielny po naszej checkliście (4–8 godzin), napraw oczywiste P0 (focus state, alt, lang, label), potem zamów audyt Standard u agencji. Dzięki temu raport za 2 999 zł skupi się na trudnych issue (ARIA, kontekst, scenariusze użytkownika), a nie na bazowych defektach, które ekspert zaznaczy automatem. Wielu naszych klientów po pre-audycie obniża wdrożenie z 50 do 25 godzin pracy dewelopera, oszczędzając ~2 500 zł na samym wdrożeniu.

Pułapka tanich automatycznych narzędzi do certyfikacji

Na rynku istnieją narzędzia oferujące tani lub darmowy audyt WCAG z automatycznym certyfikatem zgodności w 15 minut. To pułapka – żadne narzędzie automatyczne nie jest w stanie wydać prawnie wiążącego certyfikatu, bo nie testuje manualnie ze screen readerem. Co gorsza, fałszywy certyfikat na stronie zwiększa ryzyko regulacyjne, bo regulator może uznać go za świadome wprowadzanie w błąd konsumenta. Jedyne narzędzie certyfikujące, którego używamy, to nasze własne wdrożenie + reaudyt zewnętrzny – to wzorzec uznawany przez polskich i unijnych regulatorów.

Raport audytowy to tylko etap pierwszy. Wartość pojawia się dopiero, kiedy issue zostają naprawione, a strona realnie staje się dostępna. Poniżej standardowa ścieżka, którą rekomendujemy klientom KC Mobile po dostarczeniu raportu Standard lub Pro – sekwencja sprawdzona w kilkudziesięciu projektach. Cały proces obsługujemy end-to-end w ramach usługi wdrożenie WCAG, ale możesz też zlecić tylko fragment.

Spotkanie omawiające raport (1 godzina)

W ciągu 5 dni roboczych po dostarczeniu raportu organizujemy 60-minutowe spotkanie online. Tłumaczymy każdy P0 i P1 językiem zrozumiałym dla zarządu i działu marketingu, ustalamy priorytety wdrożenia i odpowiadamy na pytania techniczne deweloperów. Spotkanie jest częścią pakietu Standard i Pro – w Ekspres jest opcjonalne za dodatkowe 250 zł netto.

Wdrożenie napraw – trzy ścieżki

Pierwsza opcja: klient ma własny zespół deweloperski i wdraża naprawy samodzielnie (raport zawiera kod HTML, jesteśmy do konsultacji ad-hoc, 200 zł netto za godzinę). Druga: zlecasz nam pełne wdrożenie – cennik startuje od 30–60% kosztu audytu w zależności od zakresu, więcej na stronie wdrożenia WCAG. Trzecia (mix): my robimy P0 i krytyczne P1, Twój zespół zajmuje się P2 i drobiazgami. Każda opcja ma sens w innym kontekście budżetowym.

Reaudyt i certyfikat zgodności

Po wdrożeniu napraw warto zrobić reaudyt – mniejszy zakres, niższa cena (zwykle 50% pierwotnego audytu) i potwierdzenie, że poprawione issue rzeczywiście znikły, a nowe deploye nie wprowadziły regresji. Reaudyt jest podstawą do aktualizacji deklaracji dostępności i wystawienia certyfikatu zgodności (tylko pakiet Pro). W przypadku jednostek sektora publicznego współpracujemy też z Accessible EU – platformą Komisji Europejskiej i możemy dodać benchmarking sektorowy do raportu reaudytowego.

Aktualizacja deklaracji dostępności

Po pozytywnym reaudycie aktualizujemy lub przygotowujemy od zera deklarację dostępności – publiczny dokument, który musi być dostępny pod /deklaracja-dostepnosci/ na stronie. Zawiera status zgodności (zgodna / częściowo / niezgodna), datę publikacji, datę audytu, metodę oceny (samoocena / audyt zewnętrzny), kontakt do koordynatora dostępności i procedurę składania wniosków o zapewnienie dostępności. Pomagamy też wpisać deklarację w stopkę i menu strony, bo brak widocznego linku to jeden z częstszych powodów kar administracyjnych. Szczegóły w usłudze deklaracja dostępności.

To dwa różne dokumenty, które często są mylone na etapie zamawiania usługi. Audyt jest narzędziem diagnostycznym wewnętrznym, deklaracja jest publicznym oświadczeniem skierowanym do użytkowników. Bez porządnego audytu deklaracja staje się pustą formalnością, która nie chroni firmy przed kontrolą regulatora ani nie odpowiada realnie na potrzeby osób z niepełnosprawnością.

Praktyczna zasada: zamów audyt, dostań raport, wdróż naprawy P0/P1, dopiero potem aktualizuj deklarację. Odwrotna kolejność (najpierw deklaracja na podstawie zgadywania) generuje fałszywe dane, a regulator może uznać to za świadome wprowadzanie w błąd. Więcej o aspektach prawnych i technicznych dostępności cyfrowej na stronie naszej usługi WCAG oraz w sekcji strony WordPress, gdzie pokazujemy, jak zaprojektować motyw zgodny z WCAG od początku. Dla osób porównujących oferty cenowe warto też zerknąć na audyt cyfrowy, który łączy WCAG z technicznym SEO i UX.

Najszybsza droga: wybierz pakiet na stronie pakiety i ceny audytu WCAG lub skontaktuj się przez formularz i wpisz adres strony, szacunkową liczbę podstron oraz preferowany pakiet. W ciągu 24 godzin wysyłamy ofertę z konkretną ceną i terminem rozpoczęcia. Po akceptacji podpisujemy umowę, wystawiamy fakturę pro forma (50% przedpłata), a po opłacie startujemy audyt. Płatność końcowa po dostarczeniu raportu PDF. Zadzwoń też pod +48 604 939 140, jeśli wolisz omówić zakres telefonicznie – pierwsza rozmowa konsultacyjna jest bezpłatna i trwa zwykle 20–30 minut. Po audycie często naturalnie przechodzimy do wdrożenia WCAG, strony internetowej zgodnej z WCAG od początku albo do opieki WordPress, w której monitoring dostępności jest częścią pakietu Premium.

Planujesz audyt w ramach projektu z dotacji? Zobacz, jak sfinansować dostępny sklep lub stronę zgodną z WCAG i które programy realnie działają. Jeśli chcesz najpierw samodzielnie poprawić najczęstsze bariery, zajrzyj do technicznego przewodnika po dostępnym sklepie WooCommerce.