Dostępność cyfrowa 2026: jak audytować stronę i aplikację firmy?

01

Fakty: od kiedy obowiązuje Polski Akt o Dostępności?

Ustawa z 26 kwietnia 2024 r. wdrażająca dyrektywę (UE) 2019/882 weszła w życie 28 czerwca 2025 r. Obejmuje wskazane w niej produkty oraz usługi świadczone konsumentom. W obszarze cyfrowym są to między innymi usługi telekomunikacyjne, dostęp do audiowizualnych usług medialnych, wybrane cyfrowe elementy transportu pasażerskiego, bankowość detaliczna i rozpowszechnianie książek elektronicznych.

Dla objętych usług ustawa wymaga między innymi, aby strony internetowe i aplikacje mobilne były postrzegalne, funkcjonalne, zrozumiałe i kompatybilne. Usługodawca przeprowadza ocenę zgodności, udostępnia informacje o usłudze i sposobie spełniania wymagań oraz reaguje na wykryte braki. Konkretne wymagania zależą od rodzaju usługi.

Materiał zweryfikowano 15 października 2026 r. Ma charakter informacyjny i procesowy, nie jest indywidualną poradą prawną. Zakres obowiązków warto potwierdzić dla konkretnej usługi, roli przedsiębiorcy, kanału cyfrowego oraz ewentualnych wymagań sektorowych lub umownych.

02

Fakty: czy każda strona lub aplikacja firmy podlega ustawie?

Nie. Ustawa wskazuje zamknięte kategorie produktów i usług. Sama obecność firmy w Internecie nie oznacza jeszcze, że jej informacyjna strona podlega Polskiemu Aktowi o Dostępności. Znaczenie ma to, jaką usługę strona lub aplikacja faktycznie umożliwia i komu jest ona świadczona. Inne obowiązki mogą jednak wynikać z przepisów o podmiotach publicznych, zamówienia, dofinansowania, regulacji branżowej albo umowy.

Ustawa wyłącza usługi oferowane lub świadczone przez mikroprzedsiębiorców. To wyłączenie dotyczy usług i nie powinno być automatycznie przenoszone na obowiązki związane z produktami. Przepisy zawierają również wyjątki oraz zasady oceny zasadniczej zmiany i nieproporcjonalnego obciążenia, które wymagają udokumentowanej analizy, a nie ogólnego oświadczenia.

Umowy dotyczące usług zawarte przed 28 czerwca 2025 r. mogą działać na zasadach przejściowych do ich wygaśnięcia, nie dłużej niż do 28 czerwca 2030 r. Osobne reguły przejściowe dotyczą także produktów używanych do świadczenia usług i starszych treści internetowych. Nowe wdrożenie należy zatem oceniać inaczej niż niezmieniane archiwum.

03

Fakty: co WCAG 2.2 daje firmie — i czego nie daje?

WCAG 2.2 jest rekomendacją W3C opisującą testowalne kryteria dostępności treści internetowych. Rozwija WCAG 2.1 o dziewięć kryteriów, między innymi dotyczących widoczności fokusu, alternatywy dla przeciągania, minimalnego rozmiaru celu, spójnej pomocy, ponownego wpisywania danych i dostępnego uwierzytelniania.

WCAG porządkuje techniczne wymagania wokół postrzegalności, funkcjonalności, zrozumiałości i solidności rozwiązania. Jest użyteczną bazą dla specyfikacji, projektowania, testów i odbioru. Nie zastępuje jednak analizy zakresu ustawy ani wymagań specyficznych dla danej usługi. PFRON podkreśla, że jego wytyczne przedstawiają możliwe sposoby zapewnienia dostępności, lecz nie są wykładnią prawa.

Nie istnieje też jeden skaner, który zbada całość. Narzędzia automatyczne szybko znajdują część błędów w kodzie, ale nie ocenią wiarygodnie sensu tekstu alternatywnego, logicznej kolejności, zrozumiałości instrukcji, jakości komunikatu o błędzie ani tego, czy użytkownik kończy cały proces bez pomocy myszy.

04

Rekomendacja WEBee: zacznij od zakresu i ścieżek krytycznych

Najpierw opisz usługę, użytkowników i najważniejsze rezultaty. Zamiast testować przypadkowe podstrony, wybierz pełne ścieżki: logowanie, wyszukanie informacji, rezerwację lub zakup biletu, złożenie wniosku, pobranie dokumentu, płatność, zmianę danych, odzyskanie dostępu i kontakt z pomocą.

