WCAG na stronie firmowej - co naprawdę musisz zrobić

Przez lata dostępność cyfrowa była w Polsce tematem urzędów. Ustawa z 2019 roku nałożyła obowiązek na podmioty publiczne, te wrzuciły na strony deklaracje dostępności i temat zamknięto. Od 28 czerwca 2025 roku sytuacja jest inna: część obowiązków przeszła na firmy prywatne, a razem z nimi realne kary i kontrole.

Problem w tym, że wokół tematu narosło sporo mitów. Że wystarczy wtyczka. Że dotyczy wszystkich. Że trzeba wdrożyć WCAG 2.2. Poniżej rozdzielam to, co wiąże prawnie, od tego, co po prostu warto zrobić, i pokazuję, co konkretnie sprawdzić na własnej stronie.

Co właściwie wiąże prawnie

Łańcuch przepisów wygląda tak. Unijna dyrektywa 2019/882, znana jako Europejski akt o dostępności, została wdrożona do polskiego prawa ustawą z 26 kwietnia 2024 roku o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze. Ustawa obowiązuje od 28 czerwca 2025 roku.

Sama ustawa nie mówi jednak „zrób WCAG”. Odsyła do norm zharmonizowanych, a dla usług cyfrowych jest nią europejska norma EN 301 549. I tu jest niuans, który większość artykułów w polskim internecie gubi: obowiązującą wersją tej normy jest V3.2.1 z 2021 roku, a ona odwołuje się do WCAG 2.1 na poziomie AA, nie do 2.2. Prace nad nowszą wersją normy trwają, ale dopóki nie zostanie ona opublikowana i zharmonizowana, punktem odniesienia przy kontroli jest WCAG 2.1 AA.

Czy to znaczy, że WCAG 2.2 można zignorować? Nie. WCAG 2.2 jest nadzbiorem 2.1: dokłada dziewięć nowych kryteriów i wycofuje jedno przestarzałe. Robiąc od razu 2.2, spełniasz 2.1 z zapasem i nie będziesz musiał wracać do tematu, gdy norma zostanie zaktualizowana. To po prostu tańsze niż robienie tego dwa razy.

Kogo to realnie dotyczy

Ustawa nie objęła wszystkich firm z internetem. Lista usług jest zamknięta i obejmuje między innymi:

• handel elektroniczny, czyli sklepy internetowe i wszystko, gdzie klient zawiera umowę online,
• bankowość detaliczną,
• dystrybucję e-booków,
• transport pasażerski, w tym sprzedaż biletów,
• usługi telekomunikacyjne i audiowizualne.

Poza listą jest jeszcze jedno duże wyłączenie: mikroprzedsiębiorcy świadczący usługi. Mikroprzedsiębiorca w rozumieniu Prawa przedsiębiorców to firma, która zatrudnia średniorocznie mniej niż 10 osób i której roczny obrót lub suma bilansowa nie przekracza równowartości 2 milionów euro. Jednoosobowa działalność prowadząca mały sklep na WooCommerce najczęściej mieści się w tej definicji.

Wniosek praktyczny: jeśli prowadzisz stronę wizytówkową firmy usługowej, ustawa Cię nie dotyczy. Jeśli prowadzisz sklep internetowy i przekroczyłeś próg mikroprzedsiębiorcy, dotyczy Cię od czerwca 2025 roku. Jeśli sprzedajesz do instytucji publicznych, dostępność i tak pojawi się w wymaganiach przetargowych, niezależnie od tego, w której grupie jesteś.

Cztery zasady, na których stoi cały standard

WCAG wygląda na ogromny dokument, ale w środku ma prostą konstrukcję. Wszystkie kryteria są przypisane do czterech zasad, opisywanych skrótem POUR. Strona ma być postrzegalna, funkcjonalna, zrozumiała i solidna technicznie.

