Przejdź do treści
WCAG i dostępność

Dostępność cyfrowa WCAG 2.1 w JST — co musisz wiedzieć

Czym jest WCAG 2.1 i dlaczego obowiązuje Twoją gminę?

WCAG (Web Content Accessibility Guidelines) to międzynarodowy standard dostępności treści internetowych opracowany przez W3C. Wersja 2.1, opublikowana w czerwcu 2018 r., rozszerza wcześniejszą wersję 2.0 o 17 nowych kryteriów — głównie dotyczących urządzeń mobilnych, osób słabowidzących i osób z zaburzeniami poznawczymi.

W Polsce WCAG 2.1 stał się wymogiem prawnym na mocy ustawy z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz.U. 2019 poz. 848, z późn. zm.). Ustawa implementuje dyrektywę Parlamentu Europejskiego 2016/2102.

Obowiązek dotyczy wszystkich podmiotów publicznych — gmin, powiatów, województw, urzędów, szkół, bibliotek, ośrodków pomocy społecznej, domów kultury i każdej innej jednostki organizacyjnej JST.

Podstawy prawne — co mówi ustawa?

Kogo obejmuje obowiązek?

Art. 2 ustawy wymienia podmioty zobowiązane. Dla sektora samorządowego są to m.in.:

Terminy wejścia w życie

Typ strony Termin Status (2025)
Nowe strony (opublikowane po 23.09.2018) 23 września 2019 Obowiązuje
Istniejące strony (opublikowane przed 23.09.2018) 23 września 2020 Obowiązuje
Aplikacje mobilne 23 czerwca 2021 Obowiązuje
Intranet/ekstranet (po przeprojektowaniu) 23 września 2019 Obowiązuje

Wszystkie terminy już minęły — jeśli strona Twojej gminy nie spełnia WCAG 2.1 AA, narusza prawo od co najmniej 4 lat.

Kary pieniężne

Art. 19 ustawy przewiduje kary nakładane przez Ministra Cyfryzacji po przeprowadzeniu monitoringu:

  • Do 10 000 PLN — za uporczywe niespełnianie wymagań dostępności cyfrowej (brak poprawy po wezwaniu)
  • Do 5 000 PLN — za brak lub nieprawidłową deklarację dostępności
  • Kary mogą być nakładane wielokrotnie w kolejnych cyklach monitoringu

Ministerstwo Cyfryzacji prowadzi monitoring od 2020 r. W 2023 r. skontrolowano ponad 500 stron JST — ponad 60% nie spełniało wymagań w co najmniej jednym kluczowym kryterium.

4 zasady WCAG — POUR

WCAG opiera się na 4 zasadach, od których akronim to POUR:

1. Perceivable (Postrzegalność)

Treści muszą być prezentowane tak, aby każdy użytkownik mógł je odebrać:

  • 1.1.1 Treść nietekstowa — każdy obraz, wykres, przycisk graficzny musi mieć tekst alternatywny (alt). Obrazy dekoracyjne: alt=”” (pusty)
  • 1.3.1 Informacja i relacje — struktura nagłówkowa (H1→H2→H3), tabele z nagłówkami, listy jako <ul>/<ol>
  • 1.4.3 Kontrast minimalny — tekst normalny: kontrast 4,5:1; tekst duży (≥18pt lub ≥14pt bold): kontrast 3:1
  • 1.4.4 Zmiana rozmiaru tekstu — strona musi być czytelna po powiększeniu do 200%
  • 1.4.10 Reflow (WCAG 2.1) — brak poziomego scrollowania przy szerokości 320px
  • 1.4.11 Kontrast elementów nietekstowych (WCAG 2.1) — kontrast 3:1 dla ikon, ramek formularzy, wykresów

2. Operable (Funkcjonalność)