Dla każdej ścieżki wskaż ekrany, dokumenty, zewnętrzne komponenty, właściciela biznesowego oraz zdarzenie kończące. Zależność od dostawcy nie usuwa problemu z perspektywy użytkownika. PFRON wskazuje, że w modelu outsourcingowym odpowiedzialność za dostępność objętej usługi pozostaje po stronie usługodawcy świadczącego ją konsumentom.

• ustal, czy usługa i podmiot mieszczą się w zakresie właściwych przepisów;
• zidentyfikuj wszystkie kanały: WWW, aplikację, dokumenty, pocztę i wsparcie;
• wybierz krytyczne ścieżki użytkownika zamiast losowej próbki ekranów;
• uwzględnij logowanie, błędy, limity czasu i sytuacje bez danych;
• zapisz komponenty zewnętrzne oraz odpowiedzialność umowną dostawców;
• zdefiniuj poziom odniesienia, kryteria odbioru i dowody z testów.

05

Rekomendacja WEBee: połącz cztery rodzaje testów

Audyt powinien łączyć warstwy, ponieważ każda wykrywa inne problemy. Skan automatyczny pomaga znaleźć brakujące nazwy, nieprawidłowe role i część błędów kontrastu. Przegląd ręczny ocenia strukturę nagłówków, kolejność fokusu, sens linków, powiększenie i zachowanie przy zmianie orientacji lub rozmiaru ekranu.

Następnie należy przejść najważniejsze ścieżki samą klawiaturą i z czytnikiem ekranu. Osobno testuje się formularze, walidację, dostępne uwierzytelnianie, pliki PDF, multimedia oraz komunikaty dynamiczne. Badanie z użytkownikami technologii asystujących może ujawnić bariery, których nie pokazuje lista kontrolna.

• automatyczny skan reprezentatywnych ekranów i szablonów;
• ręczna kontrola WCAG 2.2 z dowodami dla każdego wyniku;
• test klawiaturą, czytnikiem ekranu, powiększeniem i zmianą układu;
• test pełnych scenariuszy z udziałem użytkowników, gdy wpływ jest istotny;
• kontrola dokumentów, multimediów, wiadomości i pomocy technicznej;
• ponowny test po poprawkach oraz po zmianie wspólnych komponentów.

06

Rekomendacja WEBee: naprawiaj według wpływu, nie liczby błędów

Raport nie powinien być eksportem ze skanera. Każdy problem potrzebuje ścieżki odtworzenia, wskazania użytkowników dotkniętych barierą, kryterium odniesienia, dowodu, zalecenia oraz właściciela. Priorytet nadaje się według blokowania procesu, częstotliwości komponentu i ryzyka, a nie wyłącznie według etykiety „critical” w narzędziu.

Najpierw usuń bariery, które uniemożliwiają wykonanie podstawowego zadania: niedostępne logowanie, pułapkę klawiaturową, brak etykiet pól, niewidoczny fokus, niedostępny dokument lub błąd bez jasnej instrukcji. Poprawka w bibliotece wspólnych komponentów zwykle daje większy efekt niż osobne łatki na wielu ekranach.

07

Rekomendacja WEBee: włącz dostępność do procesu wytwarzania

Jednorazowy audyt szybko traci aktualność. Wymagania powinny wejść do definicji ukończenia, biblioteki komponentów, kryteriów akceptacji, przeglądu projektu i testów regresji. Przy każdej większej zmianie warto sprawdzić nie tylko kod, ale także tekst, kolejność kroków, dokumenty i komunikację wsparcia.

Utrzymuj rejestr decyzji i wyjątków, wyniki testów, plan napraw oraz daty ponownej oceny. Informacja dla użytkownika powinna uczciwie opisywać dostępność właściwej usługi i kanał zgłoszenia problemu. Nie zastępuje naprawy, ale pozwala obsłużyć barierę i zebrać dane do dalszych ulepszeń.

WEBee może połączyć audyt strony lub aplikacji z backlogiem technicznym, poprawą komponentów, testami odbiorczymi i planem kolejnych wydań. Dzięki temu dostępność staje się mierzalnym elementem jakości produktu, a nie dokumentem przygotowanym dopiero po wdrożeniu.