Ten podział jest praktyczny, bo od razu podpowiada, gdzie szukać błędu. Nie widać tekstu na tle? To postrzegalność. Nie da się przejść formularza tabulatorem? To funkcjonalność. Komunikat błędu brzmi „error 422”? To zrozumiałość. Czytnik ekranu gubi się w kodzie? To solidność.

Co sprawdzić na własnej stronie w godzinę

Poniższe punkty to nie cała lista kryteriów WCAG, tylko te miejsca, w których realnie widzę błędy na stronach firmowych. Można je sprawdzić bez specjalistycznych narzędzi.

1. Kontrast tekstu

Minimum na poziomie AA to 4,5:1 dla zwykłego tekstu i 3:1 dla dużego, czyli od 24 pikseli albo 19 pikseli pogrubionych. Ta sama granica 3:1 dotyczy elementów interfejsu: obramowań pól formularza, ikon niosących znaczenie, granic przycisków. Najczęstszy grzech to jasnoszary tekst na białym tle, wybrany dlatego, że „wygląda elegancko”. Sprawdzisz to w narzędziach deweloperskich przeglądarki albo w dowolnym kalkulatorze kontrastu.

2. Widoczny fokus

Przejdź stronę tabulatorem od góry do dołu. Każdy element, na który wchodzisz, musi być wyraźnie zaznaczony. Jeśli w kodzie znajdziesz outline: none bez podania własnego stylu fokusu, to jest to błąd, i to jeden z najczęstszych. WCAG 2.2 dokłada tu kryterium mówiące, że fokus nie może być zasłonięty przez przyklejony nagłówek albo baner cookies.

3. Nawigacja samą klawiaturą

Odłóż mysz i spróbuj wykonać na stronie to, po co przychodzi klient: rozwinąć menu, otworzyć zakładkę, wysłać formularz, zamknąć modal. Typowe pułapki to menu rozwijane wyłącznie na najechanie kursorem, karuzele bez sterowania i okna modalne, z których nie da się wyjść klawiszem Escape.

4. Opisy alternatywne obrazów

Każdy obraz niosący treść potrzebuje opisu w atrybucie alt. Obrazy czysto dekoracyjne mają mieć alt="", czyli pusty, i to jest poprawne, a nie brakujące. Największy błąd to opisy w rodzaju „obrazek1” albo upychanie w nich słów kluczowych, co szkodzi i użytkownikowi, i pozycjonowaniu.

5. Hierarchia nagłówków

Jeden H1 na stronie, potem H2, potem H3, bez przeskoków i bez używania nagłówków po to, żeby coś było większe. Osoba korzystająca z czytnika ekranu nawiguje po stronie właśnie nagłówkami, tak jak Ty skanujesz stronę wzrokiem.

6. Formularze z prawdziwymi etykietami

Każde pole potrzebuje elementu label powiązanego z polem, a nie samego placeholdera. Placeholder znika w momencie, gdy użytkownik zaczyna pisać, więc osoba, która się rozproszy, traci informację, co wpisywała. Komunikaty błędów muszą mówić, co jest nie tak i jak to naprawić, oraz być powiązane z polem, którego dotyczą.

7. Rozmiar celów dotykowych

WCAG 2.2 wprowadza minimum 24 na 24 piksele dla elementów klikalnych. Wytyczne projektowe Apple i Google mówią o 44 i 48 pikselach i to jest lepszy punkt odniesienia. Najczęściej przewijają się tu małe ikony w stopce i krzyżyki zamykające wyskakujące okna.

8. Język strony i tytuły

Atrybut lang="pl" w znaczniku html to jedna linijka, o której zaskakująco często się zapomina. Bez niej syntezator mowy przeczyta polski tekst z angielską wymową. Każda podstrona potrzebuje też unikalnego, sensownego tytułu.

Dlaczego nakładki dostępności nie rozwiązują problemu

