- Strategia oparta o dane i cele biznesowe.
- Rekomendacje UX, integracji i automatyzacji.
- Plan wdrożeń i wsparcie zespołu.
W poprzednim artykule omówiliśmy, czym jest informacja o dostępności, kogo dotyczy i co grozi za jej brak. Jeśli jeszcze go nie czytałeś — zacznij tam, bo ten wpis jest jego bezpośrednim rozwinięciem. Tutaj wchodzimy w konkretny poziom: jak ten dokument powinien wyglądać, co w nim napisać i jakich sformułowań unikać, żeby nie skończyć z dokumentem, który formalnie istnieje, ale jest bezużyteczny lub wprost błędny.
Pracując z klientami przy wdrożeniach dostępności, regularnie widzimy te same dokumenty — albo skopiowane z instytucji publicznych, albo wygenerowane przez AI bez żadnej weryfikacji. Efekt jest za każdym razem ten sam: dokument, który wygląda poprawnie na pierwszy rzut oka, ale nie opisuje rzeczywistego serwisu i nie spełnia swoich funkcji ani informacyjnych, ani prawnych.
Przeprowadzimy audyt WCAG i przygotujemy kompletną, rzetelną informację o dostępności — opartą na rzeczywistym stanie Twojego serwisu, nie na szablonie z internetu.
Struktura dokumentu — co musi być, a co jest opcjonalne
Informacja o dostępności powinna mieć jasną, przewidywalną strukturę. Zacznij od nagłówka identyfikującego serwis: pełna nazwa sklepu lub serwisu, adres URL i data ostatniej aktualizacji dokumentu. To element, który jest często pomijany, a jest kluczowy — użytkownik musi wiedzieć, czy czyta aktualną informację, czy dokument sprzed dwóch lat.
Następna sekcja to status zgodności. Masz do wyboru trzy sformułowania: „serwis jest w pełni zgodny z WCAG 2.2 na poziomie AA”, „serwis jest częściowo zgodny z WCAG 2.2 na poziomie AA” lub „serwis nie jest zgodny z WCAG 2.2 na poziomie AA”. Wybierz to, które odpowiada rzeczywistości. Jeśli nie wiesz, bo nie robiłeś audytu — napisz „częściowa zgodność” i wskaż znane problemy. To uczciwe i bezpieczne podejście.
Jak opisać elementy niedostępne — bez prawniczego bełkotu
Sekcja z listą elementów niedostępnych to miejsce, gdzie większość dokumentów całkowicie się sypie. Albo jest pusta („brak elementów niedostępnych” — co rzadko jest prawdą), albo zawiera ogólniki w stylu „niektóre elementy mogą nie spełniać wymogów dostępności”, albo cytuje numery kryteriów WCAG bez żadnego wyjaśnienia co to oznacza w praktyce.
Opis elementów niedostępnych powinien być konkretny i zrozumiały dla osoby nieznającej WCAG. Przykłady dobrych sformułowań: „Część zdjęć produktów nie posiada opisów alternatywnych (tekst alt) — pracujemy nad ich uzupełnieniem, planowany termin: październik 2025.” Albo: „Proces składania zamówienia nie jest w pełni obsługiwalny za pomocą samej klawiatury — wymagamy kliknięcia myszą w kroku wyboru sposobu dostawy. Planujemy naprawę do końca roku.” Takie opisy są uczciwe, konkretne i pokazują, że firma jest świadoma problemu i pracuje nad jego rozwiązaniem.
Dane kontaktowe i procedura zgłaszania problemów
Sekcja kontaktowa to niezbędny element — użytkownik musi mieć realny kanał do zgłoszenia problemu. Adres email lub formularz kontaktowy są wystarczające. Warto wskazać czas odpowiedzi, np. „Odpowiadamy w ciągu 5 dni roboczych.” Jeśli ktoś zgłosi problem, który faktycznie istnieje, to dobra wiadomość — możesz go naprawić i podziękować użytkownikowi za informację.
Procedura odwoławcza to sekcja, która informuje, gdzie użytkownik może się odwołać jeśli jego zgłoszenie nie zostanie rozpatrzone. Dla podmiotów prywatnych należy wskazać odpowiedni organ nadzorczy lub sąd. Nie musisz wchodzić w szczegóły prawne — wystarczy krótki akapit z informacją, że użytkownik ma prawo dochodzić swoich praw przez odpowiednie organy, i odesłanie do właściwej instytucji.
Wzór struktury — gotowy schemat do wypełnienia
Poniższy schemat możesz potraktować jako punkt wyjścia. Każdą sekcję należy uzupełnić informacjami specyficznymi dla Twojego serwisu — nie kopiuj cudzych danych ani nie zostawiaj pustych pól.
Informacja o dostępności cyfrowej — [Nazwa sklepu]
Adres serwisu: [URL]
Data ostatniej aktualizacji: [data]
Status zgodności: Serwis jest częściowo zgodny z WCAG 2.2 na poziomie AA z powodu niezgodności wymienionych poniżej.
Elementy niedostępne:
[Lista konkretnych elementów z opisem problemu i planowanym terminem naprawy]
Zgłaszanie problemów z dostępnością:
Email: [adres]
Formularz: [URL]
Odpowiadamy w ciągu [liczba] dni roboczych.
Procedura odwoławcza:
W przypadku nierozpatrzenia Twojego zgłoszenia masz prawo skontaktować się z właściwym organem nadzorczym lub dochodzić swoich praw na drodze sądowej zgodnie z przepisami prawa.
Błędy, które widzimy najczęściej
Pierwszym i najczęstszym błędem jest kopiowanie deklaracji z BIP instytucji publicznych. Te dokumenty powołują się na ustawę o dostępności cyfrowej podmiotów realizujących zadania publiczne — czyli na przepis, który sklepów prywatnych nie dotyczy. Efekt: dokument zawiera błędną podstawę prawną i myli użytkownika szukającego informacji o swoich prawach.
Drugi błąd to podawanie daty „sporządzenia” dokumentu sprzed kilku lat bez żadnej aktualizacji. Strona się zmienia, nowe funkcje są wdrażane, stare problemy są naprawiane — ale dokument opisuje stan z 2021 roku. Taka deklaracja jest formalnie przeterminowana i może wprowadzać użytkownika w błąd co do aktualnego stanu dostępności serwisu.
Trzeci błąd, coraz częstszy, to dokumenty wygenerowane przez narzędzia AI bez weryfikacji. Model językowy nie zna Twojego serwisu, nie przeprowadził audytu i nie wie, które elementy są niedostępne. Wygeneruje poprawnie wyglądający tekst, który jednak będzie fikcją — i to fikcją, którą Twoja firma podpisuje swoją nazwą.
