Audyt WCAG to uporządkowane badanie strony internetowej lub aplikacji pod kątem dostępności cyfrowej. Jego celem jest ustalenie, czy osoby korzystające z klawiatury, czytnika ekranu, powiększenia albo innych technologii wspomagających mogą samodzielnie wykonać najważniejsze zadania.

Rzetelny audyt nie kończy się listą komunikatów z automatycznego skanera. Łączy testy automatyczne z oceną ekspercką, badaniem ręcznym i — jeśli taki jest zakres — testami z użytkownikami. Wynikiem powinien być raport, który odpowiada na trzy pytania:

  1. Co nie działa i gdzie występuje problem?
  2. Komu oraz w jaki sposób błąd utrudnia korzystanie z serwisu?
  3. Co należy zmienić i jak sprawdzić poprawkę?

Dobry raport jest jednocześnie dokumentem dla kierownictwa, planem pracy dla zespołu oraz materiałem odbiorowym dla programisty lub dostawcy strony.

Czym dokładnie jest audyt WCAG?

WCAG, czyli Web Content Accessibility Guidelines, opisuje wymagania dostępności treści internetowych. Audyt sprawdza wybrany serwis, aplikację lub proces w odniesieniu do ustalonej wersji WCAG i poziomu zgodności, najczęściej WCAG 2.1 na poziomie AA albo szerszego zakresu WCAG 2.2 AA.

Zakres prawny trzeba dopasować do sytuacji organizacji. Podmioty publiczne w Polsce podlegają ustawie o dostępności cyfrowej, której tabela wymagań odpowiada WCAG 2.1 A i AA oraz odwołuje się do normy EN 301 549. Przy nowym projekcie można dodatkowo zbadać kryteria WCAG 2.2. Więcej o tym rozróżnieniu wyjaśniamy w artykule Kogo obowiązuje WCAG w 2026 roku?.

Audyt może służyć do:

  • poznania rzeczywistego stanu istniejącej strony;
  • przygotowania planu napraw;
  • odbioru nowego serwisu od wykonawcy;
  • sprawdzenia ważnego procesu, na przykład zakupu, rejestracji albo złożenia wniosku;
  • zebrania danych potrzebnych do deklaracji dostępności;
  • porównania stanu przed wdrożeniem i po nim;
  • okresowej kontroli jakości nowych treści;
  • weryfikacji poprawek w ramach reaudytu.

Ministerstwo Cyfryzacji opisuje audyt ekspercki jako możliwie pełne i dokładne badanie strony lub aplikacji, wykonywane przez eksperta dostępności cyfrowej.

Audyt WCAG a automatyczny skan strony

Automatyczny skaner jest przydatnym elementem audytu, ale nie jest pełnym audytem. Potrafi szybko znaleźć część problemów, między innymi:

  • brak atrybutu alt przy obrazie;
  • zbyt niski kontrast możliwy do obliczenia z kodu;
  • pole formularza bez programowej etykiety;
  • niektóre błędy struktury HTML;
  • powtarzające się identyfikatory;
  • pusty przycisk lub link bez dostępnej nazwy.

Program nie rozstrzygnie jednak samodzielnie, czy tekst alternatywny trafnie przekazuje znaczenie obrazu, kolejność fokusu jest logiczna, komunikat błędu pomaga poprawić dane ani czy użytkownik rozumie cały proces. Może też zgłosić wynik wymagający dopiero oceny człowieka.

W3C podkreśla, że narzędzia automatyczne pomagają znajdować potencjalne problemy, ale nie mogą samodzielnie określić dostępności. Dlatego wynik „zero błędów” w skanerze nie oznacza zgodności z WCAG.

Automatyczny skan Audyt ekspercki
Sprawdza reguły możliwe do zapisania w programie Łączy automatyzację z oceną człowieka
Działa szybko na wielu podstronach Bada reprezentatywną próbkę i ważne procesy
Wykrywa część błędów w kodzie Ocenia również znaczenie, kolejność i sposób obsługi
Może wskazać fałszywy alarm Audytor interpretuje wynik w kontekście strony
Daje listę technicznych komunikatów Powinien dać diagnozę, priorytety i zalecenia naprawy

Na początku możesz uruchomić darmowy test dostępności strony. Pozwoli znaleźć część podstawowych problemów i lepiej przygotować się do rozmowy o zakresie pełnego badania.