Na rynku jest cała kategoria produktów obiecujących zgodność z WCAG po wklejeniu jednej linijki skryptu. Dokładają one na stronę pływający przycisk z opcjami powiększenia tekstu, zmiany kontrastu i podświetlenia linków.

Problem polega na tym, że te opcje dubluje każda przeglądarka i każdy system operacyjny, a osoby faktycznie korzystające z technologii asystujących mają własne, dopracowane narzędzia. Nakładka nie naprawia natomiast niczego, co decyduje o zgodności: nie doda sensownego opisu alternatywnego do zdjęcia, nie naprawi kolejności nagłówków, nie sprawi, że formularz da się wypełnić z klawiatury. Audyt sprawdza kod strony, a nie obecność widgetu. Warto o tym wiedzieć, zanim wyda się kilka tysięcy złotych rocznie na abonament, który daje poczucie bezpieczeństwa zamiast bezpieczeństwa.

Dostępność opłaca się także poza zgodnością

Nawet jeśli ustawa Cię nie obejmuje, większość wymagań WCAG pokrywa się z tym, co i tak poprawia wyniki strony. Poprawny kontrast to czytelność na telefonie w słońcu. Sensowne nagłówki i opisy alternatywne to materiał, z którego korzysta Google i modele językowe budujące odpowiedzi. Formularz z prawdziwymi etykietami i czytelnymi błędami po prostu ma wyższą skuteczność. Nawigacja klawiaturą to zysk dla każdego, kto pracuje szybko.

To samo myślenie opisałem szerzej w tekście o łączeniu SEO i UX: dostępność jest po prostu kolejną warstwą tej samej jakości technicznej, a nie osobnym projektem obok.

Czym to sprawdzić i czego narzędzia nie wykryją

Kolejność jest ważna, bo narzędzia różnią się tym, ile fałszywego spokoju potrafią dać.

Lighthouse, wbudowany w Chrome, ma zakładkę Accessibility i jest dobrym punktem startu, bo nie wymaga instalacji niczego. Jego wynik procentowy bywa jednak mylący: strona z oceną 100 potrafi być całkowicie nieużywalna z klawiatury, bo Lighthouse sprawdza tylko część kryteriów i tylko to, co da się ocenić automatycznie.

axe DevTools i WAVE to rozszerzenia do przeglądarki, które pokazują konkretne elementy z błędami zamiast ogólnego wyniku. Przy poprawianiu strony są wygodniejsze, bo od razu prowadzą do miejsca w kodzie.

Najważniejsza rzecz do zapamiętania: narzędzia automatyczne wykrywają w praktyce około jednej trzeciej problemów. Wykryją brakujący atrybut alt, ale nie ocenią, czy jego treść ma sens. Wykryją zbyt niski kontrast, ale nie zauważą, że kolejność tabulacji przeskakuje z nagłówka na stopkę i z powrotem. Nie sprawdzą, czy komunikat błędu w formularzu tłumaczy, co poprawić.

Dlatego po automacie zawsze wykonuję trzy testy ręczne, które zajmują kilkanaście minut i wyłapują większość reszty:

• Przejście całej strony tabulatorem, od pierwszego elementu do stopki, z próbą wykonania głównej akcji bez dotykania myszy.
• Powiększenie strony do 200 procent skrótem przeglądarki. Treść ma się przelewać, a nie znikać za krawędzią albo nachodzić na siebie.
• Przesłuchanie kluczowej podstrony czytnikiem ekranu. Na macOS jest to VoiceOver, uruchamiany skrótem Command i F5, na Windowsie darmowe NVDA. Pierwsze pięć minut jest niekomfortowe, ale nic tak szybko nie pokazuje, że nagłówki są w złej kolejności, a przycisk nazywa się „kliknij tutaj”.

Ile to kosztuje i od czego zależy

