Deklaracja dostępności 2026 Co musi zawierać, jak ją przygotować i kto kontroluje
Praktyczny przewodnik dla podmiotów publicznych, fundacji i firm objętych EAA — z wymaganiami technicznymi HTML, meta tagiem i najczęstszymi błędami.
W skrócie
Kogo dotyczy:
Każdy podmiot publiczny (urząd, szkoła, szpital, instytucja kultury, fundacja realizująca zadania publiczne). Od 28.06.2025 także firmy prywatne w sektorach objętych European Accessibility Act (e-commerce, bankowość, transport).
Termin:
Aktualizacja do 31 marca każdego roku. Nowe strony od 1 sierpnia 2024 — obowiązkowo w formacie Deklaracji 2.0.
Format:
Wyłącznie HTML (nie PDF, nie Word, nie obraz). Musi być w pełni dostępna cyfrowo — nawet jeśli sama strona nie spełnia WCAG.
Meta tag:
Ministerstwo Cyfryzacji zaleca umieszczenie w kodzie każdej podstrony: <meta name="deklaracja-dostępności" content="URL">. To umożliwia automatyczne wykrywanie deklaracji przez narzędzia monitoringu.
Kara:
Do 5 000 PLN za brak lub niekompltną deklarację. Kontroluje Ministerstwo Cyfryzacji.
Deklaracja dostępności to dokument, który informuje użytkowników — szczególnie osoby z niepełnosprawnościami — o stanie dostępności cyfrowej strony internetowej lub aplikacji mobilnej. Nie jest to marketingowa deklaracja dobrej woli. To obowiązek prawny wynikający z ustawy z 4 kwietnia 2019 roku o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych. Nawet jeśli Twoja strona nie spełnia wymogów WCAG — deklaracja musi istnieć i musi być w pełni dostępna. To jest świadomy wybór ustawodawcy: użytkownik z niepełnosprawnością ma prawo dowiedzieć się, czego może się spodziewać na stronie, zanim zacznie z niej korzystać.
W tym artykule pokazujemy, co dokładnie musi zawierać deklaracja w 2026 roku (wersja 2.0 obowiązująca od 1 sierpnia 2024), jak ją technicznie opublikować — w tym meta tag i identyfikatory HTML — jakie błędy najczęściej popełniają podmioty publiczne i kto to kontroluje.
Co zmieniła Deklaracja Dostępności 2.0
31 lipca 2024 roku Ministerstwo Cyfryzacji opublikowało nową wersję warunków technicznych publikacji deklaracji — wersję 2.0. Nowe strony tworzone od 1 sierpnia 2024 muszą stosować tę wersję. Istniejące strony powinny zaktualizować deklarację przy najbliższym przeglądzie (do 31 marca).
Najważniejsze zmiany
• Ujednolicona struktura dokumentu — stałe sekcje i nagłówki, przewidywalne dla czytników ekranu.
• Zmienione identyfikatory HTML (atrybut id) — nowe nazwy sekcji, więcej wymaganych id.
• Obowiązkowy link do raportu lub samooceny — nie wystarczy zadeklarować zgodność, trzeba wskazać na jakiej podstawie.
• Więcej przykładów kodu HTML w dokumentacji — łatwiejsza implementacja.
• Wyraźniejsze rozdzielenie deklaracji dla stron WWW i aplikacji mobilnych.
Co musi zawierać deklaracja? Obowiązkowe sekcje
Deklaracja dostępności składa się z kilku stałych sekcji. Każda ma określony nagłówek i identyfikator HTML. Poniżej pełna lista z wyjaśnieniem.
Wstęp — oświadczenie o dostępnościNagłówek: „Deklaracja dostępności”. Identyfikator: id="a11y-deklaracja". Zawiera nazwę podmiotu publicznego, nazwę strony internetowej, status zgodności z normą EN 301 549 (która referuje WCAG 2.1 AA). Status może być: zgodna, częściowo zgodna, niezgodna. Ważne: jeśli strona jest częściowo zgodna lub niezgodna, musisz opisać które elementy są niedostępne i dlaczego. Nie możesz napisać „stresta jest zgodna” jeśli tak nie jest.
Treści niedostępneIdentyfikator: id="a11y-niezgodnosc". Sekcja opisująca konkretne elementy, które nie spełniają wymogów. Typowe przykłady: brak alt textów na części obrazów, dokumenty PDF bez struktury, filmy bez napisów, formularze bez etykiet. Każdy problem powinien mieć wskazanie, kiedy zostanie naprawiony lub dlaczego naprawa nie jest możliwa (np. archiwalny materiał przed 23.09.2018).
Data sporządzenia i metoda ocenyData pierwszej publikacji strony, data ostatniej istotnej aktualizacji, data sporządzenia deklaracji, data ostatniego przeglądu. Metoda oceny: samoocena, audyt wewnętrzny lub audyt zewnętrzny. Deklaracja 2.0 wymaga linku do raportu stanowiącego podstawę oceny. Jeśli robiłeś audyt — link do raportu. Jeśli samoocenę — opis metody.
Informacje zwrotne i dane kontaktoweIdentyfikator: id="a11y-kontakt". Obowiązkowy nagłówek: „Informacje zwrotne i dane kontaktowe” — dokładnie w tej formie. Dane osoby kontaktowej (imię, email, telefon) do zgłaszania problemów z dostępnością. Opis procedury rozpatrywania zgłoszeń: bez zbędnej zwłoki, do 7 dni, maksymalnie 2 miesiące. Informacja o możliwości złożenia skargi do Rzecznika Praw Obywatelskich jeśli podmiot nie zareaguje.
Dostępność architektonicznaIdentyfikator: id="a11y-architektura". Opis dostępności fizycznej siedziby: wejścia, windy, toalety, parking dla osób z niepełnosprawnościami, pies asystujący, tłumacz języka migowego. To nie jest opcja — każdy podmiot publiczny musi opisać każdą lokalizację.
Aplikacje mobilne (jeśli dotyczy)Jeśli podmiot udostępnia aplikacje mobilne, dodaje sekcję z informacjami o ich dostępności, linkami do pobrania i statusem zgodności.
Wymagania techniczne HTML jak opublikować deklarację
Deklaracja musi być opublikowana w formacie HTML (dowolna wersja). Nie może być plikiem PDF, obrazem, dokumentem Word ani skanem. Musi spełniać wymagania WCAG 2.1 AA — nawet jeśli sama strona ich nie spełnia.
Gdzie umieścić link
Link do deklaracji musi być widoczny na każdej podstronie — typowo w stopce (footer) lub nagłówku. Użytkownik musi móc dotrzeć do deklaracji z dowolnej podstrony w sposób intuicyjny i dostępny. Tekst linku powinien brzmieć „Deklaracja dostępności” — nie „WCAG”, nie „Dostępność”, nie „A11y”.
Meta tag rekomendacja Ministerstwa Cyfryzacji
Oprócz widocznego linku w stopce, Ministerstwo Cyfryzacji zaleca umieszczenie w kodzie każdej podstrony meta tagu, który wskazuje adres deklaracji dostępności. Dzięki temu narzędzia monitoringu (używane przez Ministerstwo do kontroli) mogą automatycznie znaleźć deklarację bez analizowania wizualnej struktury strony.
Oficjalny format zalecany przez gov.pl:
<meta name="deklaracja-dostępności" content="//twoja-strona.pl/deklaracja-dostepnosci" />
W praktyce niektóre podmioty stosują też alternatywny format z elementem link:
<link rel="deklaracja-dostępności" href="https://twoja-strona.pl/deklaracja-dostepnosci" />
Oba formaty są spotykane w produkcji. Oficjalna rekomendacja Ministerstwa Cyfryzacji (portal gov.pl/web/dostepnosc-cyfrowa) wskazuje na meta tag. Format link rel jest alternatywą stosowaną przez niektóre instytucje, ale nie jest wprost wymieniony w oficjalnych wytycznych. Nasza rekomendacja: stosuj meta tag (bo jest oficjalny) i jednocześnie umieść widoczny link w stopce. Podwójne pokrycie — roboty znajdą tag, ludzie znajdą link.
Jak wdrożyć meta tag w CMS TYPO3
W CMS TYPO3 meta tag można dodać na dwa sposoby. Przez TypoScript — globalnie na wszystkich podstronach:
page.meta.deklaracja-dostępności = //twoja-strona.pl/deklaracja-dostepnosci
Lub bezpośrednio w szablonie Fluid w sekcji <head>:
<meta name="deklaracja-dostępności" content="{f:uri.page(pageUid: 123)}" />
Drugie podejście używa ViewHelper’a Fluid do dynamicznego wygenerowania URL strony z deklaracją — jeśli zmienisz slug deklaracji, meta tag zaktualizuje się automatycznie.
Obowiązkowe identyfikatory HTML (atrybut id) pełna lista
Deklaracja 2.0 wymaga użycia określonych identyfikatorów w elementach HTML. To nie jest dekoracja — narzędzia monitoringu Ministerstwa Cyfryzacji (w tym walidator deklaracja-dostepnosci.info) szukają w kodzie atrybutów id zaczynających się od a11y- i na ich podstawie oceniają kompletność deklaracji. Brak identyfikatorów = deklaracja nierozpoznawalna przez monitoring.
Poniżej pełna lista identyfikatorów wymaganych przez warunki techniczne Ministerstwa Cyfryzacji, pogrupowana według sekcji.
Sekcja wstępna Oświadczenie
• a11y-deklaracja — nagłówek główny: <h1 id="a11y-deklaracja">Deklaracja dostępności</h1>
• a11y-wstep — cała treść oświadczenia wstępnego („Nazwa podmiotu zobowiązuje się zapewnić dostępność...”)
• a11y-podmiot — nazwa podmiotu publicznego, np. <span id="a11y-podmiot">Urząd Miasta Krakowa</span>
• a11y-url — link do strony, której dotyczy deklaracja, np. <a id="a11y-url" href="...">strona internetowa Urzędu</a>
Sekcja statusu zgodności
• a11y-status — status zgodności: zgodna / częściowo zgodna / niezgodna z ustawą
• a11y-niezgodnosc — lista treści niedostępnych (wymagane jeśli status nie jest „zgodna”)
Sekcja przygotowania deklaracji
• a11y-data-sporzadzenie — data sporządzenia deklaracji w formacie RRRR-MM-DD, np. <span id="a11y-data-sporzadzenie">2026-03-15</span>
• a11y-audytor — nazwa podmiotu zewnętrznego, który przeprowadził audyt (opcjonalny — wymagany tylko jeśli badanie wykonał podmiot zewnętrzny)
• a11y-ocena — link do dokumentu z analizą nadmiernego obciążenia (opcjonalny)
Sekcja kontaktowa najczęściej pomijana
To jest sekcja, w której najczęściej brakuje identyfikatorów. Każdy element kontaktowy musi mieć własne id:
• a11y-kontakt — nagłówek sekcji: <h2 id="a11y-kontakt">Informacje zwrotne i dane kontaktowe</h2>
• a11y-osoba — imię i nazwisko osoby odpowiedzialnej za kontakt w sprawie dostępności, np. <span id="a11y-osoba">Jan Kowalski</span>. To NIE jest IOD — to koordynator dostępności lub osoba pełniąca tę funkcję.
• a11y-email — adres email osoby kontaktowej: <a id="a11y-email" href="mailto:[email protected]">[email protected]</a>
• a11y-telefon — numer telefonu do osoby kontaktowej
• a11y-procedura — opis procedury wnioskowo-skargowej (co zrobić, jeśli podmiot nie zareaguje: skarga do Rzecznika Praw Obywatelskich)
Dlaczego a11y-osoba jest ważne: użytkownik z niepełnosprawnością musi wiedzieć, do kogo konkretnie się zwrócić. „Kontakt” to za mało — ustawa wymaga wskazania osoby. Walidator sprawdza, czy ten identyfikator istnieje w kodzie HTML deklaracji.
Sekcja dostępności architektonicznej i komunikacyjnej
• a11y-architektura — nagłówek sekcji: <h2 id="a11y-architektura">Dostępność architektoniczna</h2>
• a11y-architektura-url — link do osobnej strony z opisem dostępności architektonicznej (jeśli opis jest na innej podstronie)
• a11y-komunikacja — sekcja z informacjami o dostępności komunikacyjno-informacyjnej (tłumacz PJM, pętla indukcyjna itp.)
• a11y-aplikacje — sekcja z aplikacjami mobilnymi (jeśli podmiot je udostępnia)
Przykład poprawnego kodu HTML
Fragment sekcji kontaktowej z wszystkimi wymaganymi identyfikatorami:
<h2 id="a11y-kontakt">Informacje zwrotne i dane kontaktowe</h2> <p>Osobą kontaktową jest <span id="a11y-osoba">Anna Nowak</span>, e-mail: <a id="a11y-email" href="mailto:[email protected]"> [email protected]</a>, telefon: <span id="a11y-telefon">12 345 67 89</span>. </p> <div id="a11y-procedura"> <p>Każdy ma prawo do wystąpienia z żądaniem zapewnienia dostępności cyfrowej strony lub jej elementu...</p> </div>
Walidator deklaracja-dostepnosci.info szuka w kodzie HTML wszystkich elementów z atrybutem id zaczynającym się od a11y- i porównuje je z wymaganiami warunków technicznych 2.0. Jeśli brakuje wymaganego identyfikatora — deklaracja jest oznaczana jako niekompletna. Narzędzie jest dostępne publicznie i każdy może sprawdzić swoją deklarację przed kontrolą Ministerstwa.
Obowiązkowe nagłówki HTML
Deklaracja 2.0 wymaga minimum 8 nagłówków w odpowiedniej hierarchii:
• Deklaracja dostępności — nagłówek tytułowy (h1)
• Stan dostępności cyfrowej — podrzędny do tytułowego (h2)
• Przygotowanie deklaracji dostępności — h2
• Informacje zwrotne i dane kontaktowe — h2 (dokładnie ta nazwa, obowiązkowa formuła)
• Obsługa wniosków i skarg związanych z dostępnością — h2
• Dostępność architektoniczna — h2
• Dostępność komunikacyjno-informacyjna — h2
• Aplikacje mobilne — h2 (jeśli podmiot je udostępnia)
Hierarchia musi być logiczna: jeśli tytuł jest h1, sekcje są h2. Jeśli deklaracja jest osadzona w stronie z własnym h1, tytuł deklaracji może być h2, a sekcje h3. Ważne: nie wolno przeskakiwać poziomów (np. h1 → h3 bez h2). Czytnik ekranu traci kontekst.
Najczęstsze błędy Co widzimy u klientów
Zanim przejdziesz do publikacji deklaracji, warto zobaczyć, gdzie najczęściej pojawiają się problemy. W praktyce większość błędów nie wynika z braku dobrej woli, tylko z niedoprecyzowania wymagań albo kopiowania gotowych wzorów bez zrozumienia ich znaczenia. Efekt jest ten sam: deklaracja wygląda poprawnie „na oko”, ale nie spełnia wymogów formalnych lub technicznych i nie przechodzi walidacji. Poniżej zebraliśmy najczęstsze błędy, które regularnie widzimy w projektach — zarówno u podmiotów publicznych, jak i firm objętych wymogami dostępności.
Błędy formalne
✗ Deklaracja opublikowana jako PDF — to jest niezgodne z ustawą, musi być HTML.
✗ Brak daty ostatniego przeglądu — deklaracja wygląda jak z 2020 roku.
✗ Brak informacji o metodzie oceny — nie wiadomo, na jakiej podstawie oceniono dostępność.
✗ Brak linku do raportu lub samooceny — wymag Deklaracji 2.0.
✗ Kopiowanie deklaracji z innej instytucji — częste, łatwe do wykrycia przez monitoring.
Błędy techniczne
✗ Brak identyfikatorów HTML (atrybut id) — narzędzia monitoringu nie rozpoznają sekcji.
✗ Brak meta tagu <meta name="deklaracja-dostępności"> — automatyczne wykrywanie niemożliwe.
✗ Nagłówki w złej hierarchii — np. H3 po H1 bez H2. Czytnik ekranu traci kontekst.
✗ Sama deklaracja niedostępna — brak kontrastu, brak nawigacji klawiaturowej, brak focus indicatorów. Ironia: dokument o dostępności jest niedostępny.
Błędy treściowe
✗ Status „zgodna” gdy strona ma oczywiste problemy — to jest nieprawda i może być podstawą skargi.
✗ Brak opisu treści niedostępnych — „stresta jest częściowo zgodna” bez wyjaśnienia co jest niezgodne.
✗ Brak danych kontaktowych koordynatora dostępności — użytkownik nie wie, do kogo zgłosić problem.
✗ Brak informacji o dostępności architektonicznej — szczególnie częste w instytucjach z wieloma lokalizacjami.
Kto kontroluje deklaracje dostępności? Jakie są kary za nieprzestrzeganie zasad
Monitoring dostępności cyfrowej prowadzi Ministerstwo Cyfryzacji. Corocznie publikuje raport z wynikami monitoringu stron podmiotów publicznych. Kontrola może być planowa (losowa próbka) lub po zgłoszeniu użytkownika.
Procedura: Ministerstwo wzywa do poprawy — podmiot ma od 60 do 120 dni na reakcję. Jeśli nie zareaguje, może zostać nałożona kara do 5 000 PLN za brak deklaracji lub publikację niekompletnej deklaracji. W skrajnych przypadkach Ministerstwo może zobowiązać podmiot do wycofania usługi lub nałożyć zakaz dalszego działania strony.
Dodatkowo każdy użytkownik ma prawo złożyć skargę na brak dostępności do Rzecznika Praw Obywatelskich. To oznacza, że nawet jeśli Ministerstwo nie skontroluje akurat Twojej strony, użytkownik z niepełnosprawnością może sam zainicjować procedurę.
Ważne: od 28 czerwca 2025 firmy prywatne w sektorach objętych EAA (e-commerce, bankowość, transport, telekomunikacja) również podlegają wymogom dostępności. Kontrolują je inne organy (PFRON, nadzory branżowe), ale zasada jest ta sama: brak dostępności = konsekwencje prawne i finansowe.
Jak przygotować deklarację Krok po kroku
Jeśli dopiero tworzysz deklarację lub musisz zaktualizować istniejącą, oto sprawdzony proces.
- Przeprowadź audyt dostępności strony
Samodzielnie (lista kontrolna gov.pl, narzędzia WAVE, Lighthouse, aXe) lub zlecając audytorowi. Musisz wiedzieć, co jest zgodne, a co nie, zanim napiszesz deklarację.
- Zbierz dane o dostępności architektonicznej
Każda lokalizacja: wejścia, windy, toalety, parkingi, pies asystujący, tłumacz PJM.
- Napisz deklarację w HTML
Użyj struktury z Deklaracji 2.0: nagłówki z identyfikatorami, stałe nazwy sekcji, poprawna hierarchia.
- Umieść meta tag w kodzie każdej podstrony
<meta name="deklaracja-dostępności" content="URL">
- Dodaj widoczny link w stopce
Tekst „Deklaracja dostępności”, widoczny na każdej podstronie.
- Przetestuj dostępność samej deklaracji
Kontrast, nawigacja klawiaturowa, czytnik ekranu. Deklaracja musi być w pełni dostępna.
Ustaw przypomnienie o przeglądzieDo 31 marca każdego roku i po każdej większej przebudowie strony.
Najczęściej zadawane pytania
Jeśli fundacja realizuje zadania publiczne lub otrzymuje środki publiczne — tak, podlega ustawie o dostępności cyfrowej. Jeśli jest czysto prywatna — nie musi, ale od 28.06.2025 może podlegać EAA jeśli działa w objętych sektorach (np. e-commerce).
Nie. Ustawa wymaga formatu HTML. PDF nie jest dostępny w taki sam sposób jak strona HTML — czytniki ekranu obsługują HTML natywnie, PDF wymaga dodatkowej struktury (tagi PDF/UA), której większość dokumentów nie ma.
Nadal musisz opublikować deklarację. Wpisz status „niezgodna” lub „częściowo zgodna” i opisz konkretnie, które elementy są niedostępne. Deklaracja nie jest kara — to informacja dla użytkowników. Lepiej uczciwa deklaracja „niezgodna” niż fałszywa „zgodna”.
Meta tag (<meta name="deklaracja-dostępności" content="URL">) to oficjalna rekomendacja Ministerstwa Cyfryzacji — służy do automatycznego wykrywania deklaracji przez narzędzia monitoringu. Link rel (<link rel="deklaracja-dostępności" href="URL">) to alternatywny format stosowany przez niektóre instytucje, ale nie jest wprost wymieniony w oficjalnych wytycznych. Nasza rekomendacja: stosuj meta tag (oficjalny) i dodaj widoczny link w stopce.
Minimum raz w roku — do 31 marca. Dodatkowo po każdej większej przebudowie strony, zmianie CMS, dodaniu nowych funkcji (formularze, multimedia, e-usługi). W praktyce warto przeglądać deklarację po każdej aktualizacji treści, która może wpłynąć na dostępność (np. nowe PDF-y, nowe filmy).
Generator to dobry punkt wyjścia — tworzy szkielet z poprawnymi sekcjami i identyfikatorami. Ale musisz go dostosować do swojej konkretnej sytuacji: opisać faktyczne problemy, dodać dane kontaktowe, dostępność architektoniczną, link do raportu. Szablon generyczny nie zastąpi indywidualnej oceny stanu Twojej strony.
Częściowo. Meta tag i link w stopce dodajesz raz w TypoScript lub szablonie Fluid. Treść deklaracji to podstrona HTML w TYPO3 — redaktor aktualizuje ją jak każdą inną stronę. Identyfikatory HTML wstawiasz ręcznie w edytorze HTML lub przez dedykowany Content Block. EYE-ABLE Report może automatycznie generować deklarację na podstawie wyników skanów — ale i tak wymaga weryfikacji przez człowieka.
Jak możemy pomóc
Przygotowanie prawidłowej deklaracji dostępności wymaga trzech rzeczy: wiedzy o stanie Twojej strony (audyt), znajomości wymagań prawnych i technicznych (wersja 2.0, identyfikatory, meta tag) oraz umiejętności wdrożenia tego w konkretnym CMS. Łączymy wszystkie trzy.
Nasze portfolio zawiera wdrożone strony internetowe podmiotów publicznych, fundacji i instytucji na CMS TYPO3 — w tym CUS Drobin, Międzynarodowy Dom Spotkań Młodzieży w Oświęcimiu, Niemiecki Instytut Historyczny w Warszawie. Każdy z tych projektów wymagał pełnej deklaracji dostępności, audytu WCAG i wdrożenia poprawek. Wiemy, jak to wygląda w praktyce — nie tylko w teorii.
Jeśli potrzebujesz audytu dostępności, przygotowania deklaracji zgodnej z wersją 2.0, wdrożenia meta tagu i identyfikatorów HTML, lub kompleksowego dostosowania strony do WCAG — skontaktuj się z nami. Telefon: 12 333 44 01. Email: [email protected].