Dostępność cyfrowa przestała być tematem jedynie dla specjalistów od dostępności – od czerwca 2025 r. to wymóg prawny, który dotyka też e-commerce i usług cyfrowych w sektorze prywatnym. Jednocześnie ponad 94% stron w internecie wciąż nie spełnia podstawowych kryteriów WCAG, a średnia strona główna zawiera ponad 50 wykrywalnych błędów dostępności. Ten artykuł to kompaktowy przewodnik po tym, czym jest WCAG, kogo obowiązuje w Polsce, jakie błędy pojawiają się najczęściej – i jak się za to zabrać, żeby nie skończyć z kolejnym raportem audytowym pełnym czerwonych flag!

Czym jest dostępność cyfrowa?

Dostępność cyfrowa oznacza, że strony i aplikacje są zaprojektowane tak, by mogły z nich wygodnie korzystać wszystkie osoby, także z niepełnosprawnościami (wzrok, słuch, ruch, zaburzenia poznawcze). To standard jakości wymagany w materiałach rządowych i wytycznych WCAG.

Chodzi o realne scenariusze: obsługę klawiaturą zamiast myszy, wsparcie czytników ekranu, powiększanie treści oraz alternatywy dla dźwięku i obrazu. Wymaga to poprawnych nagłówków, etykiet pól, napisów do wideo, intuicyjnej nawigacji i unikania migotania.

Dostępność to nie dodatek — to podstawowa cecha rozwiązań cyfrowych, a nie jedynie kontrast czy większa czcionka. Zastosowana poprawnie, przynosi korzyści także osobom starszym, użytkownikom mobilnym i tym uczącym się języka.

Czym jest standard WCAG i jak działa?

WCAG co to? To skrót od Web Content Accessibility Guidelines, czyli zbioru wytycznych, jak tworzyć dostępne treści i interfejsy w internecie. WCAG jest rozwijany i publikowany przez  w ramach obszaru standardów dostępności (WAI). 

WCAG ma strukturę „od ogółu do szczegółu”: na wysokim poziomie są zasady i wytyczne, a punktem kontrolnym w praktyce są testowalne kryteria sukcesu (success criteria). Kryteria te mają trzy poziomy zgodności: A / AA / AAA – w zależności od badanego zagadnienia i kontekstu.

Warto rozumieć jeszcze jedną rzecz: wersje. Przez lata „bazową” wersją był WCAG 2.0, potem 2.1, a obecnie standard W3C rozwija się dalej (WCAG 2.2 jest wskazywany jako aktualna wersja w materiałach W3C; jednocześnie różne obowiązki prawne mogą odnosić się do określonej wersji poprzez normy i harmonizację). 

W kontekście europejskim ma to znaczenie: w materiałach Komisji dotyczących standardów dla dyrektywy o dostępności stron sektora publicznego podkreśla się, że nowe wersje WCAG lub EN 301 549 nie zmieniają automatycznie obowiązków prawnych – zmiana ma znaczenie dopiero po aktualizacji standardu i jego odniesieniu w Dzienniku Urzędowym UE (Official Journal). 

Cztery zasady dokumentu WCAG w ludzkim języku - wytyczne WCAG 2.2

WCAG opiera się na 4 zasadach (często określanych skrótem POUR). Definicje tych zasad są opisane w dokumentach W3C, a polskie materiały rządowe używają ich odpowiedników językowych: postrzegalność, funkcjonalność, zrozumiałość i kompatybilność/solidność. 

  1. Postrzegalność (Perceivable): użytkownik musi móc odebrać treść – wzrokiem, słuchem, dotykiem lub przez technologie asystujące. W praktyce: tekst alternatywny do obrazów, napisy do wideo, sensowna struktura treści, możliwość powiększenia bez utraty czytelności. 

  2. Funkcjonalność (Operable): użytkownik musi móc obsłużyć interfejs różnymi metodami – np. klawiaturą. W praktyce: wszystko osiągalne tabulatorem, brak pułapek klawiaturowych, logiczna kolejność fokusu, „przejdź do treści”. 

  3. Zrozumiałość (Understandable): treść i sposób działania interfejsu mają być zrozumiałe i przewidywalne. W praktyce: jasne komunikaty błędów, spójna nawigacja i nazewnictwo, czytelny język. 

  4. Solidność / kompatybilność (Robust): rozwiązanie ma działać „trwale” – poprawnie w przeglądarkach i z technologiami asystującymi (dziś i jutro). W praktyce: semantyczny HTML, poprawne role/nazwy elementów, ostrożne i poprawne użycie ARIA. 

Kogo dotyczy dostępność cyfrowa w Polsce i jakie są obowiązki?

