Wzór raportu z audytu dostępności cyfrowej: struktura, wyniki, zalecenia

Rola raportu z audytu dostępności cyfrowej w dokumentacji urzędowej

Raport jako podstawa dowodowa, zarządcza i komunikacyjna

Raport z audytu dostępności cyfrowej pełni jednocześnie trzy funkcje: dowodową, zarządczą oraz komunikacyjną. Dobrze zaprojektowany wzór raportu pozwala po latach wykazać, że podmiot realnie dbał o dostępność, a nie reagował wyłącznie na doraźne kontrole. Stanowi także materiał roboczy dla kierownictwa i zespołów technicznych przy planowaniu kolejnych wdrożeń, modyfikacji systemów czy budżetów.

Funkcja dowodowa to przede wszystkim możliwość okazania dokumentu podczas kontroli (np. PFRON, Najwyższa Izba Kontroli, wewnętrzny audyt). Raport z audytu dostępności cyfrowej pokazuje, że badanie miało określony zakres, stosowano konkretną metodykę i odnotowano wyniki w sposób oparty na standardach WCAG. Brak takiego dokumentu powoduje, że jednostka ma problem z udowodnieniem, iż realnie badała swoje serwisy i systemy.

W wymiarze zarządczym raport staje się materiałem do podejmowania decyzji: które działania naprawcze są priorytetowe, jak alokować zasoby, kiedy planować kolejne etapy prac. Kierownictwo patrzy w pierwszej kolejności na część podsumowującą oraz plan działań, a dopiero później – jeśli w ogóle – sięga do szczegółowych opisów błędów. Wzór raportu z audytu dostępności cyfrowej powinien więc zakładać logiczny podział na warstwy: ogólną (strategiczną) i szczegółową (techniczną).

Komunikacyjnie raport jest punktem odniesienia dla wielu zespołów: IT, redakcji BIP, działu komunikacji, pełnomocnika ds. dostępności, a czasem także wykonawców zewnętrznych. Zbyt techniczny dokument bywa niezrozumiały dla osób odpowiedzialnych za treści, natomiast zbyt ogólny – bezużyteczny dla programistów. Stąd potrzeba takiej struktury raportu, która pozwoli każdej grupie odnaleźć „swoje” informacje bez zagłębiania się w całość.

Różnica między raportem z audytu, oświadczeniem o dostępności i planem działań

Trzy dokumenty, które często są mylone, to: raport z audytu dostępności cyfrowej, oświadczenie o dostępności i plan działań naprawczych. Każdy z nich ma inną funkcję i inny poziom szczegółowości. Raport jest punktem wyjścia – to on zawiera kompletną diagnozę stanu dostępności: opis metodyki, wyników i niezgodności z WCAG oraz zalecenia. Oświadczenie o dostępności to skrócony, ustandaryzowany komunikat publikowany w BIP lub na stronie internetowej.

Oświadczenie nie zastępuje raportu. Opiera się na jego wnioskach, ale ma z góry określony zakres treści: poziom zgodności (zgodna/częściowo zgodna/niezgodna), informacje o wyłączeniach, procedurę żądania dostępności oraz dane kontaktowe. Z kolei plan działań naprawczych jest dokumentem operacyjnym. Bazuje na liście niezgodności z raportu i wskazuje konkretne zadania, terminy, odpowiedzialnych oraz szacowany nakład pracy. W praktyce plan działań może funkcjonować jako osobny dokument lub jako wyodrębniona sekcja końcowa raportu.

Różnice między tymi trzema dokumentami pomagają uporządkować proces: najpierw rzetelny audyt i raport, następnie przygotowanie oświadczenia o dostępności dla użytkowników, a równolegle opracowanie planu działań naprawczych dla zespołów. Próba połączenia wszystkiego w jeden skrócony materiał zwykle prowadzi do chaosu: oświadczenie staje się zbyt techniczne, a raport – zbyt ogólnikowy.

Miejsce raportu w systemie dokumentów: BIP, polityki i rejestry ryzyka

W administracji publicznej raport z audytu dostępności cyfrowej nie powinien „leżeć w szufladzie”. Najczęściej jest on powiązany z kilkoma obszarami dokumentacji: BIP, polityką dostępności, polityką bezpieczeństwa informacji, planami cyfryzacji, rejestrami ryzyka oraz dokumentacją projektów IT. Każdy z tych dokumentów odwołuje się na swój sposób do dostępności, a raport z audytu dostarcza im aktualnej diagnozy.

Dla BIP raport jest bazą do przygotowania rzetelnego oświadczenia o dostępności oraz do uzasadniania ewentualnych wyłączeń i planowanych dat usunięcia niezgodności. W polityce dostępności (jeśli jednostka ją przyjęła) raport pomaga wyznaczyć priorytety i wskaźniki realizacji celów. W planach cyfryzacji raport wskazuje obszary, w których przy kolejnych zamówieniach publicznych trzeba wyraźniej postawić wymagania dotyczące WCAG.

Bardzo użyteczne bywa powiązanie raportu z audytu dostępności cyfrowej z rejestrami ryzyka. Niezgodności o wysokim wpływie na użytkowników – np. brak dostępnych formularzy w kluczowym procesie – warto wpisać jako ryzyka operacyjne i monitorować ich redukcję. W dokumentacji projektów IT raport pełni rolę „wejściowego” dokumentu: pozwala ustalić, jakie wymagania dostępnościowe muszą być wpisane do zakresu projektu modernizacji lub wdrożenia nowego systemu.

Skutki dobrego raportu vs dokument „pod ustawę”

Różnica między dobrze przygotowanym raportem a dokumentem tworzonym jedynie „pod ustawę” jest wyraźna po kilku miesiącach. Rzetelny raport prowadzi do realnych zmian: ułatwia planowanie budżetu na dostępność, pozwala uniknąć kosztownych poprawek w ostatniej chwili i zmniejsza ryzyko sankcji. Zbyt lakoniczny raport zwykle kończy w archiwum, a serwis internetowy po roku wygląda tak samo jak wcześniej – tylko ryzyko wzrosło, bo rośnie również świadomość użytkowników.