Interfejs musi być obsługiwalny niezależnie od sposobu interakcji:

  • 2.1.1 Klawiatura — każda funkcja dostępna z klawiatury (Tab, Enter, Escape, strzałki)
  • 2.1.2 Brak pułapki klawiaturowej — użytkownik musi mieć możliwość opuszczenia każdego komponentu
  • 2.4.1 Pomiń bloki — link „Przejdź do treści” na początku strony
  • 2.4.3 Kolejność fokusa — logiczna sekwencja przechodzenia Tab-em
  • 2.4.7 Widoczny fokus — wyraźny obrys elementu aktywnego (nigdy outline: none bez zamiennika!)
  • 2.5.5 Rozmiar celu dotykowego (WCAG 2.1, AAA ale rekomendowany) — minimum 44×44 pikseli

3. Understandable (Zrozumiałość)

Treści i działanie interfejsu muszą być zrozumiałe:

  • 3.1.1 Język strony — atrybut lang=”pl” w tagu <html>
  • 3.1.2 Język fragmentu — obce wyrazy oznaczone odpowiednim atrybutem lang
  • 3.2.1 Po otrzymaniu fokusa — fokus nie powoduje nieoczekiwanych zmian kontekstu
  • 3.3.1 Identyfikacja błędu — formularze wskazują błędy tekstowo (nie tylko kolorem!)
  • 3.3.2 Etykiety lub instrukcje — pola formularzy z widocznymi etykietami (label)

4. Robust (Kompatybilność)

Treści muszą działać z różnymi technologiami wspomagającymi:

  • 4.1.1 Parsowanie — poprawny kod HTML (walidator W3C)
  • 4.1.2 Nazwa, rola, wartość — komponenty interaktywne z poprawnymi atrybutami ARIA
  • 4.1.3 Komunikaty o stanie (WCAG 2.1) — dynamiczne komunikaty dostępne dla czytników ekranu (aria-live)

Checklist audytu WCAG dla strony JST

Poniższa lista kontrolna obejmuje najczęstsze problemy występujące na stronach gmin i jednostek organizacyjnych:

Nagłówki i struktura

  • ☐ Jeden H1 na stronę
  • ☐ Nagłówki w kolejności hierarchicznej (brak przeskoków H2→H4)
  • ☐ Tytuł strony (tag <title>) opisowy i unikalny
  • ☐ Atrybut lang=”pl” na <html>
  • ☐ Semantyczny HTML: <nav>, <main>, <header>, <footer>, <aside>

Obrazy i multimedia

  • ☐ Każdy obraz informacyjny ma atrybut alt z opisem
  • ☐ Obrazy dekoracyjne mają alt=”” lub role=”presentation”
  • ☐ Filmy z napisami (closed captions)
  • ☐ Audiodeskrypcja dla filmów informacyjnych

Formularze

  • ☐ Każde pole z elementem <label> powiązanym przez for/id
  • ☐ Błędy opisane tekstowo (nie tylko kolor czerwony)
  • ☐ Wymagane pola oznaczone tekstem, nie tylko gwiazdką
  • ☐ Logiczna kolejność tabulacji

Nawigacja i interakcja

  • ☐ Link „Przejdź do treści głównej” (skip link)
  • ☐ Widoczny fokus na wszystkich elementach interaktywnych
  • ☐ Menu rozwijane obsługiwane klawiaturą
  • ☐ Brak pułapek klawiaturowych (modal, slider, mapa)

Kontrast i kolory

  • ☐ Tekst: kontrast ≥ 4,5:1
  • ☐ Tekst duży: kontrast ≥ 3:1
  • ☐ Informacja nie przekazywana wyłącznie kolorem
  • ☐ Linki odróżnialne od tekstu nie tylko kolorem (podkreślenie lub inny wskaźnik)

Dokumenty i załączniki

  • ☐ Pliki PDF dostępne (tagowany PDF, nie skan!)
  • ☐ Tabele w dokumentach z nagłówkami
  • ☐ Format pliku podany przy linku (np. „Uchwała nr XII/2024 (PDF, 245 KB)”)

Narzędzia do sprawdzania dostępności

Poniższe narzędzia są bezpłatne i pomagają wykryć najczęstsze błędy. Pamiętaj jednak, że żadne narzędzie automatyczne nie wykryje więcej niż 30-40% problemów — resztę trzeba sprawdzić ręcznie.