W Polsce trzeba rozdzielić dwa duże „światy”: podmioty publiczne (obowiązek od lat) oraz część biznesu (obowiązki, które weszły w życie wraz z implementacją Europejskiego Aktu o Dostępności).

Podmioty publiczne: obowiązek ustawowy + deklaracja dostępności

Polskie przepisy wdrażają unijną dyrektywę o dostępności cyfrowej stron internetowych i aplikacji publicznych; wymagania w załączniku odpowiadają WCAG na poziomie AA (z pewnymi ograniczeniami).

Terminy: strony od 23 września 2020 r., aplikacje mobilne od 23 czerwca 2021 r.

Zakres: jednostki sektora finansów publicznych, państwowe jednostki organizacyjne, podmioty finansowane/nadzorowane przez sektor publiczny, ich związki oraz wybrane organizacje pozarządowe działające na rzecz zdrowia, osób z niepełnosprawnościami i seniorów.

Praktyka: obowiązek może obejmować także intranety/extranety (z osobną deklaracją); niektóre treści są wyłączone (np. transmisje na żywo, starsze dokumenty, mapy) przy zapewnieniu alternatywnego dostępu do danych.

Egzekwowanie: nadzór i audyty prowadzi minister właściwy ds. cyfryzacji; możliwe są kary finansowe - do 10 000 zł za naruszenia serwisu/aplikacji i do 5 000 zł za problemy z deklaracją dostępności.

Dostęp dla użytkowników: każdy może zgłosić żądanie zapewnienia dostępności; podmiot publiczny musi odpowiedzieć niezwłocznie, zasadniczo w ciągu maks. 7 dni, zapewniając dostępność lub alternatywny sposób korzystania. W przypadku odmowy lub braku reakcji wnioskodawca może złożyć skargę do organu nadzorczego (w Polsce – do ministra właściwego ds. informatyzacji). Konsekwencje dla podmiotu mogą obejmować m.in. nakaz zapewnienia dostępności, a w przypadku podmiotów objętych ustawą o dostępności cyfrowej – również kary finansowe.

Biznes: rosnące wymagania wynikające z EAA i polskiego PAD

Od 28 czerwca 2025 r. dostępność stała się wymogiem prawnym także dla części rynku prywatnego poprzez implementację Europejskiego Aktu o Dostępności (EAA).

EAA ma ujednolicić wymagania dostępności dla kluczowych produktów i usług, eliminując rozbieżne przepisy i tworząc wspólne zasady rynku wewnętrznego.

W katalogu objętych obszarów są m.in. komputery i systemy operacyjne, smartfony, bankomaty, automaty biletowe, usługi telekomunikacyjne, bankowość, e-booki i e-commerce.

Polskie regulacje definiują usługi handlu elektronicznego jako świadczone na odległość przez strony i aplikacje mobilne w celu zawarcia umowy; obejmują szeroką gamę sprzedaży online, choć przewidziano wyłączenia (np. mikroprzedsiębiorcy, niektóre elementy jak mapy przy alternatywnym dostępie, treści poza kontrolą podmiotu).

Nadzór nad dostępnością usług e‑handlu prowadzi minister właściwy ds. cyfryzacji oraz instytucje takie jak PFRON, organy nadzoru rynku i organy celne; branżowe przewodniki wskazują konkretne zastosowania nowych wymagań.

Firmy pracujące dla sektora publicznego

Nawet jeśli sama firma nie jest „podmiotem publicznym”, bardzo często w praktyce musi dostarczać rozwiązania zgodne z standardem WCAG, jeśli buduje serwisy/aplikacje dla instytucji publicznych. Powód jest prosty: to instytucja publiczna odpowiada za zgodność swoich serwisów z wymaganiami ustawowymi równoważnymi WCAG AA, więc będzie to przenosić na wykonawcę (umową, odbiorem, wymaganiami w przetargu). 

Małe i średnie firmy: „brak obowiązku” ≠ „brak ryzyka”

W części przypadków (np. mikroprzedsiębiorca świadczący usługi) przepisy mogą przewidywać wyłączenia, ale to nie oznacza, że temat znika. Po pierwsze: firma może szybko „wyrosnąć” z definicji mikroprzedsiębiorstwa i wtedy – jak pokazują analizy prawne dotyczące EAA – nie warto budować strategii na wyłączeniu, bo ono jest kruche i może wymagać ponownej oceny wraz ze zmianą skali działalności.  Po drugie: nawet bez bezpośredniego obowiązku, dostępność to realny wpływ na sprzedaż, koszty obsługi i wizerunek (o tym szerzej poniżej). 