Raport szczątkowy często ogranicza się do kilku ogólnych zdań: „Strona jest częściowo zgodna z WCAG, występują problemy z kontrastem i alternatywami tekstowymi”. Z perspektywy zespołu IT czy redakcji BIP to informacja bezużyteczna, bo nie wiadomo ani gdzie są problemy, ani jak duży jest ich wpływ, ani jakie działania są priorytetowe. W takiej sytuacji nawet przy dobrej woli trudno zaplanować sensowne prace naprawcze.

Dobry wzór raportu z audytu dostępności cyfrowej pozwala ustandaryzować podejście w całej organizacji: kolejne audyty mają podobną strukturę, co ułatwia porównywanie wyników w czasie i między serwisami. Kierownictwo widzi, jak zmienia się poziom dostępności, a pełnomocnik ds. dostępności może sensownie raportować postęp. Przy raportach „pod ustawę” taki nadzór jest praktycznie niemożliwy.

Wymogi prawne i standardy – punkt odniesienia dla wzoru raportu

Kluczowe źródła: ustawa, rozporządzenia, WCAG 2.1

Podstawą dla raportu z audytu dostępności cyfrowej są konkretne akty prawne i standardy. W polskich realiach punktem wyjścia jest ustawa o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych oraz powiązane rozporządzenia wykonawcze. Ustawa implementuje dyrektywę unijną i odsyła wprost do standardu WCAG 2.1 na poziomie co najmniej AA (z pewnymi wyjątkami).

Standard Web Content Accessibility Guidelines (WCAG) 2.1 opisuje kryteria sukcesu zgrupowane w cztery zasady: postrzegalność, funkcjonalność, zrozumiałość i solidność. Dla tworzenia wzoru raportu istotne są nie tylko same kryteria, ale również sposób ich oznaczania (np. 1.1.1, 2.4.3, 4.1.2) oraz poziom: A, AA, AAA. Raport z audytu dostępności cyfrowej powinien jednoznacznie wskazywać, do których kryteriów odnosi się każde stwierdzenie o zgodności lub niezgodności.

Rozporządzenia doprecyzowują m.in. sposób publikowania oświadczeń o dostępności, wymagane informacje oraz częstotliwość aktualizacji. Przy projektowaniu wzoru raportu warto przeanalizować wzór oświadczenia – tak, aby raport dostarczał danych w formie, którą łatwo przenieść do oświadczenia, zamiast każdorazowo interpretować wyniki audytu na nowo.

Elementy raportu konieczne do „obrony” audytu

Aby audyt dostępności cyfrowej można było obronić podczas kontroli zewnętrznej, w raporcie muszą znaleźć się określone informacje. Po pierwsze – zakres audytu: jakie serwisy, systemy, aplikacje, dokumenty i funkcjonalności zostały objęte badaniem, a co pozostało poza zakresem. Po drugie – metodyka: wykorzystane metody (testy eksperckie, automatyczne, z użytkownikami), narzędzia, konfiguracja środowiska i zastosowane kryteria oceny.

Kolejne elementy to daty i harmonogram audytu (kiedy wykonywano badania, czy obejmowały wersję produkcyjną, czy testową) oraz opis próby: czy audyt miał charakter pełny (badano wszystkie kluczowe podstrony i procesy), czy próbkowy (badano wybrane typy stron, formularzy, dokumentów PDF). Brak tych danych powoduje, że raport z audytu dostępności cyfrowej staje się trudny do interpretacji – zwłaszcza jeśli po pewnym czasie w serwisie wdrożono zmiany.

Istotne jest również wskazanie podmiotu wykonującego audyt (nazwa, dane kontaktowe, ewentualne kwalifikacje) oraz odbiorcy audytu (np. nazwa jednostki samorządu, departamentu, spółki komunalnej). Wzór raportu powinien mieć wydzielone miejsce na te informacje w części wstępnej, aby nie było wątpliwości, kto badał i na czyje zlecenie. W przypadku audytu wewnętrznego warto to wyraźnie odnotować.

Różne typy podmiotów zobowiązanych a zakres raportu

Administracja rządowa, samorządowa, jednostki podległe, podmioty lecznicze czy uczelnie publiczne mają wspólny mianownik – obowiązek zapewnienia dostępności cyfrowej. Jednak skala i specyfika ich serwisów jest inna. Wzór raportu z audytu dostępności cyfrowej powinien być elastyczny, by dało się go stosować zarówno dla małej gminy z jednym serwisem, jak i dla resortu z rozbudowanym portalem i wieloma systemami dziedzinowymi.

W małych jednostkach raport często obejmuje jeden serwis internetowy i kilka podstawowych formularzy oraz dokumentów. Zakres można wtedy opisać szczegółowo, wskazując wszystkie kluczowe podstrony. W dużych jednostkach częściej stosuje się podejście próbne: wybiera się reprezentatywne typy treści, procesów (np. wniosek o świadczenie, rejestracja, logowanie) oraz systemów (BIP, e-usługi, platforma edukacyjna). W raporcie trzeba jasno zaznaczyć, że badanie miało charakter próbkowy i jakie kryteria przyjęto przy wyborze próby.

Inaczej będzie wyglądał raport z audytu dostępności cyfrowej aplikacji mobilnej niż serwisu www. W aplikacji nacisk kładzie się na interakcje dotykowe, obsługę czytnika ekranu w środowisku mobilnym, gesty oraz odpowiednie oznaczenia elementów interfejsu. W serwisie www ważniejsze są np. nagłówki, kolejność fokusa, etykiety formularzy. Wzór raportu powinien zawierać sekcję, w której audytor wskazuje, jaki typ rozwiązania był badany.

