Ustawa z 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych nakłada na samorządy, szkoły, biblioteki, muzea i jednostki budżetowe obowiązek zgodności z WCAG 2.1 na poziomie AA. Kary za brak dostępności wynoszą do 10 000 zł dla stron www i aplikacji mobilnych, do 5 000 zł za brak lub nieaktualną deklarację dostępności. WordPress może być w pełni zgodny z WCAG 2.1 AA — ale wymaga dobrze napisanego motywu lub wtyczki i świadomego zarządzania treścią.
Kogo obowiązuje ustawa o dostępności cyfrowej
Ustawa obejmuje wszystkie podmioty publiczne wymienione w art. 3 ustawy z 4 kwietnia 2019 r. To szeroka kategoria, która obejmuje m.in.:
- jednostki samorządu terytorialnego (gminy, powiaty, województwa) i ich jednostki organizacyjne,
- szkoły i uczelnie publiczne,
- biblioteki, muzea, teatry finansowane ze środków publicznych,
- podmioty publiczne wykonujące zadania publiczne (np. spółki komunalne),
- organizacje pozarządowe, które realizują zadania publiczne finansowane ze środków publicznych.
NGO z dotacją publiczną — tu jest pułapka. Organizacja pozarządowa, która realizuje projekt dofinansowany ze środków publicznych (np. z FE, z dotacji samorządu) i w ramach tego projektu prowadzi stronę internetową, podlega wymogom ustawy w zakresie tej strony. To wymóg pojawia się często w umowach o dofinansowanie jako warunek rozliczenia projektu.
Od 28 czerwca 2025 r. Europejski Akt o Dostępności (EAA, dyrektywa 2019/882) rozszerza wymogi dostępności na sektor prywatny — banki, sklepy e-commerce, platformy streamingowe, usługi telekomunikacyjne. To zmiana, która dotyczy firm, nie tylko podmiotów publicznych.
Co znaczy WCAG 2.1 AA w praktyce
WCAG (Web Content Accessibility Guidelines) to standard opracowany przez W3C. Wersja 2.1 na poziomie AA to minimum wymagane przez polskie i unijne przepisy. Standard składa się z czterech zasad — treść musi być:
Postrzegalna — użytkownik musi móc odebrać treść wszystkimi zmysłami lub ich alternatywą:
- Obrazy mają teksty alternatywne (alt),
- Wideo ma napisy i audiodeskrypcję,
- Kontrast kolorów tekstu do tła wynosi minimum 4,5:1 (AA),
- Treść nie znika po powiększeniu tekstu do 200%.
Funkcjonalna — interfejs musi działać bez myszy (tylko klawiatura):
- Wszystkie funkcje dostępne z klawiatury,
- Widoczny focus (zaznaczenie aktywnego elementu),
- Nie ma pułapek klawiatury,
- Tytuły stron są unikalne i opisowe.
Zrozumiała — treść i interfejs muszą być przewidywalne:
- Język strony jest określony w kodzie (atrybut
lang), - Formularze mają etykiety i komunikaty błędów,
- Nawigacja jest spójna na całej stronie.
Solidna (Robust) — kod musi być kompatybilny z technologiami asystującymi:
- Poprawny HTML (atrybuty ARIA, semantyczne tagi),
- Kompatybilność z czytnikami ekranu (NVDA, JAWS, VoiceOver).
Dostępność WCAG 2.1 AA pokrywa się w około 90% z dobrymi praktykami technicznego SEO. Poprawny HTML, szybkie ładowanie, responsywność, czytelna struktura nagłówków — to jednocześnie wymagania dostępności i czynniki rankingowe Google.
Ile kosztuje strona lub aplikacja WordPress dla samorządu, NGO lub instytucji kultury?
Deklaracja dostępności — obowiązek i terminy
Deklaracja dostępności to dokument, który każdy podmiot publiczny musi publikować na swojej stronie. Zawiera:
- ocenę aktualnego stanu dostępności strony,
- wykaz znanych niedostępnych elementów i powodów ich wyłączenia,
- dane kontaktowe do zgłaszania problemów z dostępnością,
- link do procedury odwoławczej (wniosek do organu nadzorczego),
- datę ostatniej aktualizacji.
Kluczowe terminy:
- Deklarację dostępności trzeba publikować i aktualizować do 31 marca każdego roku,
- Przy nowych stronach: deklaracja musi być opublikowana od razu przy uruchomieniu,
- Przy przebudowie strony: deklaracja musi być zaktualizowana.
Brak deklaracji lub brak jej aktualizacji w terminie to podstawa do nałożenia kary do 5 000 zł (ustawa z 4.04.2019, art. 18). Deklaracja dostępności nie jest dowodem na zgodność — jest deklaracją stanu faktycznego. Podmiot, który opublikuje deklarację bez rzeczywistego audytu, naraża się na odpowiedzialność za podanie nieprawdy.
Kary i nadzór — kto i jak egzekwuje
Organem nadzorczym w Polsce jest Minister Cyfryzacji (wcześniej Ministerstwo Cyfryzacji). Kontrole prowadzi KPRM (Kancelaria Prezesa Rady Ministrów). Mechanizm:
- Skarga użytkownika — każdy użytkownik może zgłosić naruszenie dostępności do podmiotu publicznego (dane w deklaracji dostępności). Podmiot ma 7 dni na odpowiedź, 60 dni na usunięcie bariery.
- Postępowanie sądowo-administracyjne — gdy podmiot nie reaguje, użytkownik może złożyć wniosek do organu nadzorczego.
- Kara administracyjna — do 10 000 zł dla podmiotu publicznego za naruszenia dotyczące strony www i aplikacji mobilnych; do 5 000 zł za brak deklaracji dostępności.
W praktyce kontrole skupiały się głównie na dużych podmiotach (ministerstwa, urzędy centralne) i podmiotach, które otrzymały skargi. Mniejsze gminy i NGO były objęte kontrolami rzadziej — ale ryzyko rośnie wraz ze wzrostem świadomości użytkowników i zwiększoną aktywnością organizacji rzeczniczych.
WordPress jako platforma dostępna cyfrowo
WordPress obsługuje ponad 43% stron na świecie i jest w pełni zdolny do spełnienia WCAG 2.1 AA — pod warunkiem właściwej implementacji. Sam rdzeń WordPress jest rozwijany z uwzględnieniem dostępności. Problem leży w motywach i wtyczkach.
Motyw (theme) — kontroluje HTML i CSS generowany przez WordPressa. Motyw niedostępny cyfrowo (brak kontrastu, brak semantyki, brak obsługi klawiatury) uniemożliwia spełnienie WCAG niezależnie od tego, jak jest zarządzana treść. Żaden popularny, darmowy motyw nie gwarantuje zgodności z WCAG 2.1 AA out-of-the-box. Dedykowany motyw lub custom plugin z własnym renderowaniem HTML daje pełną kontrolę.
Treść zarządzana w CMS — poprawność atrybutów alt, struktura nagłówków, format tabel zależy od redaktora treści. WordPress (Gutenberg) daje możliwość zarządzania dostępnością treści, ale wymaga przeszkolenia redaktorów.
Wtyczki — każda dodana wtyczka może wprowadzić niedostępne elementy. Slider z animacją bez opcji wstrzymania, mapa bez alternatywy tekstowej, formularz bez etykiet — to typowe problemy. Przy architekturze własnej wtyczki (izolowanej od motywu i rdzenia WP) mamy pełną kontrolę nad każdym elementem HTML, co umożliwia spełnienie WCAG w całości.
Zbudowaliśmy pełną platformę WordPress z własną logiką aplikacji (~26 000 linii kodu) i przez cały projekt utrzymywaliśmy zgodność z WCAG 2.1 AA: poprawny kontrast kolorów, semantyczne nagłówki, obsługa klawiatury na mapie Leaflet.js, opisy alt na zdjęciach, formularze z etykietami i komunikatami błędów.
Audyt dostępności — co obejmuje i ile kosztuje
Audyt WCAG 2.1 AA weryfikuje stronę pod kątem wszystkich kryteriów sukcesu poziomu A i AA (ok. 50 wymagań). Standardowy audyt obejmuje:
- Automatyczne testy narzędziami (axe, WAVE, Lighthouse) — wykrywają ok. 30–40% problemów,
- Manualne testy nawigacji klawiaturą,
- Testy czytnikiem ekranu (NVDA dla Windows, VoiceOver dla macOS/iOS),
- Testy powiększenia tekstu i zmiany kontrastu,
- Przegląd kodu HTML (ARIA, semantyka).
Wynikiem audytu jest raport z listą naruszeń z priorytetyzacją i rekomendacjami naprawy.
Koszt audytu zależy od rozmiaru strony. [DO UZUPEŁNIENIA: orientacyjne widełki cenowe audytu WCAG dla strony samorządowej — brak danych w materiałach źródłowych]. Audyt jest pozycją odrębną od wdrożenia — można zlecić go niezależnie.
Jak zbudować dostępny serwis na WordPress krok po kroku
- Audyt istniejącej strony (jeśli jest) — identyfikacja naruszeń, priorytetyzacja.
- Wybór lub budowa dostępnego motywu — weryfikacja kontrastu, semantyki HTML, obsługi klawiatury.
- Konfiguracja wtyczek — usunięcie lub zastąpienie niedostępnych elementów.
- Szkolenie redaktorów treści — zasady zarządzania obrazami (alt), strukturą nagłówków, tabelami.
- Testy manualne — NVDA/VoiceOver, nawigacja klawiaturą, powiększenie tekstu.
- Przygotowanie deklaracji dostępności — dokumentacja stanu faktycznego.
- Monitoring — cykliczne sprawdzanie dostępności po dodaniu nowych treści i aktualizacjach wtyczek.
Dostępność to nie jednorazowy projekt, ale ciągły proces. Nowa treść (zdjęcie bez alt, tabela bez nagłówków) może naruszyć dostępność już po wdrożeniu. Stąd szkolenie redaktorów jest równie ważne jak prawidłowy kod.
Platforma zgłoszeń i partycypacji mieszkańców: jak zbudować system z mapą dla gminy
Finansowanie z dotacji
Wdrożenie dostępnej strony dla samorządu lub NGO można finansować ze środków:
- Fundusze Europejskie — programy regionalne i krajowe na cyfryzację, w tym wymogi dostępności jako warunek rozliczenia,
- Rządowy Fundusz Polski Ład — dla samorządów,
- Dotacje z ministerstw i urzędów centralnych — np. programy Ministerstwa Kultury dla instytucji kultury,
- Środki własne gminy — wydatki na dostępność jako obowiązkowe na mocy ustawy.
Przy projektach z dofinansowaniem europejskim dostępność WCAG 2.1 AA jest zazwyczaj wymagana jako warunek rozliczenia — nie jako opcja.
Jeśli chcesz omówić dostosowanie strony samorządu lub instytucji do wymogów WCAG 2.1 — opisz sytuację w formularzu (aktualna strona, rodzaj podmiotu, termin), a wrócimy z oceną zakresu i harmonogramem. Klikalny prototyp rozwiązania możemy pokazać w 48 godzin.