Dlaczego dostępność cyfrowa ma znaczenie dla biznesu?

Dostępność cyfrowa bywa błędnie postrzegana jako „temat niszowy”, ale dane demograficzne temu przeczą.

Na poziomie globalnym  szacuje, że około 1,3 mld ludzi doświadcza znaczącej niepełnosprawności (ok. 16% populacji, czyli 1 na 6 osób).  W Unii Europejskiej  wskazuje, że w 2024 r. 23,9% osób w wieku 16+ zgłaszało długotrwałe ograniczenia aktywności (co w statystyce Eurostat jest ujmowane jako „disability / activity limitation”).  Równolegle trend starzenia jest jednoznaczny: WHO prognozuje, że do 2030 r. 1 na 6 osób na świecie będzie miała 60+ lat. 

Z perspektywy biznesu to nie tylko „większy rynek”, ale też zwyczajnie mniej tarcia w ścieżce użytkownika. Rządowe materiały o dostępności zwracają uwagę, że rozwiązania dostępne cyfrowo działają sprawniej na urządzeniach mobilnych i „łatwiej będzie je odnaleźć wyszukiwarkom internetowym”.  To jest dobry skrót myślowy: dostępność bardzo często idzie w parze z uporządkowaną treścią, przewidywalnym interfejsem i lepszą jakością implementacji.

Przykład czysto biznesowy: porzucone formularze. Jeśli formularz nie ma prawidłowych etykiet albo nie informuje czytelnie o błędach, część użytkowników nie kończy procesu (a część nie jest w stanie go w ogóle przejść). Skala problemu nie jest hipotetyczna – badanie top 1 000 000 stron (patrz niżej) pokazuje, że brak etykiet pól formularzy to jedna z najczęstszych barier. 

Do tego dochodzi „bezpieczeństwo prawne” w czasie: logika unijnych i polskich regulacji idzie w stronę rozszerzania dostępności poza administrację publiczną. Widać to wprost w opisach EAA: dostępność ma stać się „normą” także w przedsiębiorstwach i ich usługach/produktach. 

Najczęstsze bariery i błędy na stronach niezgodnych z WCAG

Żeby ta sekcja była maksymalnie praktyczna, warto oprzeć się o dane. Coroczny raport „The WebAIM Million” oparty o automatyczną analizę 1 000 000 stron głównych. W edycji 2025 raport wskazuje m.in., że wykryto ponad 50,9 mln błędów (średnio 51 na stronę), a 94,8% stron miało wykrywalne naruszenia WCAG 2 (A/AA) – przy czym raport wyraźnie podkreśla ograniczenia automatycznych testów. 

Najczęściej wykrywane typy błędów (w 2025 r.) skupiają się w kilku „klasykach” – i to świetnie pasuje do checklist, featured snippets i lead magnetów. 

  1. Zbyt niski kontrast tekstu: najczęstszy problem (79,1% stron głównych). WCAG 2.1 dla poziomu AA wymaga co do zasady kontrastu min. 4,5:1 dla tekstu oraz 3:1 dla dużego tekstu (z wyjątkami). 

  2. Brak tekstu alternatywnego dla obrazów (55,5% stron głównych): bez tego użytkownik czytnika ekranu nie dostaje informacji „co jest na grafice/ikonie”, a w przypadku obrazów-linków powstają linki bez sensownej nazwy. 

  3. Brak etykiet pól formularzy (48,2% stron głównych): to wprost uderza w możliwość zrozumienia, co wpisać i gdzie; a przy technologiach asystujących bywa barierą krytyczną. 

  4. Puste linki (45,4%) i puste przyciski (29,6%): elementy klikalne bez czytelnej nazwy są dezorientujące i nieweryfikowalne przy nawigacji klawiaturą/czytnikiem. 

  5. Brak zdefiniowanego języka dokumentu (15,8%): czytniki ekranu i narzędzia językowe mogą wtedy czytać treść niewłaściwą „wymową/akcentem”, a hybrydowe treści wielojęzyczne robią się trudniejsze do obsłużenia. 

  6. Nielogiczna struktura nagłówków (np. przeskakiwanie poziomów): raport wskazuje, że nagłówki są kluczowym mechanizmem nawigacji dla użytkowników czytników, więc ich poprawne wdrożenie ma duże znaczenie. 

  7. Brak obsługi klawiatury / pułapki klawiaturowe: w polskim skrócie WCAG 2.1 rząd wprost wskazuje „możliwość obsłużenia wszystkiego za pomocą samej klawiatury” jako element zasady funkcjonalności. 