Jak przebiega audyt WCAG krok po kroku?

Metodyka W3C WCAG-EM porządkuje ocenę w pięciu głównych etapach: określenie zakresu, poznanie badanego serwisu, wybór reprezentatywnej próbki, zbadanie próbki oraz opisanie wyników. W3C przedstawia ten proces w omówieniu oceny zgodności.

1. Ustalenie celu i standardu badania

Najpierw trzeba odpowiedzieć, po co wykonywany jest audyt. Inny zakres będzie potrzebny do przygotowania deklaracji dostępności, inny do odbioru nowej strony, a jeszcze inny do sprawdzenia samego procesu zakupowego.

Na tym etapie ustala się między innymi:

  • badaną stronę, aplikację lub proces;
  • wersję WCAG i poziom zgodności;
  • dodatkowe podstawy, na przykład ustawę lub EN 301 549;
  • czy badanie obejmuje wersję mobilną, dokumenty i multimedia;
  • czy będą prowadzone testy z użytkownikami;
  • format raportu i oczekiwany poziom szczegółowości rekomendacji;
  • zasady reaudytu po wprowadzeniu poprawek.

Nieprecyzyjne zamówienie „audytu WCAG strony” może prowadzić do zupełnie różnych ofert. Warto ustalić zakres przed wyceną, aby później nie okazało się, że raport obejmuje wyłącznie stronę główną lub wynik automatycznego narzędzia.

2. Poznanie serwisu i jego funkcji

Audytor przegląda strukturę witryny, używane szablony, technologie oraz główne zadania użytkowników. Szuka elementów wspólnych i nietypowych, takich jak:

  • nagłówek, menu i stopka;
  • wyszukiwarka;
  • formularze i komunikaty błędów;
  • logowanie i zakładanie konta;
  • koszyk, płatność i potwierdzenie zakupu;
  • filtrowanie i sortowanie;
  • mapy, wykresy oraz multimedia;
  • dokumenty do pobrania;
  • okna dialogowe i elementy aktualizowane bez przeładowania strony.

To ważny etap, ponieważ dwa adresy mogą korzystać z tego samego szablonu, a jeden proces może składać się z wielu ekranów i stanów.

3. Wybór reprezentatywnej próbki

W dużym serwisie nie zawsze bada się każdą podstronę osobno. Wybiera się próbkę, która pokrywa wszystkie najważniejsze szablony, rodzaje treści, funkcje i ścieżki użytkownika.

Próbka może obejmować:

  • stronę główną;
  • stronę kategorii i artykuł;
  • wyniki wyszukiwania oraz brak wyników;
  • formularz pusty, poprawnie wypełniony i zawierający błędy;
  • proces od pierwszego kroku do potwierdzenia;
  • stronę z tabelą, dokumentem, filmem lub mapą;
  • podstronę o nietypowym układzie;
  • widok po zalogowaniu;
  • elementy wybrane losowo.

Próbka nie powinna być zbiorem najłatwiejszych stron. Musi odwzorowywać faktyczną różnorodność serwisu. W opublikowanym w 2026 roku raporcie z samooceny serwisu Dostępność cyfrowa Ministerstwo wskazało listę badanych adresów i wyjaśniło, że reprezentowały wszystkie używane szablony.

4. Testy automatyczne i ręczne

Audytor łączy kilka metod, ponieważ każda pokazuje inną część problemu. Typowy zestaw obejmuje:

  • analizę automatyczną;
  • przegląd kodu i semantyki HTML;
  • obsługę całej strony wyłącznie klawiaturą;
  • sprawdzenie widoczności oraz kolejności fokusu;
  • test z czytnikiem ekranu;
  • powiększenie i zmianę układu treści;
  • sprawdzenie kontrastu i użycia koloru;
  • test orientacji ekranu oraz widoku mobilnego;
  • ocenę formularzy, błędów i dynamicznych komunikatów;
  • ocenę tekstów alternatywnych, dokumentów i multimediów.

W raporcie powinny znaleźć się konkretne informacje o środowisku badania: systemie operacyjnym, przeglądarce, technologii wspomagającej i ich wersjach. Dzięki temu wykonawca może odtworzyć problem, a wyniki reaudytu da się uczciwie porównać z badaniem początkowym.

5. Analiza wyników i przygotowanie raportu