Narzędzie Typ Co sprawdza Koszt
WAVE (wave.webaim.org) Rozszerzenie przeglądarki / online Struktura, kontrast, alt, ARIA, formularze Bezpłatne
axe DevTools (Deque) Rozszerzenie przeglądarki WCAG 2.1 A/AA, automatyczne reguły Bezpłatne (wersja podstawowa)
Lighthouse (Google Chrome) Wbudowane w Chrome DevTools Accessibility score, podstawowe kryteria Bezpłatne
Colour Contrast Analyser (TPGi) Aplikacja desktop Kontrast kolorów (foreground/background) Bezpłatne
NVDA Czytnik ekranu (Windows) Testy ręczne z czytnikiem ekranu Bezpłatne
Pa11y CLI / CI/CD Automatyczne testy WCAG w pipeline Open source

Szczegółowe porównanie narzędzi: WAVE, axe i inne narzędzia audytu WCAG dla JST.

Deklaracja dostępności — co musi zawierać?

Każdy podmiot publiczny musi opublikować deklarację dostępności na swojej stronie (art. 10 ustawy). Wzór określa decyzja wykonawcza Komisji Europejskiej 2018/1523.

Obowiązkowe elementy deklaracji:

  1. Data publikacji strony i data ostatniej aktualizacji
  2. Status zgodności — „zgodna”, „częściowo zgodna” lub „niezgodna” z WCAG 2.1 AA
  3. Lista treści niedostępnych z podaniem przyczyny i planowanego terminu naprawy
  4. Data sporządzenia deklaracji i metoda oceny (samoocena / audyt zewnętrzny)
  5. Dane kontaktowe koordynatora dostępności (imię, nazwisko, email, telefon)
  6. Procedura skargowa — informacja o prawie złożenia skargi do Rzecznika Praw Obywatelskich
  7. Informacja o dostępności architektonicznej budynku urzędu

Deklarację należy przeglądać i aktualizować co najmniej raz w roku (do 31 marca) oraz po każdej znaczącej zmianie strony. Praktyczny poradnik: Jak napisać i opublikować deklarację dostępności.

Poziomy zgodności: A, AA, AAA

WCAG definiuje trzy poziomy zgodności:

  • Poziom A — minimum. 30 kryteriów sukcesu. Bez tego strona jest praktycznie niedostępna
  • Poziom AAwymagany przez polskie prawo. 20 dodatkowych kryteriów. Obejmuje kontrast 4,5:1, zmianę rozmiaru tekstu, widoczny fokus
  • Poziom AAA — najwyższy. 28 dodatkowych kryteriów. Nie jest wymagany prawnie, ale niektóre kryteria (jak rozmiar celu dotykowego 44×44px) są rekomendowane

Uwaga: ustawa wymaga poziomu AA, ale w przypadku treści multimedialnych (wideo, audio) i dokumentów PDF wymagania mogą sięgać poziomu AAA w niektórych interpretacjach. Szczegóły w artykule Ustawa o zapewnianiu dostępności — obowiązki JST.

Najczęstsze błędy WCAG na stronach JST

Na podstawie raportów Ministerstwa Cyfryzacji i audytów organizacji pozarządowych, najczęstsze problemy to:

  1. Brak tekstów alternatywnych obrazów — 73% skontrolowanych stron (dane MC 2023)
  2. Niewystarczający kontrast tekstu — szczególnie w stopce, menu, opisach zdjęć
  3. Niedostępne pliki PDF — skany dokumentów bez warstwy tekstowej (OCR)
  4. Brak skip linku — „Przejdź do treści głównej”
  5. Formularze bez etykiet — pola z samym placeholderem zamiast <label>
  6. Brak widocznego fokusa — outline: none w CSS bez alternatywy
  7. Nieoznaczony język strony — brak atrybutu lang=”pl”
  8. Mapy Google bez alternatywy tekstowej — iframe bez tytułu, brak adresu tekstowego
  9. Slajdery bez kontroli klawiaturą — karuzele zdjęć obsługiwane tylko myszą
  10. Deklaracja dostępności nieaktualna lub brak danych koordynatora

Koordynator dostępności — kto to jest?