Przy stronie firmowej na kilkanaście podstron, zbudowanej na własnym kodzie albo porządnym motywie, doprowadzenie do WCAG 2.1 AA to zwykle od dwóch do pięciu dni roboczych. Największą część pochłania nie sama praca, tylko decyzje projektowe: zmiana palety, gdy firmowy jasnoszary nie spełnia kontrastu, albo przeprojektowanie menu, które działa wyłącznie na najechanie kursorem.

Koszt rośnie w trzech sytuacjach. Pierwsza to sklep, bo dochodzi koszyk, filtry i proces zakupowy, czyli najbardziej złożone interakcje w całym serwisie. Druga to strona zbudowana na przeciążonym kreatorze, gdzie ten sam element powtarza się w kilkunastu wariantach i każdy trzeba poprawić osobno. Trzecia to serwis z dużą liczbą starych treści, w których obrazy nie mają opisów, a nagłówki były używane do formatowania.

Odwrotnie działa to przy nowym projekcie. Dostępność wpięta w etap projektowania, na poziomie palety, typografii i komponentów, kosztuje praktycznie tyle samo co projekt bez niej. Płaci się dopiero za doklejanie jej do gotowego interfejsu.

Od czego zacząć

Zacznij od ustalenia, czy ustawa Cię obejmuje, bo to zmienia wagę tematu z „warto” na „trzeba”. Potem przejdź osiem punktów z tego tekstu na własnej stronie i wypisz, co się nie zgadza. Dopiero mając tę listę, ma sens rozmowa o kosztach, bo okazuje się zwykle, że połowa problemów to zmiany w arkuszu stylów i szablonie, a nie przebudowa serwisu.

Najczęstsze pytania

Czy WCAG obowiązuje każdą firmę w Polsce?

Nie każdą. Ustawa z 26 kwietnia 2024 roku obejmuje konkretne usługi: handel elektroniczny, bankowość detaliczną, e-booki, transport pasażerski, usługi telekomunikacyjne i audiowizualne. Zwykła strona wizytówkowa firmy budowlanej nie jest nią objęta. Wyłączeni są też mikroprzedsiębiorcy świadczący usługi, czyli firmy zatrudniające mniej niż 10 osób z obrotem do 2 milionów euro. Jeśli jednak prowadzisz sklep internetowy i przekraczasz próg mikroprzedsiębiorcy, obowiązek dotyczy Cię od 28 czerwca 2025 roku.

Który poziom WCAG jest wymagany: 2.1 czy 2.2?

Prawnie wiąże WCAG 2.1 na poziomie AA, bo taką wersję zawiera norma zharmonizowana EN 301 549 V3.2.1 z 2021 roku, obowiązująca do dziś. WCAG 2.2 to nadzbiór 2.1, więc wdrażając 2.2 spełniasz jednocześnie 2.1 i jesteś przygotowany na aktualizację normy, nad którą trwają prace. Artykuły, które piszą wprost, że prawo wymaga WCAG 2.2, upraszczają stan faktyczny.

Czy nakładka typu widget dostępności załatwia sprawę?

Nie. Nakładki dokładają na stronę pasek z powiększaniem tekstu i zmianą kontrastu, ale nie naprawiają struktury kodu: brakujących opisów alternatywnych, złej kolejności nagłówków, formularzy bez etykiet czy elementów niedostępnych z klawiatury. Audytor sprawdza kod, nie widget. W Stanach Zjednoczonych firmy z takimi nakładkami i tak są pozywane.

Ile trwa doprowadzenie zwykłej strony firmowej do WCAG 2.1 AA?

Przy stronie na kilkanaście podstron, budowanej na własnym kodzie lub porządnym motywie, to zwykle od dwóch do pięciu dni roboczych: audyt, poprawki kontrastu i fokusu, uzupełnienie opisów alternatywnych, przebudowa formularzy i nawigacji klawiaturą. Więcej czasu zajmują sklepy, bo dochodzi koszyk, filtry i proces zakupowy.