Opis zgodności i niezgodności w spójności z oświadczeniem

Ustawa i rozporządzenia przewidują trzy kategorie ogólnego poziomu zgodności: „zgodna z ustawą”, „częściowo zgodna z ustawą” i „niezgodna z ustawą”. Raport z audytu dostępności cyfrowej powinien tak prezentować wyniki, aby łatwo było z nich wyprowadzić jedną z tych formuł. Oznacza to konieczność zliczenia kryteriów spełnionych i niespełnionych oraz oceny skali wpływu naruszeń na ogólne korzystanie z serwisu.

Warto wprowadzić w raporcie jasne definicje tych trzech kategorii na poziomie konkretnej strony lub funkcjonalności. Przykładowo: „zgodna” – brak stwierdzonych naruszeń kryteriów WCAG na poziomie A i AA; „częściowo zgodna” – występują naruszenia, ale dotyczą ograniczonej liczby funkcjonalności lub mają charakter umiarkowany; „niezgodna” – naruszenia uniemożliwiają skorzystanie z głównych usług lub dotyczą wielu kluczowych kryteriów.

Takie definicje pozwalają budować spójność między raportem a oświadczeniem. Jeśli raport na poziomie serwisu wskazuje liczne niezgodności w kluczowych procesach, to oświadczenie nie powinno mówić o „pełnej zgodności”. Z kolei, gdy pojedyncze drobne niezgodności nie wpływają realnie na korzystanie z serwisu, nie ma powodu, aby w oświadczeniu z góry deklarować „niezgodność”. Klarowne opisy w raporcie ułatwiają uczciwą ocenę.

Struktura raportu z audytu dostępności cyfrowej – przegląd od góry do dołu

Rozbudowany raport kontra raport operacyjny

Przy projektowaniu wzoru raportu z audytu dostępności cyfrowej pojawia się podstawowe pytanie: tworzyć dokument bardzo szczegółowy, czy raczej zorientowany na praktyczne działania? W praktyce warto odróżnić dwa podejścia. Raport rozbudowany zawiera pełną dokumentację audytu, z bogatymi opisami metodyki, obszerną tabelą kryteriów WCAG, przykładami kodu, zrzutami ekranu i szerokimi uzasadnieniami. Raport operacyjny skupia się na najważniejszych wynikach, podziale na priorytety i klarownym planie działań naprawczych.

Raport rozbudowany lepiej sprawdza się jako dokument na potrzeby archiwalne, przy dużych projektach modernizacyjnych oraz w sytuacji, kiedy audyt ma być podstawą do przetargu na poprawę dostępności. Umożliwia także dokładne porównywanie wyników między różnymi audytami (np. rok do roku). Minusem jest większa objętość i mniejsza przystępność dla osób nietechnicznych.

Raport operacyjny jest krótszy, ale za to bardziej „zadaniowy”. Na pierwszych stronach pojawia się lista kluczowych problemów, ich wpływ, rekomendowane działania i priorytety. Szczegółowe opisy są skrócone lub przeniesione do załączników. Taki raport dobrze sprawdza się tam, gdzie najważniejszym celem jest szybkie wdrożenie działań naprawczych, a nie szczegółowe dokumentowanie każdej niezgodności.

Warstwa zarządcza i techniczna – dwa „wejścia” do raportu

Przy układaniu struktury raportu przydaje się prosty podział: część zarządcza (strategiczna) i część techniczna (szczegółowa). Obie korzystają z tych samych danych, ale prezentują je z inną granulacją i innym językiem. W warstwie zarządczej pojawiają się podsumowania, wskaźniki, ryzyka i priorytety napraw, a w warstwie technicznej – konkretne kryteria WCAG, lokalizacje w interfejsie, przykłady kodu czy zrzuty ekranu.

W małych jednostkach sensowne jest połączenie tych warstw w jednym dokumencie, ale z wyraźnym rozdziałem rozdziałów. W dużych resortach lub uczelniach wygodniejsze bywa przygotowanie „streszczenia dla kierownictwa” jako samodzielnego materiału i odesłanie do pełnej dokumentacji audytu jako załącznika. Kluczowe jest to, by obie warstwy odnosiły się do tych samych identyfikatorów niezgodności – wtedy kierownik projektu bez problemu przejdzie od tabeli priorytetów do konkretnego zadania dla zespołu deweloperskiego.

Dobrą praktyką jest numeracja rozdziałów i podrozdziałów w sposób, który pozwala łatwo cytować fragmenty raportu w korespondencji i dokumentach projektowych. Jeśli zgłoszenie w systemie ticketowym odwołuje się do „niezgodności T-04, rozdział 5.2 raportu”, unikamy niejasności oraz dyskusji, czy mowa o tym samym problemie.

Rozdział o ryzykach i skutkach biznesowych

Dojrzały wzór raportu wykracza poza suche wyliczanie niezgodności technicznych. Przy każdej grupie problemów dobrze sprawdza się krótki opis ryzyka i skutków dla użytkowników, a także potencjalnych skutków prawnych dla organizacji. Taki rozdział „mostkuje” świat dostępności i świat zarządzania, pokazując, że błąd w etykiecie formularza to nie tylko problem dewelopera, ale też ryzyko dla realizacji usługi publicznej.

W praktyce można zestawić dwa poziomy skutków:

• Skutek dla użytkownika – np. „osoba korzystająca z czytnika ekranu nie jest w stanie samodzielnie złożyć wniosku o świadczenie”, „użytkownik z dysleksją gubi się w nawigacji”.
• Skutek dla organizacji – np. „wzrost liczby telefonów i wizyt osobistych w sprawach, które mogłyby zostać załatwione online”, „ryzyko skargi do Rzecznika Praw Obywatelskich lub kontroli organu nadzoru”.