Po testach audytor łączy powtarzające się obserwacje, przypisuje je do właściwych wymagań i ocenia ich wpływ. Ten sam błąd szablonu może występować na setkach adresów, dlatego raport powinien pokazywać zarówno przykładowe miejsce, jak i przewidywany zasięg problemu.

Wyniki wymagają interpretacji. Brak alt przy dekoracyjnej grafice jest inną sytuacją niż brak opisu wykresu zawierającego kluczowe dane. Oba przypadki dotyczą alternatywy tekstowej, ale mają inny wpływ i mogą wymagać innej poprawki.

Co sprawdza audyt WCAG?

Zakres kryteriów zależy od ustalonej wersji standardu, ale badanie powinno obejmować cztery zasady WCAG:

  1. Postrzegalność — czy informacje można odebrać wzrokiem, słuchem albo za pomocą technologii wspomagającej. Obejmuje to między innymi alternatywy tekstowe, napisy, strukturę i kontrast.
  2. Funkcjonalność — czy wszystkie działania można wykonać różnymi metodami, w tym klawiaturą, oraz czy użytkownik ma wystarczająco dużo czasu i może się sprawnie poruszać po stronie.
  3. Zrozumiałość — czy treść, nawigacja, formularze i komunikaty są przewidywalne oraz zrozumiałe.
  4. Kompatybilność — czy kod prawidłowo przekazuje nazwę, rolę, wartość i stan elementów technologiom wspomagającym.

Lista kryteriów nie powinna zastępować testowania całych zadań. Użytkownik nie korzysta z serwisu „kryterium po kryterium”. Chce znaleźć informację, złożyć wniosek, kupić bilet albo wysłać formularz. Dlatego dobry audyt sprawdza równocześnie zgodność techniczną i możliwość ukończenia najważniejszych procesów.

Co powinien zawierać raport z audytu WCAG?

Nie istnieje jeden obowiązkowy szablon raportu. W3C udostępnia jednak zalecany wzór raportu z oceny dostępności, a Ministerstwo Cyfryzacji opisuje minimalne elementy, których można oczekiwać przy pełnym audycie.

1. Streszczenie dla osób decyzyjnych

Pierwsze strony raportu powinny pozwolić kierownictwu zrozumieć wynik bez czytania kilkudziesięciu opisów technicznych. Streszczenie powinno zawierać:

  • cel i zakres badania;
  • ogólny wynik oceny;
  • najpoważniejsze bariery;
  • procesy, których nie da się ukończyć;
  • główne źródła problemów;
  • zalecaną kolejność działań.

Jeżeli raport używa punktacji, musi wyjaśniać sposób jej obliczenia. Sama liczba, na przykład „72/100”, nie jest poziomem zgodności WCAG i nie powinna zastępować wyników dla poszczególnych kryteriów.

2. Podstawa i zakres oceny

Raport powinien jednoznacznie wskazywać:

  • wersję WCAG i badany poziom, na przykład WCAG 2.1 AA;
  • ewentualne odniesienie do ustawy lub normy EN 301 549;
  • adres i wersję badanego serwisu;
  • daty badania;
  • listę podstron, ekranów i procesów w próbce;
  • elementy wyłączone z badania;
  • ograniczenia, które mogły wpłynąć na wynik.

Bez tych informacji nie wiadomo, czego dokładnie dotyczy wniosek o zgodności lub niezgodności.

3. Metodyka i środowisko testowe

Czytelnik powinien wiedzieć, jak przeprowadzono audyt. W raporcie warto podać:

  • użyte narzędzia automatyczne;
  • metody testów ręcznych;
  • systemy operacyjne i przeglądarki;
  • czytniki ekranu oraz inne technologie wspomagające;
  • urządzenia i rozdzielczości;
  • dane testowe i role użytkowników;
  • informację o udziale użytkowników z niepełnosprawnościami.

4. Szczegółowy opis każdego problemu

Każde zgłoszenie powinno być możliwe do znalezienia, odtworzenia, naprawienia i ponownego sprawdzenia. Przy błędzie warto podać:

  • unikalny numer;
  • nazwę problemu;
  • adres strony i element, którego dotyczy;
  • kroki prowadzące do odtworzenia;
  • zachowanie zaobserwowane oraz oczekiwane;
  • wpływ na użytkownika;
  • powiązane kryterium WCAG i jego poziom;
  • wagę oraz priorytet naprawy;
  • zrzut ekranu lub fragment kodu, gdy pomaga zrozumieć problem;
  • rekomendowany sposób naprawy;
  • warunek odbioru poprawki.