Warto zapamiętać jeszcze jedną rzecz z tych danych: 96% wykrytych błędów automatycznych wpada właśnie do tych sześciu kategorii – czyli naprawienie „najbardziej typowych” problemów może przynieść bardzo duży efekt, nawet zanim wejdzie się w trudniejsze przypadki. 

Jak sprawdzić, czy strona spełnia WCAG i co daje audyt?

Testowanie dostępności zawsze warto rozumieć jako „warstwy”: automaty + manual + proces audytu.

Narzędzia automatyczne: szybki start, ale nie wyrok

Automatyczne skanery (np. WAVE, Lighthouse, axe i inne) są przydatne, bo szybko pokazują część problemów. Ale kluczowe jest ograniczenie: raport WebAIM oparty o analizę automatyczną sam podkreśla, że automatyczne narzędzia mają ograniczenia i „brak wykrytych błędów nie oznacza dostępności”. 

To samo mocno wybrzmiewa w praktyce audytowej rządu brytyjskiego: automatyczne narzędzia są pomocne, ale „żadne narzędzie nie wykryje każdej bariery”, a wyniki mogą wymagać interpretacji lub bywać błędne – dlatego powinny być łączone z testami manualnymi. 

Jeśli chcesz to spiąć ze światem „jakości strony” (a nie tylko dostępności),  Lighthouse jest wygodny, bo raportuje kilka obszarów jednocześnie (performance, accessibility, best practices, SEO). 

Testy manualne: tu wychodzą blokery

Najprostszy manualny test, który realnie wykrywa twarde bariery:

  • Test klawiaturą (bez myszy): czy da się przejść przez menu, znaleźć CTA, wypełnić formularz, zaakceptować zgody, dokończyć zakup? To jest dokładnie to, co polskie materiały podają jako przykład zasady funkcjonalności. 

  • Test powiększenia / responsywności: WCAG 2.1 (AA) wymaga, aby tekst dało się powiększyć do 400% bez utraty treści lub funkcjonalności (z wyjątkami). 

  • Test struktury treści: czy nagłówki są logiczne i opisowe? To pomaga zarówno dostępności, jak i orientacji w treści. WebAIM opisuje, że użytkownicy czytników ekranu opierają nawigację na semantycznej strukturze, a nagłówki są używane również przez wyszukiwarki do określania tematu strony. 

Audyt dostępności: kiedy „wstępne testy” to za mało

Pełny audyt WCAG to zwykle połączenie: wyboru reprezentatywnych widoków/procesów, testów manualnych, testów z technologiami asystującymi oraz mapowania problemów na konkretne kryteria sukcesu i rekomendacje wdrożeniowe. W3C publikuje metodykę WCAG-EM (Website Accessibility Conformance Evaluation Methodology) – to dobry, uporządkowany punkt odniesienia „jak robić ocenę zgodności”. 

Sedno (i rzecz, którą warto mocno podkreślać w komunikacji): żadne narzędzie online nie zastąpi pełnego audytu WCAG – bo nie zobaczy wszystkiego, co jest zależne od kontekstu, treści, procesów i zachowań użytkownika. 

Wymogi WCAG a SEO: gdzie naprawdę się łączy?

WCAG nie jest „algorytmem SEO”, ale w praktyce spora część dobrych praktyk dostępności poprawia to, jak roboty wyszukiwarek rozumieją stronę i jak użytkownik się po niej porusza.

Najbardziej namacalne punkty styku:

  • Semantyka HTML i nagłówki. WebAIM wprost opisuje, że nagłówki tworzą „outline” strony, są kluczowe dla nawigacji czytników ekranu i są wykorzystywane również przez wyszukiwarki do określania treści strony. 

  • Tekst alternatywny obrazów. W wytycznych Google dla obrazów jest jasno powiedziane, że alt text poprawia dostępność (dla osób niewidzących lub przy niskiej przepustowości) i jednocześnie pomaga Google zrozumieć temat obrazu (Google używa alt text wraz z innymi sygnałami). 

  • Linki i ich opisowość. Dokumentacja Google dla deweloperów podkreśla, że linki powinny być „crawlable” i że tekst linku (albo alt w przypadku obrazu będącego linkiem) jest sygnałem opisującym stronę docelową. 

  • Page experience / Core Web Vitals. Google opisuje, że systemy rankingowe szukają sygnałów zgodnych z dobrą jakością doświadczenia strony (page experience), a Core Web Vitals to zestaw metryk UX (ładowanie, interaktywność, stabilność). Jednocześnie jest też ważne zastrzeżenie: dobre wyniki w raportach nie gwarantują topowych pozycji – to tylko część większego obrazu. 