Ten sam błąd może mieć niski ciężar techniczny (poprawka zajmie godzinę), a wysoki ciężar biznesowy (blokuje kluczowy proces). Zestawienie skutków ułatwia nadawanie priorytetów: zamiast „poprawmy wszystko po kolei”, pojawia się pytanie: „co w realny sposób uniemożliwia skorzystanie z usługi?”.

Łączenie raportu z planem działań naprawczych

Jedną z większych różnic między raportami „do szuflady” a raportami rzeczywiście używanymi w organizacji jest sposób, w jaki opisane są kroki naprawcze. W pierwszym przypadku audyt kończy się listą niezgodności bez odpowiedzi na pytanie: kto, kiedy i w jakim trybie ma je usunąć. W drugim – raport staje się podstawą planu projektu poprawy dostępności.

Praktycznym rozwiązaniem jest osobny rozdział lub załącznik „Plan działań naprawczych”, w którym każda niezgodność lub grupa niezgodności ma przypisane:

• priorytet (np. krytyczny, wysoki, średni, niski),
• proponowany termin usunięcia (realny, uwzględniający cykl życia systemu),
• typ kompetencji potrzebnych do wdrożenia poprawki (programista front-end, redaktor treści, dostawca zewnętrznego komponentu),
• szacowany nakład pracy w kategoriach jakościowych (drobna poprawka, zmiana średniej skali, przebudowa komponentu).

Im bardziej techniczny jest serwis, tym więcej szczegółów można umieścić bezpośrednio w raporcie. W urzędach o ograniczonych zasobach IT lepiej sprawdza się prostszy plan, który można potem przełożyć choćby na harmonogram w arkuszu kalkulacyjnym lub prostym narzędziu do zarządzania zadaniami.

Część wstępna raportu: identyfikacja, kontekst i cel audytu

Identyfikacja podmiotu, serwisu i wersji badanej

W części wstępnej raportu podstawową rolę odgrywa jednoznaczne wskazanie, czego dokładnie dotyczy audyt. Nie wystarczy nazwa urzędu i ogólne stwierdzenie „serwis www”. Precyzyjna identyfikacja zmniejsza ryzyko sporów po zmianach w systemie lub po kilku rundach modernizacji.

Dobrze przygotowany wzór raportu zawiera pola na:

• pełną nazwę podmiotu (zgodną z rejestrem, bez skrótów wewnętrznych),
• nazwę serwisu lub systemu (np. „Portal informacyjny Gminy X”, „Platforma e-usług zdrowotnych Y”),
• adres URL głównej strony lub stron logowania, w przypadku systemów zamkniętych,
• informację o wersji – np. numer wersji aplikacji mobilnej, datę ostatniej dużej aktualizacji, wersję szablonu graficznego.

W systemach rozwijanych ciągle, jak portale informacji publicznej czy platformy edukacyjne, przydaje się opis „stanu na dzień audytu”. Można to prosto ująć: „Badanie przeprowadzono na wersji produkcyjnej serwisu w kształcie z dnia 15 maja 2025 r., po wdrożeniu nowego układu strony głównej.” W kolejnych audytach takie adnotacje ułatwiają porównania.

Cel audytu: formalna zgodność czy zmiana praktyki?

Ten sam raport może mieć dwa różne cele: spełnienie wymogu ustawowego lub realne wsparcie procesu poprawy dostępności. W części wstępnej dobrze jest jasno zadeklarować priorytet, bo wpływa to na szczegółowość opisu i rozkład akcentów.

Najczęściej pojawiają się trzy warianty:

• Audyt formalny – skupia się na ocenie zgodności z ustawą i WCAG, tak aby umożliwić przygotowanie oświadczenia o dostępności. Raport kładzie nacisk na kategoryzację „zgodna / częściowo zgodna / niezgodna” oraz kompletną listę naruszeń.
• Audyt przedmodernizacyjny – wykonywany przed planowaną przebudową serwisu lub systemu. Raport ma wtedy bardziej diagnostyczny charakter: wskazuje główne problemy architektoniczne, które lepiej rozwiązać na etapie projektu, a nie „doklejać” poprawki po fakcie.
• Audyt weryfikujący postęp – porównuje stan obecny ze stanem po poprzednim audycie lub wdrożeniu poprawek. Wzór raportu powinien przewidywać miejsce na odniesienia do wcześniejszych ocen (np. w tabeli zgodności).

W praktyce wiele organizacji łączy te cele: audyt pełni funkcję formalną, a jednocześnie ma wskazać, jak efektywnie wydać środki na poprawę dostępności. Jasne zapisanie tego w części wstępnej pozwala audytorom dobrać odpowiednią głębokość analiz i uniknąć nieporozumień z zamawiającym.

Interesariusze – kto będzie korzystał z raportu

Przy pisaniu raportu inaczej dobiera się język, poziom szczegółu i przykłady w zależności od tego, kto będzie go czytał. Wzór raportu warto uzupełnić krótkim podrozdziałem, w którym audytor wskazuje główne grupy odbiorców dokumentu. Typowy zestaw obejmuje:

• kierownictwo – potrzebuje syntetycznego obrazu ryzyk, priorytetów i kosztów,
• pełnomocnika ds. dostępności – interesuje go zgodność z ustawą, wpływ na oświadczenie o dostępności i raportowanie do organów nadrzędnych,
• zespoły IT i dostawcy zewnętrzni – oczekują precyzyjnych opisów niezgodności i wskazówek technicznych,
• redaktorzy treści – potrzebują jasnych wytycznych redakcyjnych i przykładów dobrych oraz złych praktyk.

Jeśli raport ma być udostępniany publicznie, przydaje się też informacja o tym, które fragmenty są adresowane szerzej, a które mają charakter bardziej techniczny. Ułatwia to np. przygotowanie streszczenia dostępnego dla mieszkańców gminy lub studentów uczelni.

Zakres audytu i metodyka badania – jak to jasno opisać

Opis zakresu: pełny, próbny, problemowy

