Jak napisać deklarację dostępności (z przykładami)

Deklaracja dostępności to publiczna strona wyjaśniająca zaangażowanie organizacji w dostępność cyfrową, uczciwie podająca bieżący poziom zgodności oraz dająca odwiedzającym sposób na zgłoszenie napotkanych barier. Odwiedzający powinien przeczytać ją w dwie minuty i dowiedzieć się dokładnie, do kogo się zwrócić, jeśli coś na stronie nie działa tak, jak powinno. Poniżej struktura, którą można bezpośrednio zaadaptować, wraz z uwagami, czego unikać.

Co powinna zawierać

Solidna deklaracja dostępności obejmuje pięć elementów: krótkie oświadczenie o zaangażowaniu, bieżący status zgodności względem nazwanego standardu (zwykle WCAG 2.1 lub 2.2 AA), sposób oceny tego statusu, znane ograniczenia, o ile istnieją, oraz dane kontaktowe do zgłaszania uwag. Pominięcie statusu zgodności i poprzestanie na “zależy nam na dostępności” to najczęstsza słabość widziana w deklaracjach; brzmi jak hasło marketingowe, a nie dokumentacja.

Szablon do adaptacji

Zastąp fragmenty w nawiasach szczegółami właściwymi dla danej organizacji.

Deklaracja dostępności dla [nazwa organizacji]

[Nazwa organizacji] dąży do zapewnienia dostępności cyfrowej osobom z niepełnosprawnościami. Stale poprawiamy doświadczenie użytkowników dla wszystkich i stosujemy odpowiednie standardy dostępności.

Status zgodności: Ta strona internetowa dąży do zgodności z WCAG 2.1 na poziomie AA. [Wskaż jedno z: “jest w pełni zgodna”, “jest częściowo zgodna” lub “nie jest obecnie zgodna”, i krótko wyjaśnij dlaczego, jeśli nie jest to pełna zgodność.]

Znane ograniczenia: [Wymień znane problemy, np. “Niektóre starsze dokumenty PDF opublikowane przed 2025 rokiem nie zostały jeszcze poprawione i mogą nie być w pełni dostępne dla użytkowników czytników ekranu. Sukcesywnie nad tym pracujemy.”]

Opinie i zgłoszenia: Chętnie poznamy Państwa opinię na temat dostępności [nazwa strony]. Prosimy o kontakt w razie napotkania barier w dostępności. Telefon: [numer] E-mail: [adres] Adres korespondencyjny: [adres] Staramy się odpowiadać na zgłoszenia w ciągu [X] dni roboczych.

Specyfikacja techniczna: Dostępność [nazwa strony] opiera się na HTML, CSS, JavaScript i WAI-ARIA w zakresie współpracy z technologiami wspomagającymi.

Sposób oceny: [Nazwa organizacji] oceniła dostępność tej strony poprzez [samoocenę / zewnętrzny audyt / skanowanie automatyczne połączone z testami ręcznymi]. Niniejsza deklaracja została ostatnio zaktualizowana dnia [data].

Czego unikać

Nie twierdź o “pełnej zgodności” ani “100% zgodności z ADA”, chyba że faktycznie zostało to zweryfikowane testami, najlepiej z udziałem testów ręcznych, a nie samego skanu automatycznego. Tego typu twierdzenia stały się przedmiotem szczególnej kontroli; w 2025 roku amerykańska FTC nakazała accessiBe zapłacić 1 milion dolarów w ramach ugody dotyczącej zarzutów częściowo związanych z przesadzonymi twierdzeniami o tym, jak dużą część strony może automatycznie naprawić jej widżet. Ta lekcja jest uniwersalna daleko poza tym jednym przypadkiem: deklaracja powinna opisywać to, co faktycznie zweryfikowano, a nie to, co chciałoby się, żeby było prawdą.

Unikaj też ukrywania deklaracji tam, gdzie nikt jej nie znajdzie. Umieść link do niej w stopce strony i upewnij się, że sama strona z deklaracją jest dostępna (właściwa struktura nagłówków, czytelny kontrast, żadnych ścian nieustrukturyzowanego tekstu).

Wygenerowane deklaracje kontra deklaracja oparta na prawdziwych testach

Kilku dostawców widżetów, w tym UserWay i accessiBe, oferuje generator deklaracji dostępności jako część swojego produktu. Może to być naprawdę przydatny punkt startowy pod względem struktury i standardowego sformułowania, zwłaszcza dla małej strony bez wewnętrznej wiedzy prawnej czy eksperckiej w dziedzinie dostępności. Luka, na którą warto uważać, polega na tym, że wygenerowana deklaracja oparta na szybkim automatycznym skanie może w efekcie twierdzić o poziomie zgodności, na który strona faktycznie nie zapracowała poprzez testy ręczne. Jeśli firma korzysta z wygenerowanej deklaracji, warto traktować sekcję statusu zgodności jako część wymagającą najwięcej redakcji i zaktualizować ją, gdy tylko zna się rzeczywisty stan, zamiast przyjmować domyślne twierdzenie.

