Szablon raportu dostępności — co powinien zawierać dobry raport
„Raport dostępności“ oznacza co najmniej trzy różne artefakty w zależności od tego, kto je zlecił, a przepaść między nimi jest wystarczająco szeroka, by kierownik ds. zamówień i lider inżynieryjny, siedzący na tym samym spotkaniu, wyszli z niego oczekując zupełnie różnych dokumentów. Sformułowanie to obejmuje: automatyczny PDF generowany przez axe DevTools lub skan WAVE wypuszczany z pipeline’u budowania; 60-stronicowy raport ręczny, który specjalistyczna firma dostarcza po sześciotygodniowym audycie; oraz branżowe raporty zbiorcze, takie jak WebAIM Million i pierwsze zestawienia egzekwowania przepisów EAA.
Niniejszy artykuł dotyczy dwóch pierwszych — artefaktu, który się zleca, recenzuje, zatwierdza i przekazuje zespołowi deweloperów. Poniżej przedstawiono strukturę użytecznego raportu, skalę oceny ważności oddzielającą sprawnie działający raport od stosu nieklasyfikowalnych znaczników oraz format ustaleń, które zespoły inżynierskie faktycznie będą triage’ować. Połowa raportów trafiających na biurka kierowników ds. dostępności w 2026 roku nie przechodzi testu opisanego poniżej — i niemal zawsze jest to ten sam błąd: brak zakresu, brak skali, brak planu działań, brak werdyktu — jedynie długa lista odwołań do WCAG i słowo „wysoki“ powtórzone w kolumnie.
Automatyczne raporty ze skanera, ręczne raporty z audytu i branżowe raporty roczne to trzy odrębne artefakty. Poniższy przewodnik kataloguje dziewięć sekcji, które sprawiają, że produkt dostarczany jest użyteczny — każda sekcja opisana według identycznego schematu: zawartość, przykładowe sformułowanie, uzasadnienie, docelowi odbiorcy oraz to, czy sekcja jest obowiązkowa, czy zalecana. Katalog można czytać od początku do końca lub przejść bezpośrednio do wybranej sekcji.
9 sekcji · co powinien zawierać każdy dobry raport dostępności
| ID | Sekcja | Zadanie | Wymagana? |
|---|---|---|---|
| E·01 | Podsumowanie dla kierownictwa | Jednostronicowy werdykt o stanie zgodności dla sponsorów | Obowiązkowa |
| E·02 | Opis zakresu | Co było testowane — i co było poza zakresem | Obowiązkowa |
| E·03 | Metodologia | Standard, typ audytu, narzędzia, wersje | Obowiązkowa |
| E·04 | Werdykt zgodności | Zaliczone / niezaliczone / nie dotyczy dla każdego kryterium sukcesu | Obowiązkowa |
| E·05 | Ustalenia — lista problemów | Każdy defekt z ID, SC, ważnością i sposobem naprawy | Obowiązkowa |
| E·06 | Skala oceny ważności | Zdefiniowane znaczenie blokera / głównego / drugorzędnego | Obowiązkowa |
| E·07 | Plan usuwania barier | Priorytety napraw z szacunkami nakładu pracy | Obowiązkowa |
| E·08 | Polityka ponownego testowania | Harmonogram i wyzwalacze ponownej walidacji | Obowiązkowa |
| E·09 | Szablon deklaracji dostępności | Projekt publicznej deklaracji gotowy do publikacji | Obowiązkowa |
Wymagana = ujęta zarówno w raportach ze skanera automatycznego, jak i ręcznych raportach z audytu, z zastrzeżeniem, że skanery automatycznie generują szkic lub pomijają E·01, E·02, E·07 i E·09, ponieważ te sekcje wymagają oceny człowieka. Format każdej sekcji należy do audytora; obecność wszystkich dziewięciu decyduje o użyteczności produktu dostarczanego.
Trzy rodzaje raportu dostępności — i który jest potrzebny
Terminologia ma znaczenie, bo dostawcy celowo zacierają granice między kategoriami. Pod tą samą nazwą sprzedawane są trzy odrębne artefakty, które odpowiadają na różne pytania.
Raport ze skanera automatycznego. Generowany przez narzędzie — axe DevTools, WAVE, Lighthouse, Pa11y lub bezpłatny skaner dostępności na tej stronie. Gotowy w kilka minut. Pokrywa mniej więcej 60–70 procent kryteriów sukcesu WCAG 2.2 pod względem powierzchni, ale znacznie mniej pod względem wpływu na użytkownika, bo najpoważniejsze w skutkach błędy — pułapki klawiaturowe, jakość kolejności fokusa, czytelność dla czytnika ekranu, sensowny tekst alternatywny — w dużej mierze wykraczają poza możliwości analizy statycznej. Przydatny jako punkt wyjścia i zabezpieczenie przed regresją w CI, ale nie jako kompletny raport.
Ręczny raport z audytu. Zlecany specjalistycznej firmie lub przygotowywany wewnętrznie, najlepiej po przeprowadzeniu ręcznego audytu przez testerów z niepełnosprawnościami. Zajmuje cztery do ośmiu tygodni. Pokrywa te 30–40 procent wymagań WCAG, których automatyzacja nie wychwytuje, plus ludzką ocenę reszty. To artefakt, który pozwala ustalić zasadną prawnie pozycję zgodności na podstawie ADA tytuł III lub EAA i który napędza plan usuwania barier dostępności.
Branżowy raport roczny. WebAIM Million, Benchmark eGovernment UE, zestawienia egzekwowania EAA z pierwszego roku. Kontekst sektorowy — nie zastępuje testowania własnej strony.
Jeśli interesariusz mówi „potrzebujemy raportu dostępności“ bez doprecyzowania, o który rodzaj chodzi, należy zapytać. Różnica kosztów między tymi trzema jest mniej więcej cztery rzędy wielkości.
Raport pomijający zakres, skalę oceny ważności lub werdykt jest aktywnie wprowadzający w błąd — czytelnik nie może stwierdzić, co było testowane, co oznacza „ważność“ ani czy strona spełnia wymagania.
Każdy wpis poniżej opisuje te same elementy w tej samej kolejności: zawartość, przykładowe sformułowanie, uzasadnienie, docelowi odbiorcy oraz to, czy jest obowiązkowy. Raport bez którejkolwiek z dziewięciu sekcji jest niekompletny; raport bez E·02, E·04 lub E·06 jest bezużyteczny.
Podsumowanie dla kierownictwa
Jeden akapit, prostym językiem, bez żargonu. Elementem niezbędnym jest werdykt o stanie zgodności — jedno zdanie informujące sponsora projektu, czy strona spełnia, częściowo spełnia, czy nie spełnia wymagań wskazanego standardu. Poniżej werdyktu: trzy do pięciu zdań podających standard, okno audytu, liczbę ustaleń blokujących i główny wniosek z planu usuwania barier.
Sponsorzy projektu potrzebują werdyktu, a nie pomiaru temperatury. Podsumowanie to jedyna strona, którą otwiera większość niespecjalistycznych czytelników, i raport, który zakopuje ocenę stanu zgodności pod dwunastoma stronami preambuły metodologicznej, nie spełnia swojego głównego zadania. Zdanie z werdyktem to również to, co organy regulacyjne i kierownicy ds. zamówień cytują, odwołując się do raportu.
Opis zakresu
Co było testowane — adresy URL, typy stron, ścieżki użytkownika, urządzenia, przeglądarki, technologie wspomagające. I co było poza zakresem — strony chronione logowaniem niedostępne dla konta testowego, PDF-y, natywne aplikacje mobilne, osadzone zasoby stron trzecich. Każda wykluczona powierzchnia jest nazwana z podaniem przyczyny wykluczenia (poza budżetem, brak danych testowych, odroczone do kolejnego zlecenia).
Opis zakresu uniemożliwia podważenie audytu rocznego na podstawie kwestii proceduralnych. Bez niego zgłoszenie zgodności jest niepodważalne — powód może wskazać dowolną niebadaną powierzchnię i twierdzić, że raport milczy na jej temat, a strona pozwana nie może wykazać inaczej. Opis zakresu ogranicza również odpowiedzialność audytora: wykluczenie, które zostało nazwane, to wykluczenie zaakceptowane przez audytowaną organizację.
Metodologia
Który standard — WCAG 2.2 AA, WCAG 2.1 AA, EN 301 549 v3.2.1, Section 508. Jaki typ audytu — automatyczny, ręczny, mieszany. Jakie narzędzia i w jakich wersjach — axe-core 4.x, NVDA 2025.1, VoiceOver iOS 18, JAWS 2025. Jakie podejście testowe — przejście próbkowane WCAG-EM, przegląd wszystkich szablonów, testowanie oparte na ścieżkach.
Metodologia pozwala porównać ponowne testowanie po sześciu miesiącach na podobnych zasadach. Bez nazwy wersji narzędzia nie można odróżnić regresji od artefaktu aktualizacji narzędzia. Bez nazwy standardu zgłoszenie „zgodności“ jest nieinterpretowalne. Sekcja metodologii to także miejsce, w którym inni audytorzy oceniają kompetencje autora raportu.
Werdykt zgodności
Formalne stwierdzenie zgodności, według kryterium sukcesu, w trzech stanach: zaliczone, niezaliczone, nie dotyczy. WCAG 2.2 AA obejmuje 55 kryteriów sukcesu — każde z nich powinno znaleźć się w tej tabeli. „Nie dotyczy“ to prawomocny werdykt — strona bez wideo nie musi spełniać kryterium 1.2.2 Napisy rozszerzone — lecz każde „nie dotyczy“ wymaga jednowierszowego uzasadnienia.
Organy regulacyjne i prawnicy reprezentujący powodów czytają to jako pierwsze. Raport, który rozmywa werdykt — „w zasadzie zgodny“, „w zasadniczej zgodności“, „w drodze do dostępności“ — to raport, który przegrywa przed Departamentem Sprawiedliwości lub krajowym organem egzekwowania EAA. Tabela werdyktu jest też wejściem do publicznej deklaracji dostępności, dlatego rozmyta tabela daje rozmytą deklarację.
Ustalenia — lista problemów
Najdłuższa sekcja każdego rzeczywistego raportu. Każde ustalenie otrzymuje własny wiersz ze stabilnym ID, kryterium sukcesu WCAG, ważnością, lokalizacją, opisem, wpływem na użytkownika i zalecaną naprawą. Format jest opisany w sekcji „format ustaleń“ poniżej. Ustalenia są grupowane według szablonu lub ważności, uszeregowane według priorytetu usuwania barier i powiązane odsyłaczami z tabelą werdyktu zgodności.
Lista ustaleń to część, którą faktycznie otwiera zespół inżynieryjny. Raport, który ukrywa ustalenia w tekście ciągłym, nigdy nie zostanie poddany triage’owi; raport, który dostarcza je jako wiersze ze stabilnymi ID, staje się zaległościami do obsłużenia jako zgłoszenia. Stabilne ID to kluczowy element — pozwala odwołać się do tego samego ustalenia w tabeli werdyktu, planie działań i raporcie z ponownego testowania rok później.
Skala oceny ważności
Zdefiniowana skala wskazująca, co oznaczają w danym raporcie pojęcia: bloker, główne i drugorzędne. Bez skali ważności są tylko odczuciami. Zalecana skala trójstopniowa — zakotwiczona we wpływie na użytkownika, a nie w pewności skanera czy narażeniu prawnym — jest opisana w dalszej sekcji o skali.
Bez skali „wysoka ważność“ oznacza to, co czytelnik sam sobie dopowiada, a kolumna ważności staje się dekoracyjna. Ze skalą „bloker“ oznacza to samo w ustaleniu F-001 co w ustaleniu F-247, a plan działań może racjonalnie ustalać priorytety. Skala uniemożliwia też rozszerzanie zakresu podczas ponownych testów — ustalenie nie może być po cichu przeklasyfikowane między cyklami, jeśli jego definicja ważności jest zapisana na papierze.
Plan usuwania barier
Priorytety napraw z szacunkami nakładu pracy. Najpierw blokery, potem główne, potem drugorzędne; w obrębie każdego poziomu — najpierw te, które powtarzają się w wielu szablonach. Szacunki mogą być przybliżone — małe, średnie, duże w roboczodniach inżyniera — ale muszą istnieć, bo plan działań zamienia raport w program pracy.
Raport bez planu działań to stos ustaleń bez instrukcji, co robić dalej, i audytowana organizacja po cichu go archiwizuje. Plan działań zamienia raport w program pracy, który można śledzić, wycenić i raportować w kolejnych kwartałach. To również artefakt, który przewodnik kupującego po monitorowaniu wskazuje jako dane wejściowe do konfiguracji ciągłego monitorowania.
Polityka ponownego testowania
Kiedy raport zostanie zwalidowany ponownie, co wyzwala ponowne testowanie poza harmonogramem i które ustalenia zostaną ponownie przetestowane. Roczny pełny audyt uzupełniony ponownym testowaniem wcześniej niezaliczonych kryteriów po sześciu miesiącach jest uzasadniony dla większości stron; produkty dostarczane codziennie wymagają krótszego cyklu.
Raport bez harmonogramu ponownego testowania po cichu traci aktualność w ciągu dwunastu miesięcy. Unijna Dyrektywa w sprawie dostępności stron internetowych oczekuje corocznego odświeżania publikowanych deklaracji; zarówno EAA, jak i zasady DOJ dotyczące tytułu II traktują nieaktualizowane audyty jako dowód, że organizacja przestała zwracać na to uwagę. Nazwany harmonogram chroni też audytora przed przyszłym klientem pytającym, dlaczego poprzedni raport nie wychwycił regresji, która pojawiła się dwa miesiące po zamknięciu okna audytu.
Szablon deklaracji dostępności
Projekt publicznej deklaracji napisany na podstawie ustaleń audytu, gotowy do opublikowania pod adresem /accessibility/. Audytor dysponuje faktami, więc audytor redaguje deklarację; audytowana organizacja przegląda i publikuje. Przykłady tego, jak opublikowane deklaracje różnią się jakością, prezentuje audyt deklaracji dostępności obejmujący 100 najczęściej cytowanych w 2026 roku.
Deklaracja to publiczna twarz raportu i jedyny dokument, który zobaczy większość użytkowników. Przygotowanie jej jako części raportu — zamiast pozostawiania audytowanej organizacji tłumaczenia ustaleń na język publiczny sześć miesięcy później — zamyka pętlę między audytem a publiczną pozycją zgodności. To również artefakt wymaganej zgodności z EAA na podstawie artykułu 7 i jeden z dokumentów, które zasady DOJ dotyczące tytułu II z 2024 roku oczekują być dostępnym na żądanie.
Skala oceny ważności, która rzeczywiście działa
Większość raportów posługuje się pojęciami „wysoka / średnia / niska“ bez definiowania ich znaczenia, co czyni kolumnę ważności dekoracyjną zamiast kluczowej. Działająca skala jest zakotwiczona we wpływie na użytkownika — nie w pewności skanera ani w narażeniu prawnym.
Bloker. Użytkownicy z daną niepełnosprawnością nie mogą w ogóle ukończyć procesu. Pułapka klawiaturowa w trakcie płatności. Czytnik ekranu, który nie ogłasza krytycznego pola formularza. Modal przechwytujący fokus, którego nie można zamknąć bez myszy. Użytkownik musi zrezygnować lub poprosić o pomoc.
Główne. Użytkownicy mogą ukończyć proces, ale ze znacznym wysiłkiem lub z istotnie mniejszą ilością informacji niż użytkownik widzący i posługujący się myszą. Kolejność fokusa skacząca nieprzewidywalnie. Komunikaty o błędach pojawiające się wizualnie, ale nieogłaszane. Kontrast poniżej 4,5:1 na dużych fragmentach strony. Proces kończy się, ale doświadczenie jest istotnie pogorszone.
Drugorzędne. Problem dostępności, który nie blokuje procesu ani nie degraduje go w istotny sposób. Dekoracyjny obraz bez alt="". Punkt orientacyjny bez etykiety. Problem dotyczący wyłącznie poziomu AAA, zgłoszony informacyjnie. Należy uwzględnić w raporcie, ale trafia na koniec kolejki usuwania barier.
Uwaga dotycząca ważności prawnej. Niektóre działy prawne postulują równoległy poziom „ważności prawnej“ ważony narażeniem na pozwy zbiorowe zamiast wpływem na użytkownika. To dopuszczalne — ale należy zachować go jako oddzielną kolumnę. Łączenie obu produkt raportu, któremu zespół deweloperski nie ufa, a prawnicy nadmiernie na nim polegają.
Format ustaleń, z którym zespoły inżynierskie faktycznie pracują
Ustalenie to wiersz, a nie akapit. Wymagane pola:
| Pole | Przykład |
|---|---|
| ID ustalenia | F-014 |
| Kryterium sukcesu WCAG | 1.4.3 Kontrast (minimalny) |
| Ważność | Główne |
| Lokalizacja | https://example.com/checkout — button.cta-primary (patrz zrzut ekranu F-014.png) |
| Opis | Tekst głównego CTA renderowany jest przy współczynniku 3,2:1 na pomarańczowym tle; WCAG AA wymaga 4,5:1. |
| Wpływ na użytkownika | Użytkownicy słabowidzący i użytkownicy w jasnym świetle dziennym nie mogą odczytać etykiety przycisku. |
| Zalecana naprawa | Przyciemnienie tokenu tła z #F2994A do #C95F0A lub zmiana koloru tekstu na ciemny granat. |
Każdy wiersz, w którym brakuje zdania o wpływie na użytkownika, zostanie zdepriorytetyzowany przez inżynierów pytających „co to właściwie psuje?“. Każdy wiersz bez zalecanej naprawy zostanie zdepriorytetyzowany przez kierowników produktu pytających „co mamy zrobić?“. Raport, który przechodzi triage, naprawia problemy; raport, który nie przechodzi, to stos znaczników ważności.
Wersja „wynik ze skanera“ — co jest inne
W przypadku raportu ze skanera automatycznego — PDF generowany przez przebieg CI, bezpłatny skaner dostępności lub platformę monitorującą — sekcje E·01, E·02, E·07 i E·09 zwykle są nieobecne lub automatycznie szkicowane. Wartość raportu ze skanera tkwi w E·04 i E·05: odczytywalnej maszynowo liście niezaliczonych kryteriów sukcesu i ustaleń powiązanych z selektorami DOM. Skaner nie jest w stanie sporządzić użytecznego podsumowania dla kierownictwa, nie może podjąć decyzji o zakresie, nie może nadać priorytetów planu działań i nie może napisać deklaracji, pod którą prawnik by się podpisał.
To w porządku — raport ze skanera to surowe dane wejściowe do kompletnego raportu dostępności, a nie jego zamiennik. Niektóre platformy monitorujące dokładają teraz brakujące sekcje do wyników skanowania; to bliżej kompletnego artefaktu, ale podsumowanie i plan działań nadal wymagają ludzkiej oceny przed publikacją.
Szablon do pobrania
Działający szablon w formacie markdown odwzorowuje jeden do jednego dziewięć sekcji opisanych powyżej:
# Raport dostępności — [Strona] — [Data]## Podsumowanie dla kierownictwa— jeden akapit wraz ze zdaniem zawierającym werdykt## Zakres— adresy URL, ścieżki, urządzenia, technologie wspomagające; jawna lista elementów poza zakresem## Metodologia— standard, typ audytu, narzędzia, wersje## Werdykt zgodności— tabela wszystkich 55 kryteriów sukcesu WCAG 2.2 AA z oceną zaliczone / niezaliczone / nie dotyczy## Ustalenia— jeden nagłówek podrzędny na ustalenie, pola zgodnie z formatem powyżej## Skala oceny ważności— definicje blokera / głównego / drugorzędnego użyte w raporcie## Plan usuwania barier— lista priorytetów z szacowaniem nakładu pracy## Polityka ponownego testowania— harmonogram i wyzwalacze## Deklaracja dostępności (projekt)— wersja gotowa do publikacji
W przyszłej wersji tej strony znajdą się pliki .md i .docx do pobrania; na razie powyższa struktura jest kanonicznym odniesieniem. Audyt deklaracji dostępności pokazuje, jak różnią się 100 najlepszych deklaracji — luka między dobrymi a złymi ściśle odpowiada temu, czy raport stanowiący ich podstawę zawierał zdefiniowany zakres i rzeczywistą skalę oceny ważności.
Co łączy te 9 sekcji
Każda z dziewięciu sekcji wykonuje to samo podstawowe zadanie: przekształca fragment dowodu w fragment języka, który można zacytować, zbadać i postawić audytowanej organizacji za dwanaście miesięcy. Podsumowanie dla kierownictwa zamienia 60-stronicową ocenę w werdykt. Opis zakresu zamienia faktyczne pokrycie audytora w niepodważalne ograniczenie. Metodologia zamienia proces w powtarzalny punkt odniesienia dla porównań. Tabela werdyktu zamienia zgodność z WCAG w 55 atomowych twierdzeń. Ustalenia zamieniają defekty w wiersze do triage’u. Skala zamienia ważność z odczucia w definicję. Plan działań zamienia ustalenia w program pracy. Polityka ponownego testowania zamienia raport z migawki w cykl. Szablon deklaracji zamienia wewnętrzny raport w publiczną pozycję zgodności.
Raporty, które zawodzą w 2026 roku, zawodzą, bo pomijają krok przekształcania. Cytują numer kryterium sukcesu WCAG bez tłumaczenia, co to właściwie psuje dla jakich użytkowników. Oznaczają ustalenia jako „wysoka“ bez tłumaczenia „wysokiej“ na definicję. Podają werdykt bez zakresu, do którego się odnosi. Każdy brakujący krok przekształcania to miejsce, w którym raport staje się niepodważalny — a niepodważalny raport dostępności nie jest produktem dostarczanym, lecz artefaktem marketingowym.
Głębszy wzorzec polega na tym, że raport dostępności jest czytany z czterech zupełnie różnych odległości. Sponsor projektu czyta E·01 i nigdy nie wraca. Kierownik ds. zamówień czyta E·02, E·03 i E·09. Lider inżynieryjny czyta E·05, E·06 i E·07. Audytor czytający raport dwanaście miesięcy później czyta E·03, E·04 i E·08. Raport, który nie działa ze wszystkich czterech odległości, zawodzi co najmniej jednego z tych czytelników, a czytelnik, który zawodzi, to zwykle ten dysponujący budżetem.
Co zrobić najpierw
Działania praktyczne dla kierowników ds. dostępności w 2026 roku
- Uruchomić bezpłatny skaner dostępności na trzech reprezentatywnych szablonach, by uzyskać wyjściową listę ustaleń w formacie sekcji E·05 — to minimalny użyteczny artefakt, i to bez kosztów.
- Zlecić ręczny audyt przez testerów z niepełnosprawnościami w celu uzyskania kompletnego dziewięciosegmentowego raportu. Nalegać na E·02, E·06 i E·07 jako kryteria odbioru produktu.
- Opublikować projekt deklaracji dostępności z E·09 pod adresem
/accessibility/w ciągu czterech tygodni od dostarczenia raportu. Nie pozwalać, by leżała nieopublikowana. - Wdrożyć ciągłe monitorowanie zgodnie z przewodnikiem kupującego po monitorowaniu, by wychwytywać regresje między rocznym raportem a ponownym testowaniem po sześciu miesiącach.
- Wpisać ponowne testowanie z E·08 do kalendarza inżynieryjnego — nie prawnego — i traktować je jako bramkę wydania.
Użyteczny raport dostępności to taki, który organ regulacyjny może przeczytać w pięć minut (E·01, E·02, E·04), inżynier może poddać triage’owi w jednym sprincie (E·05, E·06, E·07), a audytor może powtórzyć za rok (E·03, E·08). Bezużyteczny to taki, który cytuje numery kryteriów WCAG bez tłumaczenia ich na język, na którym którykolwiek z tych czytelników może działać. Połowa raportów trafiających na biurka kierowników ds. dostępności w 2026 roku nie przechodzi tego testu — i niemal zawsze jest to ten sam błąd: brak zakresu, brak skali, brak planu działań, brak werdyktu.
Uruchom bezpłatny skaner WCAG 2.2, by uzyskać automatyczny punkt wyjścia w formacie sekcji E·05, a następnie zleć ręczny audyt dla pozostałych sześciu sekcji.
Otwórz skaner →Najczęściej zadawane pytania
Co powinien zawierać raport dostępności?
Kompletny raport zawiera dziewięć sekcji: podsumowanie dla kierownictwa z werdyktem o stanie zgodności, opis zakresu, sekcję metodologiczną podającą standard i narzędzia, werdykt zgodności według kryterium sukcesu, listę ustaleń, skalę oceny ważności, plan usuwania barier z szacunkami nakładu pracy, politykę ponownego testowania oraz projekt deklaracji dostępności. Raport bez zakresu, skali lub werdyktu jest bezużyteczny — czytelnik nie może stwierdzić, co było testowane, co oznacza „ważność“ ani czy strona spełnia wymagania.
Jaka jest różnica między raportem a deklaracją dostępności?
Raport dostępności to wewnętrzny produkt dostarczany — zwykle 30 do 80 stron — dokumentujący ustalenia audytu, ważności i plan działań. Deklaracja dostępności to krótka, publiczna strona pod adresem /accessibility/ podsumowująca stan zgodności, standard, datę audytu, znane wyjątki i sposób kontaktu dla użytkowników, którzy napotkali barierę. Raport produkuje deklarację; deklaracja nie jest raportem.
Jak długi jest typowy raport dostępności?
Ręczny raport z audytu małej strony marketingowej liczy 25 do 40 stron. Raport dla złożonego produktu z uwierzytelnianiem i wieloma ścieżkami może osiągnąć 80 do 150 stron, bo sekcja ustaleń rośnie wraz z liczbą przeglądanych szablonów. Sekcje narracyjne łącznie zajmują mniej więcej 10 do 15 stron niezależnie od wielkości strony. Reszta to ustalenia.
Czy raporty ze skanerów dostępności są wystarczające prawnie?
Nie. Ani zasady DOJ dotyczące tytułu II z 2024 roku, ani Europejski Akt o Dostępności (EAA) nie traktują wyników ze skanera automatycznego jako kompletnego raportu dostępności. Skanery wykrywają mniej więcej 30 do 40 procent problemów z WCAG — głównie kontrast, brakujący tekst alternatywny, brakujące etykiety i strukturę dokumentu. Pozostałe 60 do 70 procent wymaga oceny człowieka. Raport ze skanera to surowe dane wejściowe do pełnego raportu, nie jego zamiennik.
Jak często należy wydawać ponownie raport dostępności?
Pełny cykl ręcznego audytu i raportu co dwanaście miesięcy to roboczy punkt wyjścia dla większości stron. Ponowne testowanie wcześniej niezaliczonych kryteriów po sześciu miesiącach to dobra praktyka. Każda istotna zmiana szablonu, przeprojektowanie lub migracja frameworka powinna wyzwolić audyt różnicowy. Ciągłe monitorowanie działa między raportami, by regresje były wykrywane natychmiast.
Czy WCAG wymaga określonego formatu raportu?
Nie. WCAG określa kryteria sukcesu; nie narzuca formatu żadnego produktu dostarczanego audytu. W3C publikuje EARL i WCAG-EM jako strukturalne punkty odniesienia, ale żaden z nich nie jest obowiązkowy na podstawie ADA, EAA, AODA ani żadnego innego reżimu. Przepisy wymagają, by raport podał standard, zakres, metodologię i werdykt — format wokół tych faktów należy do audytora.
MetodologiaModel sekcji wywodzi się z metodologii oceny WCAG-EM, materiałów referencyjnych IAAP dotyczących raportów z audytów i ponad 30 opublikowanych deklaracji dostępności zbadanych w /articles/accessibility-statement-audit-top-100/.
ZakresNiniejszy artykuł stanowi przewodnik po formacie raportu, a nie prawną listę kontrolną zgodności. W kwestii obowiązków sprawozdawczych właściwych dla danej jurysdykcji na podstawie ADA tytuł III, EAA lub innych obowiązujących przepisów zaleca się konsultację z właściwym prawnikiem.