Zakres audytu można ująć na kilka sposobów. Najprostszy, ale najmniej użyteczny, to stwierdzenie „zbadano serwis X”. Dużo większą wartość dla zamawiającego i organów kontrolnych ma precyzyjny opis, który z jednej strony nie zostawia wątpliwości, a z drugiej – nie zamyka drogi do rozsądnego doboru próby.

Dobrym punktem wyjścia jest rozróżnienie trzech typów zakresu:

• Audyt pełny – obejmuje wszystkie kluczowe sekcje serwisu, typy treści i procesy użytkownika. Sprawdza się przy mniejszych serwisach informacyjnych oraz w sytuacji, gdy organizacja chce mieć „czyste konto” przed dużym przeglądem zewnętrznym.
• Audyt próbny – polega na zbadaniu reprezentatywnych podstron i funkcjonalności. Przy rozbudowanych portalach jest często jedynym realistycznym wariantem. Kluczowe staje się wtedy opisanie kryteriów doboru próby, np.: „wybrano po jednej stronie z każdego szablonu, po jednym formularzu z każdej grupy usług oraz wszystkie strony o najwyższej liczbie odsłon”.
• Audyt problemowy – koncentruje się na wybranym obszarze, który z jakiegoś powodu budzi wątpliwości (np. system rekrutacyjny, portal B2B, moduł e-płatności). Zastosowanie ma np. po skargach użytkowników lub po zmianach w jednym module systemu.

W raporcie warto wyraźnie zaznaczyć, na jakim typie zakresu opierał się audyt, tak aby nikt nie interpretował audytu próbnego jako pełnego. W praktyce często pojawia się formuła mieszana: audyt pełny dla głównego portalu i próbny dla powiązanych systemów dziedzinowych.

Katalog badanych elementów i procesów

Sam opis typu zakresu nie wystarcza. Wzór raportu powinien wymagać od audytora przygotowania katalogu badanych elementów, najlepiej w formie tabeli. W prostej wersji mogą to być kolumny:

• identyfikator elementu/procesu (np. S1, F3, D2),
• opis (np. „formularz: zgłoszenie urodzenia dziecka”, „podstrona: aktualności”, „dokument: statut gminy – PDF”),
• adres URL lub ścieżka nawigacyjna,
• typ urządzenia/środowisko (desktop, mobile, aplikacja mobilna), jeśli ma to znaczenie dla badania.

Przy kolejnych audytach ten katalog pozwala szybko sprawdzić, czy badano te same obszary, czy może zakres został rozszerzony lub zmieniony. W dużych organizacjach katalog elementów badanych dobrze jest zsynchronizować z wewnętrznym rejestrem systemów i usług cyfrowych.

Metody badawcze: eksperckie, automatyczne, z udziałem użytkowników

Metodyka audytu powinna być opisana tak, by osoba z zewnątrz mogła zrozumieć, jak uzyskano wyniki. W praktyce w większości audytów pojawia się kombinacja trzech podejść:

• Testy eksperckie – przeprowadzane ręcznie przez specjalistów ds. dostępności, którzy weryfikują kryteria WCAG dla wybranych stron i funkcjonalności. Dają największą głębię, ale wymagają czasu i kompetencji.
• Testy automatyczne – z użyciem narzędzi skanujących kod (wtyczki przeglądarkowe, skanery serwisów). Sprawdzają się przy identyfikacji powtarzalnych wzorców błędów (np. brak alternatyw tekstowych, kontrast, błędne struktury nagłówków), lecz nie zastępują analizy eksperckiej.
• Testy z udziałem użytkowników – sesje, w których osoby z niepełnosprawnościami wykonują konkretne zadania w systemie. Zapewniają najsilniejszy dowód występowania problemu, ale są najbardziej czasochłonne i trudniejsze w organizacji.

W dobrym wzorze raportu każda z zastosowanych metod powinna mieć opis: jaki był cel jej wykorzystania, na jakiej próbie została użyta (które strony, ile scenariuszy), jakie narzędzia wspierające zastosowano (np. czytniki ekranu, lupy ekranowe, narzędzia do pomiaru kontrastu). Dzięki temu raport nie jest „czarną skrzynką”, a jego wnioski można powtórzyć lub zweryfikować.

Środowisko testowe i konfiguracja urządzeń

Ten sam serwis może działać inaczej w różnych przeglądarkach, systemach operacyjnych czy na różnych typach urządzeń. W metodyce badania przydaje się krótki opis środowiska testowego: system operacyjny, wersje przeglądarek, typy urządzeń (desktop, tablet, smartfon), wykorzystywane technologie wspomagające (np. NVDA, JAWS, VoiceOver, TalkBack).

Nie chodzi o drobiazgowe listowanie każdej konfiguracji, lecz o wskazanie typowych scenariuszy. Przykładowo:

• Desktop: Windows, Chrome i Firefox, NVDA jako główny czytnik ekranu.
• Mobile: Android, Chrome, TalkBack; iOS, Safari, VoiceOver.

Dokumentacja przebiegu audytu i ograniczeń badania

Metody i zakres to jedno, ale administracja coraz częściej pyta także: czego nie sprawdzono i dlaczego. Wzór raportu powinien przewidywać osobny fragment na opis ograniczeń audytu. Bez tego łatwo o nieporozumienia, gdy po kilku miesiącach ktoś oczekuje odpowiedzi na pytania wykraczające poza pierwotne zlecenie.

Praktyczny schemat tego podrozdziału może wyglądać tak:

• Ograniczenia techniczne – np. brak dostępu do środowiska testowego, niemożność zalogowania się do części funkcji, blokady sieciowe uniemożliwiające skanowanie automatyczne.
• Ograniczenia czasowe – np. skrócony termin realizacji wymuszający zawężenie próby do najbardziej reprezentatywnych podstron.
• Ograniczenia organizacyjne – brak możliwości zorganizowania testów z udziałem użytkowników, brak zgody na analizę wybranych systemów dziedzinowych, przerwa techniczna w trakcie badania.