W praktyce biznesowej to spina się bardzo prosto: dostępność wymusza porządek w treści i interfejsie, a porządek zwykle pomaga i użytkownikom, i robotom. Rządowe materiały o dostępności publicznych serwisów wręcz wskazują, że dostępność sprzyja sprawniejszemu działaniu na mobile i łatwiejszemu odnajdywaniu przez wyszukiwarki. 

Poziomy dostępności WCAG i praktyczny plan wdrożenia

Czy każda strona musi mieć standard dostępności „zgodny z WCAG”?

WCAG ma trzy poziomy zgodności: A, AA i AAA.  W polskich objaśnieniach prawa wymagania ustawowe dla podmiotów publicznych są opisane jako równoważne wytycznym WCAG na poziomie AA (z niewielkimi ograniczeniami), co oznacza spełnienie kryteriów zarówno na poziomie A, jak i AA. W audytach natomiast zakres badanych kryteriów może być szerszy i obejmować również poziom AAA.

Poziom AAA bywa kosztowny i trudny do utrzymania dla całych serwisów. W3C w materiałach o zgodności wprost wskazuje, że nie rekomenduje się wymagania poziomu AAA dla całych stron jako ogólnej polityki (m.in. ze względu na to, że nie wszystkie treści da się sensownie dostosować do AAA w każdym kontekście). 

Co więcej, polskie prawo dla podmiotów publicznych opisuje też katalog elementów, które nie muszą być dostępne „wprost” (np. media na żywo, część archiwalnych dokumentów, mapy z warunkiem alternatywnego dostępu), a mimo to wskazuje obowiązek zapewnienia alternatywnego dostępu do informacji. 

W modelu PAD (dla e-handlu) wprost pojawiają się mechanizmy wyjątków (np. zasadnicza zmiana podstawowych właściwości usługi albo nieproporcjonalne obciążenie), ale z istotnym warunkiem: trzeba to ocenić, udokumentować i w określonych sytuacjach poinformować organ (np. ministra właściwego ds. cyfryzacji). 

Wniosek praktyczny: dostępność to proces zarządzania jakością i ryzykiem – a nie jednorazowy checkbox „zrobione”.

Jak przygotować stronę zgodną z WCAG? Kryterium sukcesu w 2026

Poniżej plan wdrożeniowy, który jest spójny zarówno z logiką WCAG (zasady i kryteria), jak i z tym, jak państwo opisuje obowiązki i nadzór (dla podmiotów publicznych oraz e-handlu).

Ustal cel zgodności i zakres

Co dokładnie ma być dostępne (np. cały serwis, wybrane ścieżki: rejestracja, kontakt, koszyk, płatność). W sektorze publicznym punktem odniesienia jest WCAG na poziomie AA (z niewielkimi ograniczeniami) oraz deklaracja dostępności. 

Zacznij od UX/UI, nawigacji i design systemu

  • kontrast (min. 4,5:1 dla tekstu w AA; 3:1 dla dużego tekstu), 

  • stany fokusu (czy użytkownik widzi, gdzie jest), 

  • komponenty formularzy z etykietami i walidacją, 

  • „przejdź do treści” i logiczna nawigacja. 

Poprawny HTML i semantyka

To fundament „solidności/kompatybilności”. W praktyce oznacza to m.in. logiczną strukturę nagłówków i relacji w treści formularzy/tabel. 

Dostępności treści i multimediów

Zdjęcia i grafiki z sensownymi altami, multimedia z napisami/transkrypcjami, treści nieoparte wyłącznie o kolor. To są elementy, które są wymieniane w polskich skrótach WCAG jako praktyki prowadzące do postrzegalności i funkcjonalności. 

Testy na każdym etapie

  • automaty (szybko wykryją część problemów), ale z pełną świadomością ograniczeń, 

  • manual (klawiatura, powiększenie, struktura treści), 

  • w kluczowych procesach – audyt wg metodyki (np. WCAG-EM). 

Dokumentacja i transparentność

  • w sektorze publicznym: deklaracja dostępności i obsługa żądań/skarg w określonych terminach, 

  • w e-handlu (PAD): obowiązki informacyjne wobec konsumenta (m.in. jak usługa spełnia wymagania dostępności – w regulaminie lub dokumencie równoważnym) oraz mechanizm informowania organu w razie niespełnienia wymagań i opisu działań naprawczych. 

Utrzymanie

Po wdrożeniu – ciągłość. Każda nowa funkcja, kampania, zmiana CMS-a czy redesign może wprowadzić regres. Dane z raportów typu WebAIM Million sugerują zresztą, że powtarzalne błędy wracają masowo – co pokazuje wagę procesowego podejścia, a nie „jednego sprintu”.