5. Ocena wpływu i priorytetów

Poziom A lub AA kryterium WCAG nie mówi automatycznie, który błąd należy poprawić pierwszy. Priorytet powinien uwzględniać:

  • czy problem całkowicie blokuje wykonanie zadania;
  • ilu użytkowników i ile podstron dotyczy;
  • czy występuje w kluczowym procesie;
  • jak często użytkownik się z nim spotyka;
  • czy wynika ze wspólnego szablonu lub komponentu;
  • czy istnieje dostępna droga alternatywna;
  • ile pracy wymaga naprawa.

Krytycznym problemem może być na przykład brak możliwości zatwierdzenia zakupu klawiaturą. Błąd występuje na jednym ekranie, ale blokuje cały proces i bezpośrednio wpływa na klienta oraz wynik biznesowy.

6. Macierz zgodności

Przy pełnym audycie przydatna jest tabela wszystkich badanych kryteriów z wynikiem, na przykład:

  • spełnione;
  • niespełnione;
  • nie dotyczy;
  • nieweryfikowane lub poza zakresem.

Każdy wynik „niespełnione” powinien prowadzić do konkretnych zgłoszeń. Status „nie dotyczy” wymaga uzasadnienia, jeśli nie jest oczywisty. Dzięki temu raport nie pomija po cichu kryteriów, przy których nie znaleziono błędów.

7. Problemy wspólne i przyczyny źródłowe

Lista stu podobnych błędów może utrudnić pracę. Raport powinien pokazać, które problemy wynikają z jednego komponentu lub procesu redakcyjnego. Poprawa szablonu menu, komponentu formularza albo sposobu publikowania dokumentów może usunąć wiele wystąpień jednocześnie.

Warto oddzielić:

  • problemy wymagające zmiany kodu;
  • błędy projektu interfejsu;
  • problemy w treści i dokumentach;
  • błędy konfiguracji CMS;
  • braki w procesie publikacji i kontroli jakości.

8. Wyniki testów z użytkownikami

Jeżeli audyt obejmował badania z osobami z niepełnosprawnościami, raport powinien opisać scenariusze, używane technologie, zaobserwowane bariery i wnioski. Nie należy publikować zbędnych danych osobowych ani przedstawiać opinii jednej osoby jako doświadczenia całej grupy.

Testy użytkowników uzupełniają ocenę zgodności. Mogą ujawnić problemy, których nie pokaże ani automat, ani samo przejście listy kryteriów. Ministerstwo Cyfryzacji wskazuje tę różnicę w przeglądzie metod badania.

9. Rekomendacje oraz plan dalszych działań

Rekomendacja „poprawić zgodnie z WCAG” nie wystarcza. Zalecenie powinno opisywać pożądany rezultat, a gdy to przydatne — proponować rozwiązanie techniczne lub przykład prawidłowego wzorca.

Raport powinien również pomóc podzielić pracę na etapy:

  1. bariery blokujące kluczowe zadania;
  2. poprawki we wspólnych szablonach i komponentach;
  3. błędy powtarzalne w treści;
  4. pozostałe niezgodności;
  5. zmiany procesu, które zapobiegną powrotowi problemów.

10. Dostępna forma samego raportu

Raport o dostępności również powinien być dostępny. Jeśli powstaje w PDF, potrzebuje prawidłowej struktury, kolejności czytania, tagów, nagłówków, opisów grafik i dostępnych tabel. Dobrą praktyką jest przekazanie również edytowalnego lub łatwego do przetwarzania formatu, na przykład HTML, DOCX albo arkusza z listą zgłoszeń.

Przykład dobrze opisanego błędu

Pole raportu Przykład
Problem Nie można wybrać terminu wizyty klawiaturą
Miejsce Formularz rezerwacji, krok 2, lista terminów
Jak odtworzyć Otwórz formularz, przejdź klawiszem Tab do listy terminów i spróbuj wybrać godzinę
Wynik Fokus omija kafelki reagujące wyłącznie na kliknięcie myszą
Wpływ Osoba korzystająca z klawiatury nie może ukończyć rezerwacji
Kryterium WCAG 2.1.1 Klawiatura, poziom A
Priorytet Krytyczny — błąd blokuje główny proces
Rekomendacja Zastosuj natywną grupę pól radiowych z etykietami i widocznym fokusem
Warunek odbioru Każdy termin można wybrać klawiaturą, a czytnik ekranu podaje nazwę i stan opcji