Równie istotna jest krótka dokumentacja przebiegu audytu: daty poszczególnych etapów, liczba spotkań roboczych, sposób przekazywania pytań do zespołu IT. Wzór raportu może przewidywać prostą tabelę podsumowującą etapy (przygotowanie, badanie właściwe, konsultacje, weryfikacja poprawek), co ułatwia odtworzenie historii audytu przy kolejnych przeglądach.

Prezentacja wyników: poziom ogólny, poziom szczegółowy i tabele zgodności

Streszczenie menedżerskie: kilka stron zamiast kilkudziesięciu

Osobom zarządzającym trudno oczekiwać, że przeczytają kilkudziesięciostronicowy raport techniczny. Dlatego w dobrze zaprojektowanym wzorze raportu pierwszą część wynikową stanowi krótkie streszczenie menedżerskie. Jego rola różni się od części szczegółowej: zamiast listy błędów ma pokazać skalę problemu i priorytety.

Takie streszczenie zwykle zawiera:

• globalną ocenę zgodności (np. „serwis częściowo zgodny z WCAG 2.1 na poziomie AA”),
• 3–5 kluczowych obszarów ryzyka (np. formularze, nawigacja klawiaturą, dokumenty PDF),
• orientacyjny podział na priorytety napraw – co należy zrobić w pierwszej kolejności, aby ograniczyć ryzyko prawne i wizerunkowe,
• szacunek nakładu pracy w podziale na zespoły (IT, redakcja, dostawcy zewnętrzni) – nawet jeśli jest to tylko jakościowy podział na „mały/średni/duży”.

Przy porównaniu kolejnych audytów to właśnie streszczenie menedżerskie pozwala szybko ocenić trend: czy liczba obszarów krytycznych maleje, czy może przenosi się tylko w inne miejsce serwisu.

Ogólna ocena zgodności z WCAG i ustawą

Kolejna warstwa wyników to syntetyczna ocena zgodności z przepisami. Można ją ująć na kilka sposobów i wzór raportu powinien wskazywać jedno, konsekwentne podejście. Najczęściej spotyka się:

• trzystopniową skalę zgodności – zgodna / częściowo zgodna / niezgodna, zgodną z logiką oświadczeń o dostępności,
• procentową ocenę spełnionych kryteriów WCAG – przydatną w wewnętrznych raportach porównawczych (między jednostkami, serwisami, wersjami systemu),
• macierz zgodności – zestawienie poziomu A, AA (i ewentualnie AAA) z liczbą spełnionych kryteriów na każdym poziomie.

Każde podejście ma inny ciężar interpretacyjny. Skala trzystopniowa jest czytelna dla organów nadzorczych i mieszkańców. Ocena procentowa lepiej sprawdza się w zarządzaniu portfelem projektów, bo pozwala porównać np. kilka systemów dziedzinowych. Macierz zgodności przydaje się pełnomocnikom ds. dostępności, gdy muszą argumentować, dlaczego część problemów ma wysoki priorytet mimo „dobrze wyglądającego” wyniku procentowego.

Tabele zgodności WCAG – serce raportu urzędowego

Dla administracji publicznej kluczowym elementem raportu są tabele zgodności z WCAG, które potem „przekładają się” na oświadczenie o dostępności. Wzór raportu powinien jasno określać ich minimalny zakres i strukturę.

Praktyczny model tabeli obejmuje kolumny:

• Identyfikator kryterium (np. 1.3.1, 2.4.3),
• Nazwa kryterium,
• Poziom (A, AA, ewentualnie AAA),
• Status (spełnione / niespełnione / nie dotyczy),
• Uwagi – odwołania do szczegółowych opisów niezgodności oraz ewentualne ograniczenia.

Są dwa podejścia do wypełniania takich tabel. Pierwsze: zwięzłe, gdzie w uwagach pojawia się tylko odniesienie do identyfikatora błędu (np. B-12, B-13). Drugie: bogatsze, gdzie uwagi zawierają krótki opis charakteru problemu (np. „brak prawidłowego nagłówka tabeli w module rejestracji”). Pierwszy wariant jest bardziej kompaktowy, drugi ułatwia pracę osobom, które rzadko zaglądają do szczegółowych załączników.

Segmentacja wyników: według systemów, usług, grup użytkowników

Sam ogólny wskaźnik zgodności bywa mylący. Serwis może uzyskać niezłą średnią, a jednocześnie mieć poważne problemy w kluczowym procesie (np. składanie wniosku o świadczenia). Dlatego przy planowaniu wzoru raportu warto przewidzieć możliwość segmentacji wyników.

Sprawdza się kilka perspektyw:

• wg systemów i usług – np. główny portal, BIP, system rekrutacyjny, platforma e-usług, e-learning; każdy z osobnym podsumowaniem,
• wg typów zadań użytkownika – np. wyszukiwanie informacji, wypełnianie formularzy, pobieranie dokumentów, korzystanie z konta użytkownika,
• wg grup użytkowników – np. użytkownicy czytników ekranu, osoby z ograniczeniami ruchowymi, osoby ze słabszym wzrokiem, osoby starsze.

Różnica między tymi podejściami jest praktyczna. Segmentacja „systemowa” pomaga zarządzać umowami z dostawcami zewnętrznymi (łatwo przypisać odpowiedzialność). Segmentacja „zadaniowa” lepiej pokazuje ryzyko z perspektywy mieszkańca lub studenta. Segmentacja „użytkownikowa” z kolei ułatwia komunikację z organizacjami pozarządowymi i pełnomocnikami ds. osób z niepełnosprawnościami.

Wizualne podsumowania: wykresy, mapy ciepła, wskaźniki

Same tabele szybko męczą. W raportach kierowanych do kierownictwa coraz częściej pojawiają się wizualne podsumowania wyników. Ich forma może być prosta, ale powinna być spójna między audytami, aby dało się porównywać postępy.