Zgodnie z ustawą z dnia 19 lipca 2019 r. o zapewnianiu dostępności osobom ze szczególnymi potrzebami (Dz.U. 2019 poz. 1696), każdy organ administracji publicznej wyznacza koordynatora do spraw dostępności.

Obowiązki koordynatora:

  • Wsparcie osób ze szczególnymi potrzebami w dostępie do usług
  • Przygotowanie i aktualizacja planu działania na rzecz poprawy dostępności
  • Monitorowanie dostępności cyfrowej strony i BIP
  • Kontakt z mieszkańcami w sprawach barier dostępności

Więcej: Koordynator dostępności w JST — obowiązki i narzędzia.

Najczęściej zadawane pytania (FAQ)

Czy mała gmina wiejska też musi spełniać WCAG 2.1?

Tak. Ustawa o dostępności cyfrowej nie przewiduje wyjątków ze względu na wielkość gminy, liczbę mieszkańców ani budżet. Każdy podmiot publiczny — od gminy liczącej 2 000 mieszkańców po miasto stołeczne — musi spełniać WCAG 2.1 AA. Jedyny wyjątek dotyczy treści, których dostosowanie wiązałoby się z „nieproporcjonalnym obciążeniem” (art. 8 ustawy), ale wymaga to szczegółowego uzasadnienia w deklaracji dostępności.

Ile kosztuje audyt WCAG strony gminnej?

Audyt automatyczny (narzędzia WAVE, axe) — bezpłatny, ale wykrywa max 30-40% problemów. Profesjonalny audyt ręczny: od 2 000 PLN (mała strona, 5-10 podstron) do 8 000-12 000 PLN (rozbudowany portal z BIP i e-usługami). Audyt powinien obejmować testy z czytnikiem ekranu, nawigację klawiaturą i ocenę ekspertów. Warto uwzględnić ten koszt w budżecie projektu strony.

Czy nakładki dostępności (accessibility overlays) wystarczą?

Nie. Nakładki typu UserWay, AccessiBe czy EqualWeb nie zapewniają pełnej zgodności z WCAG 2.1 AA. Ministerstwo Cyfryzacji w swoich wytycznych jasno wskazuje, że „rozwiązania nadbudowujące się na istniejącą stronę nie zastępują jej właściwego zaprojektowania i zakodowania”. Nakładki mogą wręcz pogorszyć dostępność — np. konflikując z czytnikami ekranu. Jedyną skuteczną metodą jest poprawne zaprojektowanie i zakodowanie strony od podstaw.

Kto kontroluje dostępność stron JST?

Monitoring prowadzi Ministerstwo Cyfryzacji (Departament Społeczeństwa Informacyjnego). Kontrole odbywają się w cyklach rocznych — automatyczne (narzędzia skanujące setki stron) i pogłębione (ręczny audyt wybranych stron). Każdy obywatel może też złożyć skargę na niedostępną stronę — podmiot ma 7 dni na odpowiedź i 30 dni na usunięcie barier. Jeśli tego nie zrobi, skarga trafia do Rzecznika Praw Obywatelskich.

Jak zaplanować dostosowanie strony do WCAG?

  1. Audyt wstępny — sprawdź obecny stan narzędziami WAVE i axe (instrukcja krok po kroku)
  2. Lista priorytetów — najpierw napraw: kontrast, alt, formularze, skip link, fokus
  3. Budżet — drobne poprawki: 2 000-5 000 PLN; przebudowa: 10 000-30 000 PLN; nowa strona: od 8 000 PLN
  4. Wykonawca — żądaj doświadczenia z WCAG w sektorze publicznym, referencji, audytu końcowego
  5. Szkolenie redaktorów — dostępne treści to nie tylko kod, ale też sposób redagowania (program szkolenia)
  6. Deklaracja dostępności — opublikuj natychmiast, nawet jeśli strona jest „częściowo zgodna”
  7. Monitoring ciągły — planuj audyt co 12 miesięcy

Artykuł zaktualizowany: styczeń 2025 r.

Potrzebujesz profesjonalnego portalu?

Przygotujemy indywidualną ofertę dla Państwa jednostki.

Zapytaj o wycenę