Taki opis daje zespołowi znacznie więcej niż zrzut ekranu z komunikatem „element niedostępny”. Programista potrafi odtworzyć sytuację, projektant rozumie skutek, a tester wie, kiedy uznać poprawkę za zakończoną.

Po czym poznać słaby raport z audytu?

Ostrożność powinien wzbudzić raport, który:

  • zawiera wyłącznie eksport z automatycznego narzędzia;
  • nie podaje badanych adresów i procesów;
  • nie wskazuje wersji WCAG ani poziomu zgodności;
  • ogranicza się do ogólnego wyniku procentowego;
  • nie opisuje środowiska testów;
  • pokazuje błędy bez wyjaśnienia wpływu na użytkownika;
  • nie pozwala odtworzyć problemu;
  • nie zawiera priorytetów ani warunków odbioru;
  • nazywa się „certyfikatem WCAG”, choć nie wyjaśnia zakresu i metody badania;
  • obiecuje pełną ocenę całego serwisu po samym automatycznym skanie strony głównej.

Warto poprosić wykonawcę o przykładową, zanonimizowaną kartę błędu przed zleceniem pracy. Pozwala to ocenić, czy raport będzie użyteczny dla zespołu, który ma wdrożyć poprawki.

Czy audyt daje certyfikat zgodności z WCAG?

WCAG nie przewiduje jednego urzędowego certyfikatu, który bezterminowo potwierdza dostępność strony. Audyt opisuje stan określonej wersji serwisu w konkretnym czasie i w ustalonym zakresie.

Strona może zmienić się dzień po badaniu: redaktor opublikuje niedostępny PDF, programista wdroży nowy formularz albo zewnętrzny dostawca zmieni widżet płatności. Dlatego ważniejsze od ozdobnego certyfikatu są jawna metodyka, reprezentatywna próbka, szczegółowe wyniki i proces dalszej kontroli.

Czy raport z audytu wystarczy do deklaracji dostępności?

Raport daje merytoryczną podstawę do określenia stanu zgodności i opisania znanych niezgodności. Nie jest jednak samą deklaracją dostępności. Deklaracja ma wymaganą strukturę, treść oraz dane dotyczące między innymi kontaktu, procedury skargowej i dostępności architektonicznej.

Po otrzymaniu raportu trzeba:

  • ustalić rzeczywisty stan zgodności;
  • opisać niezgodne elementy i wyłączenia;
  • przygotować pozostałe wymagane informacje;
  • opublikować dokument jako dostępną stronę HTML;
  • aktualizować go po istotnych zmianach i w wymaganych terminach.

Do przygotowania dokumentu możesz użyć generatora deklaracji dostępności.

Co zrobić po otrzymaniu raportu?

Raport ma wartość dopiero wtedy, gdy prowadzi do usunięcia barier. Po jego odebraniu warto zorganizować krótkie spotkanie audytora, właściciela produktu, redaktorów i wykonawcy technicznego.

Następnie:

  1. potwierdź, że wszystkie problemy są zrozumiałe i możliwe do odtworzenia;
  2. pogrupuj błędy według wspólnej przyczyny;
  3. najpierw zaplanuj bariery blokujące kluczowe zadania;
  4. przypisz właściciela oraz termin każdej poprawki;
  5. wprowadź kryteria odbioru do systemu zadań;
  6. przetestuj poprawki w tym samym środowisku;
  7. wykonaj reaudyt najważniejszych ścieżek;
  8. popraw proces publikacji, aby błędy nie wróciły.

Nie należy zamykać zgłoszenia wyłącznie na podstawie informacji „poprawione”. Zmiana może usunąć jeden problem i utworzyć inny. Na przykład dodanie niestandardowej obsługi klawiatury może zaburzyć kolejność fokusu. Każdą poprawkę trzeba zweryfikować.

Ile trwa i ile kosztuje audyt WCAG?

Czas oraz cena zależą przede wszystkim od wielkości próbki, liczby unikalnych szablonów, złożoności procesów, liczby wersji językowych, zakresu dokumentów i multimediów oraz udziału testerów z niepełnosprawnościami.