Przydatne są zwłaszcza:

• wykres słupkowy pokazujący liczbę kryteriów spełnionych/niespełnionych na poziomach A i AA,
• mapa ciepła (heatmapa) obszarów problemowych – np. blok strony × typ problemu,
• wskaźnik koncentracji błędów – odsetek problemów występujących w modułach krytycznych z punktu widzenia usług publicznych.

Różne organizacje wybierają różny stopień szczegółowości. Mniejsza gmina może zadowolić się jednym wykresem słupkowym, podczas gdy duże ministerstwo będzie oczekiwać rozbicia wyników na systemy, departamenty lub dostawców.

Opisy niezgodności: jak pisać, żeby były użyteczne dla zespołów

Standardowy szablon opisu niezgodności

Najbardziej „pracującą” częścią raportu są szczegółowe opisy niezgodności. To one trafiają do systemów zgłoszeń, zadań w Jira czy Asanie, a po kilku miesiącach – do przeglądu przy kolejnym audycie. Im bardziej konsekwentny szablon opisu, tym łatwiej je później wdrożyć.

Typowy, dobrze działający szablon obejmuje pola:

• Identyfikator niezgodności – unikalny numer ułatwiający śledzenie,
• Tytuł problemu – krótki, ale jednoznaczny (np. „Niewidoczne focusy w menu głównym”),
• Powiązane kryteria WCAG – jedno lub kilka, jeśli problem jest złożony,
• Opis wystąpienia – co dokładnie się dzieje, gdzie i przy jakich krokach użytkownika,
• Wpływ na użytkownika – w zwykłym języku, z odniesieniem do konkretnych grup (np. „osoby korzystające z klawiatury nie mogą dotrzeć do linków w górnym menu”),
• Rekomendowane podejście do naprawy – niekoniecznie gotowy kod, ale jasny kierunek,
• Priorytet – z uzasadnieniem (np. ze względu na ryzyko prawne, zasięg problemu, wpływ na kluczowe usługi),
• Zakres występowania – pojedyncza podstrona, dany szablon, cały serwis lub konkretna aplikacja.

Zbyt skrótowe opisy („brak altów”) są wygodne dla audytora, ale mało przydatne dla zespołów. Zbyt drobiazgowe (osobny wpis dla każdego obrazka) z kolei utrudniają zarządzanie zadaniami. Dobry wzór raportu pomaga znaleźć środek: łączy problemy, gdy wynikają z jednego wzorca, ale rozdziela je, jeśli wymagają innych kompetencji lub zespołów do wdrożenia.

Poziom technicznego szczegółu: dwa języki w jednym opisie

Opis niezgodności musi być zrozumiały dla dwóch grup: technicznej i nietechnicznej. Zespół IT potrzebuje informacji o strukturze DOM, a redakcja – o tym, jakie zasady stosować, gdy dodaje treści. Da się to pogodzić, stosując rozdzielenie opisu na dwie części.

Przykładowy układ:

• Opis funkcjonalny – co widzi (lub raczej: czego nie widzi) użytkownik, jakich czynności nie może wykonać, jakie komunikaty pojawiają się lub nie pojawiają.
• Opis techniczny – fragmenty kodu, informacje o użytych komponentach, nazwy klas, powiązane biblioteki, technologia front-end/back-end, ewentualne specyfiki frameworków.

Takie rozdzielenie ułatwia przygotowanie skróconych wersji rekomendacji dla redakcji treści (mogą pominąć część techniczną), a jednocześnie zapewnia IT wystarczającą ilość danych do analizy. W praktyce różnica między raportami, które rozdzielają te dwie warstwy, a tymi, które tego nie robią, jest wyraźna: w pierwszych tempo wdrażania poprawek jest znacznie większe.

Grupowanie błędów: po module, po typie komponentu, po kryterium

Ta sama niezgodność może zostać opisana na kilka sposobów. Można ją pogrupować według kryterium WCAG, według modułów serwisu lub według typu komponentu (np. przyciski, formularze, multimedia). Które podejście wybrać w szablonie raportu?

Trzy częste strategie:

• Grupowanie wg kryteriów WCAG – porządkuje raport z perspektywy formalnej, ułatwia tworzenie tabel zgodności i komunikację z organami kontrolnymi. Minusem jest to, że zespoły IT i redakcje muszą „przekładać” te informacje na konkretne moduły i komponenty.
• Grupowanie wg obszarów systemu (np. „strona główna”, „BIP”, „moduł e-płatności”) – wygodne przy dzieleniu zadań między zespoły odpowiedzialne za poszczególne systemy. Słabiej natomiast pokazuje powtarzalne wzorce błędów w całym ekosystemie.
• Grupowanie wg typu komponentu (formularze, tabele danych, nawigacja, multimedia, dokumenty) – bardzo praktyczne w pracy warsztatowej i przy tworzeniu wytycznych projektowych, ale wymaga dodatkowego mapowania na konkretne kryteria WCAG.

Wzór raportu może zastosować podejście hybrydowe: główne rozdziały według obszarów systemu, a w ich ramach – podsekcje według typów komponentów, z zawsze dołączonym odwołaniem do kryteriów WCAG. Dzięki temu kierownictwo widzi, gdzie w systemie są problemy, a projektanci i programiści rozumieją, jakie wzorce wymagają poprawy globalnej.

Priorytety napraw: proste skale, jasne kryteria

Sam opis problemu nie wystarczy – potrzebny jest jeszcze priorytet. Audytor może użyć prostych oznaczeń (np. wysoki/średni/niski), ale przy braku kryteriów ocena bywa subiektywna i trudna do obrony. Dlatego szablon raportu dobrze uzupełnić o krótki opis logiki priorytetyzacji.

Najczęściej stosuje się zestaw trzech osi:

• wpływ na kluczowe usługi – czy problem uniemożliwia złożenie wniosku, pobranie dokumentu, zarejestrowanie się do systemu,
• zasięg – czy problem występuje w jednym miejscu, czy w wielu szablonach i komponentach,

Najczęściej zadawane pytania (FAQ)

Czym różni się raport z audytu dostępności cyfrowej od oświadczenia o dostępności?

Raport z audytu to pełna diagnoza stanu dostępności: opis metodyki, zakresu badania, szczegółowa lista niezgodności z WCAG 2.1 oraz zalecenia naprawcze. Jest dokumentem „wewnętrzno-zewnętrznym”: służy kierownictwu, zespołom technicznym i może być okazany podczas kontroli.

Oświadczenie o dostępności to natomiast skrócony, ustandaryzowany komunikat publikowany w BIP lub na stronie. Opiera się na wynikach raportu, ale zawiera tylko z góry określony zestaw informacji (poziom zgodności, wyłączenia, procedura żądania dostępności, kontakt). Raportu nie zastępuje – jest jego publicznym streszczeniem, a nie dokumentem audytowym.

Co powinien zawierać wzór raportu z audytu dostępności cyfrowej?

Minimalny zakres dobrego wzoru raportu obejmuje część ogólną i techniczną. W części ogólnej powinny się znaleźć: dane badanego serwisu/systemu, daty audytu, opis zastosowanej metodyki, zakres (co było badane, na jakich urządzeniach), ogólna ocena poziomu dostępności oraz podsumowanie kluczowych problemów i rekomendacji.

Część techniczna to szczegółowy wykaz niezgodności z odniesieniem do konkretnych kryteriów WCAG (np. 1.1.1, 2.4.3), z opisem wpływu na użytkowników i propozycją sposobu naprawy. Dobrym rozwiązaniem jest również osobna sekcja „plan działań”, gdzie błędy są pogrupowane według priorytetu, z szacowanym nakładem prac.

Jak raport z audytu dostępności wykorzystać w BIP i dokumentacji urzędowej?

Raport jest punktem wyjścia do kilku typów dokumentów. W BIP służy przede wszystkim do przygotowania oświadczenia o dostępności oraz do uzasadnienia ewentualnych wyłączeń i terminów planowanej poprawy. Dzięki spójnemu wzorowi raportu dane można przenieść do oświadczenia bez ponownej interpretacji wyników.

W szerszej dokumentacji urzędowej raport warto powiązać z polityką dostępności, planami cyfryzacji, polityką bezpieczeństwa informacji czy rejestrami ryzyka. Przykład: krytyczne niezgodności (np. niedostępne formularze w kluczowym procesie) mogą trafić jako osobne pozycje do rejestru ryzyk operacyjnych i być monitorowane przez kierownictwo.

Jak często należy wykonywać audyt i aktualizować raport z dostępności cyfrowej?

Praktyka w administracji pokazuje dwa podejścia. Pierwsze to regularne pełne audyty, np. co 1–2 lata, połączone z aktualizacją raportu i oświadczenia o dostępności. Sprawdza się tam, gdzie serwis jest rozbudowany, a zmiany wprowadzane są ciągle przez wiele zespołów.

Drugie podejście to audyt pełny przy większych modernizacjach lub wdrożeniu nowego systemu oraz mniejsze przeglądy okresowe (np. raz na rok) skoncentrowane na kluczowych obszarach. W obu wariantach raport powinien odzwierciedlać stan na dzień badania i być spójny z datą aktualizacji oświadczenia o dostępności.

Jak odróżnić rzetelny raport z audytu od dokumentu „pod ustawę”?

Raport „pod ustawę” zwykle jest bardzo ogólny, ogranicza się do kilku zdań typu „strona jest częściowo zgodna, występują problemy z kontrastem” i nie wskazuje konkretnych miejsc ani skali problemu. Taki dokument trudno wykorzystać do planowania prac, budżetu czy zarządzania ryzykiem.

Rzetelny raport zawiera:

• jasny opis metodyki i zakresu badania,
• mapę problemów z przypisaniem do kryteriów WCAG,
• informację o wpływie błędów na użytkowników,
• konkretne zalecenia i priorytety działań.

Dzięki temu po kilku miesiącach widać realne efekty: lista błędów się kurczy, a kolejne audyty pozwalają porównywać postęp.

Jak powiązać raport z audytu z planem działań naprawczych?

Raport dostarcza diagnozy i listy niezgodności, a plan działań zamienia je na konkretne zadania. Najprostszy model to wyodrębniona końcowa sekcja raportu, która dla każdego problemu wskazuje: zakres prac, odpowiedzialnego, termin i orientacyjny nakład czasu. W większych jednostkach plan bywa osobnym dokumentem, ale zawsze powinien się opierać na numeracji i strukturze raportu.

Dobrym rozwiązaniem jest też łączenie priorytetu dostępności z innymi kryteriami, np. z ryzykiem prawnym czy znaczeniem procesu dla mieszkańców. Przykład: naprawa błędów w systemie rekrutacji online do szkół będzie w planie działań wyżej niż poprawa mało odwiedzanej podstrony archiwalnej.

Na jakich przepisach i standardach powinien opierać się wzór raportu z audytu?

W polskich warunkach punktem odniesienia jest ustawa o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych wraz z rozporządzeniami wykonawczymi. Ustawa implementuje dyrektywę unijną i wskazuje WCAG 2.1 na poziomie co najmniej AA jako standard techniczny.

W praktyce oznacza to, że każdy wniosek w raporcie (zgodność lub niezgodność) powinien być powiązany z konkretnym kryterium sukcesu WCAG i jego poziomem (A, AA, ewentualnie AAA). Analiza wzoru oświadczenia o dostępności z rozporządzenia pomaga także ułożyć raport tak, aby łatwo było z niego „wyciągnąć” potrzebne informacje bez dodatkowych interpretacji.