Wtorkowe posiedzenie zarządu sieci sklepów z artykułami domowymi. Dyrektor finansowy pokazuje pismo od kancelarii: od 28 czerwca 2025 roku sklep internetowy musi spełniać wymagania dostępności, a organem nadzoru dla handlu elektronicznego jest minister właściwy do spraw informatyzacji. Prezes zadaje proste pytanie: „Czy spełniamy?”. Product owner sklepu odpowiada szczerze, że nie wie. Agencja, która rok temu robiła redesign, twierdzi, że „wszystko jest zgodne z WCAG”, ale nikt nie widział żadnego raportu. Ktoś proponuje wtyczkę za kilkadziesiąt euro miesięcznie, która „robi dostępność automatycznie”.
To scenariusz, który od połowy 2025 roku powtarza się w setkach polskich firm. Przepisy są nowe, terminy już minęły, a rynek zalały oferty od „certyfikatu WCAG w 48 godzin” po bezpłatne skanery. Zarząd potrzebuje odpowiedzi na trzy pytania: czy nas to dotyczy, co dokładnie trzeba sprawdzić i ile to będzie kosztować w czasie i pieniądzach.
Ten artykuł jest dla osoby, która ma tę decyzję podjąć: prezesa, właściciela produktu albo szefa e-commerce. Wyjaśniamy, kogo obejmuje Polski Akt o Dostępności, czym różni się prawdziwy audyt dostępności od skanu, z czego składa się cena, ile trwa praca, co powinno znaleźć się w umowie z wykonawcą i po czym poznać ofertę, którą lepiej odrzucić.
Kogo obejmuje European Accessibility Act i polska ustawa?
European Accessibility Act to dyrektywa (UE) 2019/882. Państwa członkowskie miały ją wdrożyć do 28 czerwca 2022 roku i stosować od 28 czerwca 2025 roku. W Polsce wdrożyła ją ustawa z dnia 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze (Dz.U. 2024 poz. 731), nazywana potocznie Polskim Aktem o Dostępności. Ustawa weszła w życie 28 czerwca 2025 roku.
Ustawa nie dotyczy „wszystkich stron internetowych”. Wymienia konkretne usługi świadczone konsumentom. Z perspektywy firm cyfrowych najważniejsze są:
- usługi handlu elektronicznego, czyli sprzedaż produktów lub usług konsumentom na odległość przez stronę internetową lub aplikację,
- usługi bankowości detalicznej,
- usługi telekomunikacyjne i usługi dostępu do audiowizualnych usług medialnych,
- rozpowszechnianie książek elektronicznych,
- elementy usług transportu pasażerskiego (lotniczego, kolejowego, autobusowego, wodnego): strony internetowe, aplikacje mobilne, bilety elektroniczne, informacja o podróży.
Obejmuje też wybrane produkty, takie jak komputery ogólnego przeznaczenia z systemami operacyjnymi, bankomaty, biletomaty, terminale płatnicze, czytniki e-booków i smartfony. Jeśli Twoja firma nie produkuje sprzętu, najpewniej interesuje Cię część usługowa.
Dwa wyłączenia mają duże znaczenie praktyczne. Po pierwsze, ustawy nie stosuje się do usług świadczonych przez mikroprzedsiębiorców (art. 4 pkt 1). Dyrektywa definiuje mikroprzedsiębiorstwo jako firmę zatrudniającą mniej niż 10 osób, z rocznym obrotem lub sumą bilansową nieprzekraczającą 2 mln euro. Po drugie, przepisy dotyczą usług dla konsumentów. Platforma B2B, w której zamawiają wyłącznie firmy, co do zasady jest poza zakresem, choć granica bywa nieostra, gdy ten sam sklep obsługuje i firmy, i osoby prywatne.
Warto też odróżnić tę ustawę od starszej ustawy z 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych. Tamta dotyczy urzędów, szkół, szpitali publicznych i innych podmiotów publicznych. Nowa ustawa dotyczy firm prywatnych świadczących wymienione usługi. Wiele firm IT pracujących dla sektora publicznego zna już pierwszą i błędnie zakłada, że druga jej nie dotyczy, albo odwrotnie.
Jedno zastrzeżenie: ten artykuł opisuje przepisy tak, jak brzmią w tekście ustawy, ale nie jest poradą prawną. Jeśli Twoja usługa leży na granicy zakresu, na przykład platforma subskrypcyjna z elementami B2B, potwierdź kwalifikację z prawnikiem, zanim zamówisz audyt. Audyt techniczny powie Ci, czy usługa jest dostępna, a nie czy musi być.
Co grozi firmie, która nie spełnia wymagań dostępności?
Ustawa buduje system nadzoru z kilkoma organami. Ogólny nadzór sprawuje Prezes Zarządu PFRON. Dla poszczególnych sektorów są organy wyspecjalizowane (art. 38 ust. 3): dla handlu elektronicznego minister właściwy do spraw informatyzacji, dla bankowości detalicznej Rzecznik Finansowy, dla usług telekomunikacyjnych i e-booków Prezes Urzędu Komunikacji Elektronicznej, a dla poszczególnych rodzajów transportu odpowiednio Prezes UTK, Prezes ULC, wojewódzcy inspektorzy transportu drogowego i dyrektorzy urzędów morskich.
Ścieżka postępowania jest przewidywalna. Według art. 67 każdy może złożyć Prezesowi Zarządu PFRON zawiadomienie o tym, że usługa nie spełnia wymagań dostępności. Klient, który nie mógł dokończyć zakupu czytnikiem ekranu, nie musi więc iść do sądu. Wystarczy zawiadomienie. Jeśli kontrola potwierdzi niezgodność, organ wzywa usługodawcę do działań naprawczych i przedstawienia dowodów w terminie nie dłuższym niż 120 dni (art. 62). Może też decyzją zakazać świadczenia usługi na okres do 180 dni.
Kary pieniężne opisuje art. 73. Usługodawca, który nie zapewnia dostępności usług albo nie wykonuje obowiązków informacyjnych, podlega karze do dziesięciokrotności przeciętnego wynagrodzenia miesięcznego w gospodarce narodowej za rok poprzedni, nie wyższej jednak niż 10% obrotu. Według komunikatu Prezesa GUS z 9 lutego 2026 roku przeciętne wynagrodzenie w 2025 roku wyniosło 8 903,56 zł, więc górna granica pojedynczej kary to obecnie około 89 tys. zł. Wysokość ustala się z uwzględnieniem wagi naruszenia, liczby usług niespełniających wymagań i liczby osób, na które naruszenie wpływa.
Dla dużego sklepu 89 tys. zł nie jest kwotą, która zmienia wynik roku. Dlatego w rozmowie z zarządem ważniejsze są dwa inne ryzyka. Pierwsze to zakaz świadczenia usługi: dla firmy, która zarabia na sprzedaży internetowej, nawet krótka przerwa kosztuje więcej niż kara. Drugie to ryzyko utraty klientów i reputacji. Osoby z niepełnosprawnościami, seniorzy i ich rodziny to duża grupa kupujących, a wiele przeszkód dostępności, takich jak zbyt mały kontrast, brak etykiet formularzy czy brak obsługi klawiatury, utrudnia zakupy także osobom bez żadnej niepełnosprawności.
Jest też okres przejściowy, który bywa źle rozumiany. Według art. 85 umowy o świadczenie usług zawarte przed 28 czerwca 2025 roku mogą obowiązywać w niezmienionej treści do ich wygaśnięcia, ale nie dłużej niż do 28 czerwca 2030 roku. Usługodawca może też do tej daty korzystać z produktów, których używał wcześniej. Nie oznacza to, że sklep internetowy ma czas do 2030 roku. Nowe zamówienia składane przez stronę to nowe umowy, a sama strona jest usługą świadczoną dziś.
Na czym polega audyt dostępności i czym różni się od skanu?
Audyt dostępności to ocena, czy cyfrowa usługa spełnia określony standard, zwykle wytyczne WCAG na poziomie AA, wykonana przez ludzi według powtarzalnej metody, a nie tylko przez program. Skan to uruchomienie narzędzia automatycznego, które sprawdza kod strony pod kątem reguł możliwych do wykrycia maszynowo.
Różnica nie jest akademicka. Raport WebAIM Million z 2026 roku, który co roku analizuje strony główne miliona najpopularniejszych witryn, wykrył automatycznie błędy WCAG na 95,9% stron, średnio 56,1 błędu na stronę. Najczęstsze były zbyt niski kontrast tekstu (83,9% stron), brak tekstu alternatywnego obrazów (53,1%), brak etykiet pól formularzy (51%) i puste linki (46,3%). To dobry punkt wyjścia, ale to wyłącznie problemy, które da się wykryć automatycznie.
Czego narzędzie nie oceni? Czy tekst alternatywny opisuje produkt, czy brzmi „IMG_2024_final”. Czy kolejność, w jakiej klawisz Tab przechodzi po elementach, ma sens. Czy po dodaniu produktu do koszyka czytnik ekranu w ogóle informuje, że coś się stało. Czy komunikat o błędzie w formularzu płatności jest zrozumiały. Czy okno wyboru dostawy da się zamknąć bez myszy. Deque, producent narzędzi axe, opublikował w 2021 roku badanie oparte na ponad 2 000 audytów, według którego testy automatyczne w pełni wykryły średnio 57% problemów, licząc po liczbie wystąpień. Sam Deque zaznacza, że wynik zależy od metody liczenia, a typowe szacunki branżowe były niższe. Niezależnie od tego, którą liczbę przyjmiesz, kilkadziesiąt procent problemów wymaga oceny człowieka.
Dobry audyt łączy więc trzy warstwy:
- Testy automatyczne na całej próbce, żeby szybko zebrać problemy powtarzalne, takie jak kontrast i brakujące atrybuty.
- Ręczny przegląd ekspercki każdego kryterium sukcesu WCAG na wybranych szablonach: klawiatura, fokus, struktura nagłówków, formularze, komunikaty dynamiczne, multimedia.
- Testy z technologiami asystującymi na kluczowych ścieżkach: czytnik ekranu (NVDA lub JAWS na Windows, VoiceOver na macOS i iOS, TalkBack na Androidzie), powiększenie ekranu do 200% i 400%, nawigacja wyłącznie klawiaturą.
Metodę doboru próbki opisuje dokument W3C WCAG-EM (Website Accessibility Conformance Evaluation Methodology). Zakłada on, że audytor nie testuje każdego adresu URL, tylko reprezentatywny zestaw: każdy typ szablonu, kluczowe ścieżki zadań i losową próbkę stron. To ma bezpośredni wpływ na cenę, do czego wrócimy.
Jeśli zaczynasz od zera i chcesz najpierw zrozumieć zasady WCAG, podstawy wyjaśnia nasz wcześniejszy artykuł o tym, jak zacząć testowanie dostępności z WCAG. Ten tekst zakłada, że stoisz już przed decyzją zakupową.
Którą wersję WCAG przyjąć jako punkt odniesienia?
Ani dyrektywa, ani polska ustawa nie wymieniają WCAG z nazwy. Ustawa mówi o normach zharmonizowanych: jeśli usługa jest zgodna z odpowiednimi normami zharmonizowanymi lub specyfikacjami technicznymi, uznaje się, że spełnia wymagania dostępności w zakresie, który te normy obejmują (art. 20). W praktyce chodzi o europejską normę EN 301 549, która w części dotyczącej stron i aplikacji odwołuje się do WCAG.
Tu sprawa w 2026 roku się komplikuje. ETSI, CEN i CENELEC opublikowały 2 września 2026 roku wersję EN 301 549 V4.1.1, pierwszą przygotowaną z myślą o European Accessibility Act. Według Deque, która śledzi ten proces, V4.1.1 przyjmuje WCAG 2.2 na poziomie AA i ma zostać przywołana w Dzienniku Urzędowym UE około 30 listopada 2026 roku. Dopiero od takiego przywołania norma daje domniemanie zgodności. W dniu pisania tego artykułu publikacji w Dzienniku Urzędowym jeszcze nie było.
WCAG 2.2 jest rekomendacją W3C od 5 października 2023 roku. Dodaje dziewięć nowych kryteriów sukcesu, z czego dwa na poziomie A i cztery na poziomie AA, w tym widoczność elementu z fokusem, minimalny rozmiar celu dotyku i alternatywę dla przeciągania. Treść zgodna z WCAG 2.2 jest jednocześnie zgodna z WCAG 2.1, więc wyższy standard niczego nie psuje.
Praktyczna rekomendacja dla zarządu: zamawiając audyt dziś, zapisz w umowie WCAG 2.2 AA jako punkt odniesienia albo przynajmniej WCAG 2.1 AA z osobną listą kryteriów dodanych w 2.2. Audyt wykonany wyłącznie według WCAG 2.1 będzie za rok wymagał uzupełnienia, a różnica w nakładzie pracy jest niewielka w porównaniu z kosztem drugiego zamówienia. Ustal też, czy audyt ma objąć wymagania spoza WCAG, na przykład informację o dostępności usługi, którą usługodawca musi opublikować.
Co powinien obejmować zakres audytu dostępności?
Zakres to dokument, od którego zależy wszystko inne: cena, czas i to, czy raport będzie przydatny. Zanim poprosisz o ofertę, przygotuj odpowiedzi na sześć pytań.
Jakie platformy? Strona responsywna, osobna wersja mobilna, aplikacja iOS, aplikacja Android, panel klienta po zalogowaniu. Każda platforma to osobna próbka i osobny zestaw technologii asystujących.
Jakie szablony? Wypisz unikalne typy ekranów: strona główna, lista produktów, karta produktu, wyszukiwarka z filtrami, koszyk, kolejne kroki zamówienia, logowanie, rejestracja, konto klienta, formularz reklamacji, strony treściowe, regulamin. W typowym sklepie to kilkanaście do kilkudziesięciu szablonów, mimo że adresów URL są dziesiątki tysięcy.
Jakie ścieżki zadań? Ustawa dotyczy usługi, a nie pojedynczych stron, więc audyt musi sprawdzić, czy da się wykonać całe zadanie: znaleźć produkt, dodać do koszyka, wybrać dostawę, zapłacić, otrzymać potwierdzenie, złożyć reklamację. Trzy do pięciu ścieżek zwykle pokrywa to, co najważniejsze.
Jakie elementy zewnętrzne? Bramka płatności, widżet czatu, mapa punktów odbioru, system opinii, baner zgód cookies. Często są dostarczane przez innych dostawców, ale z perspektywy klienta to część Twojej usługi. Audyt powinien je wskazać, nawet jeśli naprawić może je tylko ich dostawca.
Jakie dokumenty? Faktury PDF, regulamin, instrukcje produktów do pobrania. Pliki dokumentów opublikowane przed wejściem ustawy w życie są wyłączone (art. 86), ale nowe już nie.
Jaki standard i jaki poziom? WCAG 2.2 AA albo 2.1 AA, jak opisano wyżej, oraz to, czy audytor ma ocenić także informację o dostępności usługi.
Dobrze opisany zakres skraca negocjacje i pozwala porównać oferty. Jeśli trzech wykonawców dostaje ten sam dokument, różnice w cenie wynikają z metody i stawek, a nie z tego, że każdy inaczej zrozumiał zadanie. Ogólne zasady planowania testów i zarządzania nimi opisujemy w hubie wiedzy o zapewnianiu jakości.
Od czego zależy koszt audytu dostępności?
Nie podamy jednej kwoty, bo jej uczciwie nie ma. Nie znaleźliśmy też niezależnego, metodycznie zbieranego badania cen audytów dostępności w Polsce. Możemy natomiast pokazać, jak cena powstaje, żebyś mógł ją sam oszacować i ocenić oferty.
Audyt to praca ekspertów rozliczana w osobodniach. Cena to w przybliżeniu liczba osobodni × stawka dzienna, plus ewentualny retest. Liczbę osobodni napędzają czynniki z tabeli poniżej.
| Czynnik | Co zwiększa nakład | Co go zmniejsza |
|---|---|---|
| Liczba unikalnych szablonów | Dużo różnych typów ekranów, rozbudowany panel klienta | Spójny system komponentów, mało wyjątków |
| Liczba platform | Web + iOS + Android, osobna wersja mobilna | Jedna responsywna strona |
| Ścieżki zadań | Wieloetapowe zamówienia, konfiguratory, kalkulatory | Prosty zakup w kilku krokach |
| Elementy dynamiczne | Filtry bez przeładowania, modale, karuzele, czat | Klasyczne formularze i nawigacja |
| Technologie asystujące | Kilka czytników ekranu na kilku systemach | Jeden czytnik na platformę |
| Standard | WCAG 2.2 AA + wymagania informacyjne | WCAG 2.1 AA bez dodatków |
| Głębokość raportu | Rekomendacje kodu dla każdego problemu, priorytety, szacunek naprawy | Sama lista niezgodności |
| Retest | Kilka rund weryfikacji poprawek | Jeden retest |
Żeby przełożyć to na pieniądze, weź stawki rynkowe. W ARDURA Consulting stawki specjalistów QA, według strony usług testowania, wynoszą od 560 do 1 440 zł netto za dzień dla testerów manualnych i od 720 do 2 000 zł dla inżynierów automatyzacji. To nie jest cennik audytu dostępności, tylko widełki dziennych stawek ról, które taki audyt wykonują.
Szacunek, który możesz z tego zrobić: jeśli audyt sklepu z kilkunastoma szablonami na jednej platformie wymaga, powiedzmy, 8–15 osobodni, a stawka dzienna doświadczonego testera wynosi 1 000–1 400 zł, sam audyt kosztowałby 8–21 tys. zł netto. Serwis z aplikacjami na dwie platformy i rozbudowanym panelem może wymagać dwa–trzy razy więcej. Podkreślamy: to ilustracja metody, nie oferta. Rzeczywista liczba dni wynika z zakresu i ustala się ją przed startem.
Jeszcze jedna uwaga budżetowa. Audyt to zwykle najtańsza część projektu dostępności. Naprawa kodu, przeprojektowanie komponentów, poprawki w treściach i retest kosztują więcej niż sama diagnoza. Dlatego dobry raport powinien zawierać nie tylko listę problemów, ale też ich priorytety i wskazówki naprawy, żeby zespół deweloperski mógł oszacować swoją pracę. Zarząd, który zatwierdza budżet tylko na audyt, za trzy miesiące dostanie raport i pytanie, skąd wziąć pieniądze na resztę.
Ile trwa audyt i jak wygląda harmonogram?
Czas trwania zależy od tych samych czynników co cena. Szacunkowo, dla serwisu z kilkunastoma szablonami na jednej platformie, praca od podpisania umowy do raportu zajmuje od jednego do trzech tygodni kalendarzowych. Dla kilku platform i wielu ścieżek odpowiednio dłużej. Typowy przebieg wygląda tak.
Tydzień 0: ustalenie zakresu. Spotkanie, na którym zespół produktu pokazuje usługę, a audytor dobiera próbkę według WCAG-EM. Wynik to lista szablonów, ścieżek, platform i technologii asystujących, zatwierdzona na piśmie. Na tym etapie ustala się też dostęp do środowiska testowego i konta testowe, w tym takie, które pozwalają przejść płatność bez prawdziwej transakcji.
Tydzień 1: testy automatyczne i przegląd ekspercki. Audytor uruchamia narzędzia na całej próbce, a następnie przechodzi ręcznie przez kryteria sukcesu na każdym szablonie. To najbardziej pracochłonna część.
Tydzień 1–2: testy z technologiami asystującymi. Kluczowe ścieżki zadań przechodzone czytnikiem ekranu, samą klawiaturą i z powiększeniem. Tu wychodzą problemy, które blokują zakup, a nie tylko obniżają wygodę.
Tydzień 2–3: raport i omówienie. Raport trafia do zespołu, a audytor omawia go z product ownerem i deweloperami, żeby wszyscy rozumieli priorytety.
Po naprawach: retest. Weryfikacja poprawek na tej samej próbce, zwykle kilka dni pracy, w zależności od liczby zgłoszeń.
Najczęstsza przyczyna opóźnień nie leży po stronie audytora. To brak środowiska testowego, brak kont testowych, niedziałające płatności testowe albo zmiany wdrażane w trakcie audytu. Jeśli sklep wypuszcza nową wersję co tydzień, ustal z zespołem zamrożenie zakresu na czas testów albo audytuj środowisko stagingowe z konkretną wersją.
Co powinien zawierać raport z audytu dostępności?
Raport jest produktem, za który płacisz. Poproś o jego wzór przed podpisaniem umowy i sprawdź, czy zawiera następujące elementy.
Podsumowanie dla zarządu. Jedna–dwie strony: czy usługa w obecnym stanie pozwala wykonać kluczowe zadania osobom korzystającym z technologii asystujących, ile jest problemów krytycznych, jakie są najważniejsze ryzyka i co trzeba zrobić najpierw. Bez żargonu.
Lista niezgodności z odniesieniem do kryteriów. Każdy problem przypisany do konkretnego kryterium sukcesu WCAG, z miejscem wystąpienia (szablon, komponent, krok ścieżki), zrzutem ekranu lub nagraniem i opisem, jak go odtworzyć.
Priorytet według wpływu na użytkownika. Brak etykiety w polu newslettera w stopce i brak możliwości zatwierdzenia płatności klawiaturą to oba błędy, ale tylko jeden uniemożliwia zakup. Raport powinien je rozróżniać, na przykład w skali: blokujący, poważny, umiarkowany, drobny.
Rekomendacje naprawy. Dla każdego problemu: co zmienić w kodzie lub treści, najlepiej z przykładem. Problemy powtarzalne powinny być zgrupowane na poziomie komponentu, bo jedna poprawka w bibliotece komponentów naprawia setki wystąpień.
Opis metody i próbki. Które strony, ścieżki, przeglądarki i technologie asystujące zostały przetestowane, w jakich wersjach i kiedy. Bez tego raport nie ma wartości dowodowej, gdy organ nadzoru zapyta, na jakiej podstawie twierdzisz, że usługa jest dostępna.
Materiał do informacji o dostępności usługi. Usługodawca musi podać do publicznej wiadomości, w regulaminie lub równoważnym dokumencie, informację o tym, w jaki sposób usługa spełnia wymagania dostępności (art. 32 ust. 2). Raport powinien dać Ci materiał, na podstawie którego prawnik i zespół produktu przygotują taki tekst.
Zwróć uwagę na rzecz, której w raporcie być nie powinno: certyfikatu zgodności z EAA. Ustawa nie przewiduje certyfikacji usług przez podmioty prywatne. Usługodawca sam ocenia zgodność usługi (art. 32 ust. 1) i za tę ocenę odpowiada. Audytor dostarcza dowody i rekomendacje, a nie urzędowe potwierdzenie.
Jakie sygnały w ofercie powinny Cię zaniepokoić?
Rynek dostępności po 2025 roku przyciągnął firmy, które sprzedają uspokojenie zamiast pracy. Oto sygnały ostrzegawcze, które warto znać przed rozmową z dostawcą.
„Certyfikat WCAG” lub „certyfikat EAA” w kilka dni. Jak wyżej: nie ma urzędowego certyfikatu dla usług. Dokument z pieczątką nie przenosi na wykonawcę Twojej odpowiedzialności.
Nakładka (overlay) jako rozwiązanie zgodności. Widżety, które po dodaniu jednej linii skryptu obiecują „automatyczną zgodność”, nie naprawiają kodu strony. W kwietniu 2025 roku Federalna Komisja Handlu USA zatwierdziła ostateczny nakaz wobec firmy accessiBe, która musiała zapłacić 1 mln dolarów za wprowadzające w błąd twierdzenia, że jej widżet może sprawić, że dowolna strona będzie zgodna z WCAG. Nakaz zabrania firmie takich twierdzeń bez dowodów. To decyzja amerykańska, ale argument jest uniwersalny: zgodność wynika z kodu i treści, a nie z nakładki.
Raport będący eksportem z narzędzia. Jeśli wzór raportu to tabela z tysiącami wierszy wygenerowana przez skaner, bez priorytetów, ścieżek i testów czytnikiem ekranu, płacisz za uruchomienie programu, który możesz uruchomić sam.
Brak informacji, kto testuje i jakimi narzędziami. Zapytaj, czy audytor używa czytnika ekranu na co dzień w pracy, na jakich systemach testuje i czy w zespole są osoby korzystające z technologii asystujących. Nie każdy audyt musi obejmować testy z udziałem użytkowników z niepełnosprawnościami, ale wykonawca powinien umieć powiedzieć, kiedy byłyby wskazane.
Cena za adres URL. Wycena „za podstronę” zachęca do testowania tysięcy podobnych stron zamiast reprezentatywnych szablonów i ścieżek. Rozsądna wycena opiera się na próbce i osobodniach.
Brak retestu w ofercie. Audyt bez weryfikacji poprawek kończy się raportem, który po trzech miesiącach nie odpowiada stanowi usługi. Retest powinien być w ofercie albo jako cena, albo jako opcja.
Jak zaplanować naprawy po audycie, żeby nie wracać do punktu wyjścia?
Raport z kilkuset zgłoszeniami potrafi sparaliżować zespół produktu. Kilka zasad pomaga przejść od diagnozy do usługi, która pozostanie dostępna.
Najpierw blokady na ścieżkach zakupowych. Wszystko, co uniemożliwia osobie korzystającej z klawiatury albo czytnika ekranu znalezienie produktu, zamówienie i zapłatę, idzie na początek kolejki. To one decydują o tym, czy usługa jest dostępna w rozumieniu ustawy, i to one kosztują sprzedaż.
Naprawiaj komponenty, nie strony. Większość problemów powtarza się, bo wynika z jednego komponentu: przycisku, pola formularza, okna modalnego. Poprawka w bibliotece komponentów albo w systemie projektowym naprawia problem w całym serwisie. Tu przydaje się dobra współpraca z projektantami, bo część problemów, na przykład kontrast czy rozmiar celów dotyku, zaczyna się w projektowaniu UX/UI, a nie w kodzie.
Wpisz dostępność w definicję ukończenia. Każda nowa funkcja powinna przechodzić podstawowe kontrole dostępności przed wdrożeniem: automatyczny skan w CI, przejście klawiaturą, sprawdzenie etykiet. Inaczej za rok audyt pokaże nowe problemy w nowych funkcjach.
Dołącz kontrole dostępności do testów regresji. Automatyczne testy dostępności można uruchamiać w potoku CI razem z testami funkcjonalnymi. Nie zastąpią ręcznej oceny, ale wyłapią cofnięcia, na przykład usunięty atrybut czy pogorszony kontrast. Więcej o tym, jak budować taki zestaw, piszemy przy okazji testów regresji.
Zaplanuj okresowy przegląd. Usługa zmienia się co sprint. Rozsądny rytm to ręczny przegląd kluczowych ścieżek przy każdej dużej zmianie i pełniejszy audyt co rok lub przy przebudowie. Ustawa wymaga zresztą od usługodawcy uwzględniania zmian w usłudze i w normach (art. 32 ust. 2 pkt 4), więc jednorazowa ocena nie zamyka tematu.
Audyt zewnętrzny czy kompetencje w zespole?
To pytanie, które zarząd powinien zadać, zanim zamówi cokolwiek. Odpowiedź zależy od tego, ile usług cyfrowych firma rozwija i jak często je zmienia.
Jednorazowy audyt zewnętrzny ma sens, gdy potrzebujesz niezależnej oceny stanu wyjściowego, gdy zespół nie ma doświadczenia z dostępnością albo gdy zbliża się przebudowa i chcesz wiedzieć, czego nie powtórzyć. Daje świeże spojrzenie i dokument, który możesz pokazać zarządowi lub organowi nadzoru.
Tester dostępności w zespole ma sens, gdy usługa rozwija się co sprint, a naprawy po audycie potrwają miesiące. Wtedy osoba, która zna WCAG i technologie asystujące, pracuje razem z deweloperami, weryfikuje poprawki na bieżąco i pilnuje, żeby nowe funkcje nie wprowadzały nowych problemów. W modelu body leasingu taki specjalista dołącza do zespołu na określony czas, na przykład na okres napraw i stabilizacji, bez rekrutacji etatowej.
Model mieszany jest najczęściej najrozsądniejszy: audyt zewnętrzny na start i co roku, a pomiędzy nimi kompetencje w zespole. Ważne, żeby audytor roczny nie był tą samą osobą, która na co dzień zatwierdza poprawki, bo traci się wtedy niezależność oceny.
W ARDURA Consulting testy dostępności według WCAG 2.1 są częścią usług testowania oprogramowania, obok testów funkcjonalnych, regresji, testów mobilnych i automatyzacji. Możemy przeprowadzić ocenę według zakresu uzgodnionego na piśmie albo zapewnić testerów, którzy dołączą do Twojego zespołu na czas napraw i retestów. Jeśli punktem odniesienia ma być WCAG 2.2, zapisujemy to w zakresie przed startem.
Jak przygotować firmę do audytu, żeby nie przepłacić?
Przygotowanie po stronie zamawiającego potrafi skrócić audyt o kilka dni i poprawić jakość wyników. Oto lista rzeczy, które warto zrobić przed wysłaniem zapytania ofertowego.
Potwierdź zakres prawny. Ustal z prawnikiem, które usługi podlegają ustawie i czy któraś z nich korzysta z okresu przejściowego. Audyt techniczny nie rozstrzygnie, czy jesteś mikroprzedsiębiorcą albo czy Twoja platforma jest B2C.
Spisz szablony i ścieżki. Lista unikalnych typów ekranów i trzech–pięciu kluczowych zadań klienta to najcenniejszy dokument dla wykonawcy. Pozwala wycenić pracę dokładnie zamiast „na oko”.
Przygotuj środowisko i konta testowe. Środowisko stagingowe z wersją, która nie zmieni się w trakcie audytu, konta testowe z różnymi uprawnieniami i możliwość przejścia płatności testowej.
Zbierz dane o dostawcach zewnętrznych. Kto dostarcza bramkę płatności, czat, mapę punktów odbioru, baner cookies. Zapytaj ich o deklaracje dostępności, zanim audytor znajdzie w nich problemy.
Uruchom bezpłatny skan sam. Narzędzia takie jak rozszerzenia przeglądarki do automatycznych testów dostępności pokażą, czy problemów jest kilka, czy kilkaset. To nie zastąpi audytu, ale pomoże ocenić, czy wykonawca proponuje sensowny zakres.
Wyznacz właściciela planu napraw. Raport bez właściciela to dokument, który ląduje na dysku współdzielonym. Zanim zamówisz audyt, ustal, kto przejmie priorytety i kto zatwierdzi budżet napraw.
Zapytaj o metodę i wzór raportu. Poproś trzech wykonawców o opis metody, próbki i wzór raportu. Porównaj, kto testuje z czytnikiem ekranu, kto daje priorytety, kto oferuje retest. Cena jest dopiero czwartym kryterium.
Co zapamiętać przed zamówieniem audytu dostępności?
Polski Akt o Dostępności obowiązuje od 28 czerwca 2025 roku i dotyczy usług cyfrowych dla konsumentów: handlu elektronicznego, bankowości, telekomunikacji, e-booków i części transportu. Nie dotyczy mikroprzedsiębiorców. Za brak dostępności grozi kara do dziesięciokrotności przeciętnego wynagrodzenia, ale poważniejszym ryzykiem jest zakaz świadczenia usługi i utrata klientów.
Audyt dostępności to ocena ekspercka, a nie skan. Łączy testy automatyczne, ręczny przegląd kryteriów WCAG i testy kluczowych ścieżek z czytnikami ekranu. Jako punkt odniesienia warto przyjąć WCAG 2.2 AA, bo na nim opiera się nowa wersja normy EN 301 549. Cena wynika z liczby osobodni, a tę napędzają szablony, platformy, ścieżki i głębokość raportu. Audyt jest zwykle tańszy niż naprawy, więc budżet trzeba planować na całość.
Odrzucaj oferty certyfikatów, nakładek i raportów eksportowanych z narzędzi. Wymagaj opisu metody, priorytetów, rekomendacji naprawy i retestu. Po audycie naprawiaj komponenty zamiast stron i wpisz dostępność w proces wytwarzania, żeby nie wracać do punktu wyjścia za rok.
Jeśli chcesz ustalić zakres oceny dostępności swojej usługi albo wzmocnić zespół testerami na czas napraw, zobacz nasze usługi testowania oprogramowania albo umów rozmowę o zakresie. Powiemy, jaką próbkę warto przetestować, ile pracy to oznacza i co możesz zrobić sam, zanim zapłacisz komukolwiek.