Na pracochłonność wpływają również:

  • logowanie i różne role użytkowników;
  • aplikacja jednostronicowa z dynamicznymi widokami;
  • sklep z wieloetapowym zakupem;
  • zewnętrzne systemy płatności lub rezerwacji;
  • osobna aplikacja mobilna;
  • oczekiwana szczegółowość rekomendacji;
  • liczba rund reaudytu.

Dlatego rzetelna wycena wymaga krótkiego rozpoznania serwisu. Sama liczba adresów nie mówi wszystkiego — jedna rozbudowana aplikacja może wymagać więcej pracy niż kilkadziesiąt prostych stron opartych na tym samym szablonie.

Przykład zgłoszenia gotowego dla programisty

Wynik audytu powinien wskazywać miejsce, problem, wpływ na użytkownika i sposób sprawdzenia poprawki. Zamiast „przycisk jest niedostępny” można przekazać zgłoszenie w takiej formie:

Element Problem i skutek Oczekiwana poprawka Kryterium odbioru
Formularz kontaktowy, pole e-mail Brak programowo powiązanej etykiety; czytnik ekranu nie podaje celu pola Dodać widoczną etykietę powiązaną przez for i id Czytnik odczytuje „Adres e-mail, wymagane, pole edycji”

Przykład poprawnego powiązania:

<label for="email">Adres e-mail</label>
<input id="email" name="email" type="email" required>

Taki zapis pozwala zespołowi odtworzyć błąd i zweryfikować poprawkę bez zgadywania, co autor raportu miał na myśli.

Podsumowanie

Audyt WCAG to połączenie automatycznej analizy, testów ręcznych, wiedzy eksperta i — w ustalonym zakresie — doświadczenia użytkowników z niepełnosprawnościami. Powinien badać reprezentatywną próbkę oraz pełne procesy, a nie tylko stronę główną.

Dobry raport zawiera zakres i metodykę badania, środowisko testowe, ocenę kryteriów, szczegółowe opisy problemów, wpływ na użytkowników, priorytety, rekomendacje i warunki odbioru. Dzięki temu staje się planem napraw, a nie dokumentem odkładanym na półkę.

Jeśli chcesz poznać rzeczywisty stan strony i otrzymać raport gotowy do przekazania kierownictwu oraz wykonawcy, zamów audyt dostępności WCAG.

FAQ: audyt WCAG i raport z badania

Czy automatyczny test strony jest audytem WCAG?

Nie. Automatyczne narzędzie wykrywa tylko część możliwych problemów i nie ocenia wielu elementów wymagających ludzkiego osądu. Jest dobrym początkiem badania, ale pełny audyt wymaga także testów ręcznych i eksperckiej interpretacji.

Czy trzeba badać wszystkie podstrony serwisu?

Nie zawsze. W dużym serwisie można wybrać reprezentatywną próbkę obejmującą wszystkie szablony, rodzaje treści, funkcje i kluczowe procesy. Zakres próbki oraz sposób jej wyboru muszą być opisane w raporcie.

Czy audyt powinien obejmować test czytnikiem ekranu?

Tak, jeśli ma rzetelnie ocenić współpracę serwisu z technologiami wspomagającymi. Sam przegląd kodu nie pokaże całego doświadczenia użytkownika. Raport powinien wskazać użyty czytnik, przeglądarkę, system i ich wersje.

Czy raport powinien zawierać gotowy kod naprawy?

Nie zawsze. Powinien jednak jasno opisywać oczekiwany rezultat i umożliwiać wykonawcy przygotowanie poprawki. Zakres szczegółowych przykładów kodu warto ustalić przed zamówieniem audytu, ponieważ wpływa na czas i cenę pracy.

Kiedy wykonać reaudyt?

Reaudyt wykonuje się po wdrożeniu poprawek, najlepiej zanim zmiany zostaną ostatecznie odebrane. Warto ponownie przejść nie tylko poprawiony element, ale również powiązany proces, aby wykryć ewentualne skutki uboczne.

Jak często powtarzać audyt dostępności?

Nie ma jednego terminu odpowiedniego dla każdej strony. Badanie warto powtórzyć po dużej przebudowie, zmianie systemu, dodaniu ważnej funkcji oraz wtedy, gdy pojawiają się sygnały od użytkowników. W szybko rozwijanym serwisie lepsze są regularne testy mniejszych zmian niż jeden duży audyt raz na kilka lat.

Powiązane poradniki