Dla organizacji, które są dalej w tym procesie, deklaracja napisana po faktycznym audycie, czy to od dostawcy skoncentrowanego na testach, czy od dostawcy łączącego widżet z ręcznym przeglądem, jak Wawsome, może stwierdzać zgodność z większą pewnością, ponieważ stoją za nią realne dowody. Jeśli firma przygotowuje deklarację konkretnie na potrzeby sektora publicznego UE lub w związku z EAA, warto dostosować język zgodności także do terminologii EN 301 549, obok WCAG, ponieważ to właśnie tego standardu będą oczekiwać recenzenci i zespoły zakupowe w UE.

Uczciwe napisanie sekcji statusu zgodności

To część deklaracji, na którą warto poświęcić najwięcej czasu, i część, którą większość szablonów celowo pozostawia niejasną. “Częściowo zgodna” to zupełnie normalne, uczciwe sformułowanie, i jest znacznie bardziej przydatne dla odwiedzającego (a znacznie łatwiejsze do obrony w razie skargi) niż nieuprawnione twierdzenie o “pełnej dostępności”, którego nie da się faktycznie poprzeć. Jeśli przeprowadzono audyt, warto wskazać standard i wersję, względem której testowano (WCAG 2.1 AA to najczęstszy punkt odniesienia), oraz podać ogólny zakres, czy była to cała strona, podzbiór kluczowych podstron, czy konkretne ścieżki jak proces zakupowy. Jeśli formalny audyt nie został jeszcze przeprowadzony, można to wprost napisać: “Nie przeprowadziliśmy jeszcze formalnego audytu dostępności tej strony. Zobowiązujemy się to zrobić i zaktualizujemy niniejszą deklarację po zakończeniu tych prac” to uczciwa, przydatna informacja i rozsądne stwierdzenie tymczasowe na czas trwania prac naprawczych.

Obsługa zgłoszeń, gdy zaczną napływać

Sekcja ze zgłoszeniami to nie tylko formalność: publikacja danych kontaktowych oznacza, że warto spodziewać się faktycznych zgłoszeń, a brak wewnętrznego procesu ich obsługi podważa sens publikowania deklaracji w ogóle. Warto ustalić, kto w zespole odpowiada za przychodzące zgłoszenia dotyczące dostępności, wyznaczyć realistyczny czas odpowiedzi (i zapisać go w samej deklaracji, tak jak w powyższym szablonie) oraz prowadzić prosty rejestr tego, co zostało zgłoszone i jak rozwiązane. Taki rejestr staje się przydatnym dowodem aktywnego, działającego programu dostępności, gdyby był kiedykolwiek potrzebny, a naturalnie zasila też sekcję “znane ograniczenia”, ponieważ prawdziwe zgłoszenia użytkowników są często lepszym źródłem tego, co faktycznie nie działa, niż sam automatyczny skan.

Kwestie wielojęzyczności i wielu witryn

Jeśli organizacja działa w więcej niż jednym języku lub prowadzi osobne deklaracje dla różnych serwisów, warto zachować spójne sformułowanie statusu zgodności między wersjami, zamiast pozwolić, by jedna wersja językowa przypadkowo deklarowała wyższy poziom zgodności niż druga. Zdarza się to często firmom działającym na rynku UE, prowadzącym deklaracje w wielu językach, gdzie tłumaczenie wykonane niezależnie od oryginału może odbiegać od faktycznego bieżącego stanu. Przegląd wszystkich wersji językowych razem, w tym samym momencie co coroczna aktualizacja, to prosty sposób na uniknięcie takiej rozbieżności.

Gdzie ją opublikować

Większość organizacji publikuje deklarację jako osobną stronę, linkowaną w stopce na każdej podstronie, czasem powielaną w sekcji regulaminu lub polityki prywatności. Podmioty sektora publicznego UE objęte dyrektywą w sprawie dostępności stron internetowych mają obowiązek publikować ją w łatwo znajdywalnym miejscu i utrzymywać w aktualności; to rozsądna praktyka warta stosowania nawet tam, gdzie nie jest ściśle nakazana, ponieważ sygnalizuje zarówno użytkownikom, jak i, jeśli kiedyś do tego dojdzie, sądowi lub regulatorowi, że dostępność jest czymś, nad czym firma faktycznie się zastanowiła, a nie zignorowała.