WCAG 2.2 jest obecnie docelowym poziomem AA w całej UE na mocy Europejskiego Aktu o Dostępności (EAA) i zharmonizowanego standardu EN 301 549, a także de facto wzorcem, względem którego sądy amerykańskie mierzą strony internetowe objęte ADA, nawet gdy przepisy wciąż powołują się na wersję 2.1. Standard jest dobrze udokumentowany; ścieżka od „wiemy, że musimy zapewnić zgodność“ do „mamy wiarygodną postawę“ — nie. Niniejszy przewodnik to właśnie ta ścieżka, w sześciu krokach, w kolejności, w jakiej zespół powinien je faktycznie realizować.

WCAG 2.2 to aktualna wersja Wytycznych dotyczących dostępności treści internetowych (WCAG), opublikowanych przez W3C jako Zalecenie w październiku 2023 roku. Definiuje 86 kryteriów sukcesu zorganizowanych według czterech zasad — treść musi być postrzegalna, funkcjonalna, zrozumiała i solidna. Każde kryterium ma przypisany poziom zgodności. Poziom A to minimalny próg; poziom AA to wzorzec roboczy, do którego odnosi się każdy główny regulator; poziom AAA jest aspiracyjny i nie stanowi regulacyjnego minimum nigdzie na świecie.

Gdy regulator lub kontrakt mówi „zgodność z WCAG 2.2 AA“, oznacza to coś więcej niż zaliczenie jednej strony. Definicja zgodności W3C wymaga, aby cała jednostka zgodności — strona lub zestaw stron tworzących proces — spełniała każde kryterium poziomów A i AA, aby każdy proces był dostępny od początku do końca i aby technologia wspomagająca nie musiała być wyłączona, by treść działała. Serwis spełniający większość kryteriów na większości stron nie jest zgodny; poprzeczka to pełne pokrycie.

WCAG 2.2 dodaje dziewięć nowych kryteriów względem wersji 2.1 — wygląd fokusa, rozmiar celu, przeciąganie, nadmiarowe wprowadzanie danych, dostępne uwierzytelnianie, spójna pomoc i kilka innych. Serwisy, które spełniały wymagania WCAG 2.1 AA, nie spełniają automatycznie WCAG 2.2 AA; nowe kryteria to miejsce, gdzie ujawnia się różnica. Miarodajne źródło danych dotyczących poszczególnych kryteriów znajduje się w naszym kompletnym wykazie kryteriów sukcesu WCAG 2.2.

Zgodność to postawa, a nie stan — serwis zgodny w poniedziałek może wprowadzić regresję we wtorek. Traktowanie jej jako jednorazowego projektu to najczęstszy i najkosztowniejszy błąd w tej dziedzinie.

Nie można naprawić tego, czego się nie zmierzyło, a jedno narzędzie nie zmierzy tego dobrze. Audyt podstawowy działa w trzech trybach na mniej więcej tym samym zestawie stron.

Tryb 1 — Automatyczne skanowanie. Skaner raportuje błędy możliwe do sprawdzenia maszynowo — brakujący tekst alternatywny, brakujące etykiety formularzy, niski kontrast kolorów, nieprawidłowe ARIA, problemy ze strukturą nagłówków. Wychwytuje gęste, powtarzające się problemy, które inżynier musiałby w innym wypadku wyszukiwać ręcznie, ale nie oceni, czy tekst alternatywny jest znaczący, czy niestandardowy widget działa poprawnie pod czytnikiem ekranu, ani czy kolejność fokusa ma logiczny sens. Skanowanie należy traktować jako punkt wyjścia pod względem wolumenu, a nie jako werdykt. Zacznij od uruchomienia bezpłatnego skanera WCAG 2.2 na dziesięciu najważniejszych stronach — strona główna, logowanie, kasa, dwie strony produktów, pulpit nawigacyjny, ustawienia konta, strona deklaracji dostępności o ile istnieje oraz dwie strony docelowe o najwyższym ruchu. Skanowanie mówi, czy masz sto problemów, czy dziesięć tysięcy — to pierwsza informacja, której potrzebuje osoba kierująca usuwaniem barier.

Tryb 2 — Ręczna weryfikacja przez widzącego specjalistę ds. dostępności. Przeszkolony weryfikator pracujący na tych samych stronach wychwytuje to, czego automatyka nie potrafi ocenić. Czy tekst alternatywny jest dokładny? Czy struktura nagłówków jest logiczna, a nie tylko syntaktycznie poprawna? Czy niestandardowe widgety eksponują właściwą nazwę, rolę i stan? Specjalista obejmuje około piętnastu do dwudziestu stron dziennie; wynikiem jest pisemny raport z krokami reprodukcji odwzorowanymi na konkretne kryteria sukcesu.

Tryb 3 — Audyt użyteczności z osobami korzystającymi z technologii wspomagających. Użytkownik czytnika ekranu realizuje zakup; użytkownik tylko z klawiaturą nawiguje po pulpicie nawigacyjnym; użytkownik słabowidzący wypełnia formularz kontaktowy przy powiększeniu 200%. Wynik jest jakościowy — „komunikat po przesłaniu formularza pojawia się przed przeniesieniem fokusa, więc go przeoczyłam“ — i to warstwa, która odróżnia zgodność od dostępności. Ten tryb jest najczęściej pomijanym przez organizacje; jeśli go pominiesz, serwis będzie zaliczać skany i deklaracje, a użytkownicy wciąż nie będą mogli realizować swoich zadań.

Trzy tryby uzupełniają się nawzajem: automatyzacja znajduje wolumen, weryfikacja specjalisty wykrywa problemy strukturalne i semantyczne, a testy z użytkownikami wychwytują błędy w doświadczeniu. Pierwsze kompleksowe badanie podstawowe obejmujące wszystkie trzy tryby zajmuje dwa do czterech tygodni w przypadku serwisu średniej wielkości.

Audyt podstawowy typowego serwisu ujawnia setki do tysięcy problemów. Rozpoczęcie od góry płaskiej listy to sposób na spędzenie trzech miesięcy bez przesunięcia wyniku. Triaż działa na dwóch osiach — nasilenie i zasięg.

Nasilenie to stopień, w jakim problem psuje doświadczenie. Blokady uniemożliwiają realizację zadania: przycisk w kasie, którego czytniki ekranu nie mogą aktywować; pole formularza bez programowej etykiety; okno modalne blokujące fokus. Poważne problemy powodują znaczące utrudnienia, ale nie blokują: niejednoznaczny tekst łącza, brak stylów fokusa, komunikaty o błędach widoczne, ale nieogłaszane. Drobne problemy są kosmetyczne lub dotyczą tylko wąskich konfiguracji technologii wspomagających: kontrast nieznacznie poniżej 4,5:1, tekst alternatywny ze spacją na końcu, pominięty poziom nagłówka na stronie z przypisami.

Zasięg to liczba użytkowników, którzy napotykają dany problem. Niejednoznaczne łącze w globalnej nawigacji dociera do każdego odwiedzającego na każdej stronie. Niedostępny wybierak dat w kasie dociera do każdego kupującego. Niedostępny komponent na stronie z materiałami prasowymi dociera prawie do nikogo. Zasięg ustala się na podstawie analityki, a nie inherentnego znaczenia problemu.

Prosta macierz dwa na dwa wystarczy. Chodzi nie o precyzję — chodzi o wymuszenie rozmowy, że „zablokowanie czytnikowi ekranu możliwości finalizacji zakupu“ to nie ten sam problem co „atrybut alt ze spacją na końcu na stronie prasowej“.

Triaż daje priorytetyzowany backlog. Backlog, a nie raport z audytu, stanowi podstawę pracy inżynierów.

Prace naprawcze sprowadzają się do tych samych wzorców niemal w każdym serwisie. Każda kategoria mapuje się na jedno lub więcej kryteriów sukcesu WCAG; kompletny wykaz kryteriów sukcesu WCAG 2.2 jest miarodajnym źródłem.

Semantyczna struktura HTML. Naprawa o najwyższej dźwigni to użycie właściwego elementu. button to nie div z obsługą kliknięcia; nagłówek to nie pogrubiony tekst; lista to nie akapity rozdzielone łamaniem wiersza. Natywny HTML wnosi nazwę, rolę i zachowanie klawiatury za darmo; reinwentowanie tego z ARIA na ogólnym elemencie to sposób, w jaki wprowadzana jest większość błędów dostępności. Mapuje się na kryteria sukcesu 1.3.1 i 4.1.2.

Tekst alternatywny obrazów. Każdy znaczący obraz wymaga opisowego tekstu alternatywnego. Dekoracyjne obrazy otrzymują alt="", a nie brak atrybutu. Funkcjonalne obrazy — ikony wewnątrz przycisków, łącza-obrazy — otrzymują tekst alternatywny opisujący czynność, a nie sam obraz. Mapuje się na kryterium sukcesu 1.1.1.

Dostępność klawiaturowa. Każdy interaktywny element musi być osiągalny i obsługiwalny wyłącznie klawiaturą — tab do niego, aktywacja Enterem lub spacją, wyjście Escape’m. Niestandardowe widgety (listy rozwijane, okna modalne, zakładki, karuzele, wybieraki dat) są najczęstszymi sprawcami. Sprawdzaj, odłączając mysz. Mapuje się na kryteria sukcesu 2.1.1 i 2.1.2.

Zarządzanie fokusem. Gdy fokus trafia na element, musi być widoczny, a gdy coś zmienia stronę, fokus musi wylądować w sensownym miejscu. Otwierające się okno modalne powinno przenosić fokus do jego wnętrza; zamknięcie powinno zwracać fokus do elementu wyzwalającego. WCAG 2.2 dodało kryterium sukcesu 2.4.11 Focus Not Obscured i zaostrzyło kryterium 2.4.7 Focus Visible; obramowanie fokusa nie jest już opcjonalnym dodatkiem.

Kontrast kolorów. Tekst na tle musi osiągać 4,5:1 dla normalnego i 3:1 dla dużego zgodnie z kryterium sukcesu 1.4.3; interaktywne komponenty interfejsu i grafiki muszą osiągać 3:1 zgodnie z kryterium 1.4.11. Większość naruszeń występuje w powierzchniach marketingowych — kolory marki wyglądające dobrze na skalibrowanym monitorze projektanta i niespełniające wymogów na rzeczywistym laptopie. Sprawdzanie kontrastu w narzędziach projektowych zapobiega większości regresji.

Etykiety formularzy i komunikaty o błędach. Każde pole wymaga programowej etykiety, a nie tylko podpowiedzi. Błędy muszą być ogłaszane technologii wspomagającej, powiązane z polem, które je spowodowało, i opisane w formie możliwej do podjęcia działania. „Nieprawidłowe dane“ to nie etykieta; „Numer telefonu musi zawierać kod kraju“ — tak.

ARIA — powściągliwość, nie entuzjazm. ARIA należy stosować tylko wtedy, gdy natywny HTML nie może wyrazić tego, co robi komponent. nav jest lepszy niż role="navigation"; button jest lepszy niż role="button". Nieprawidłowe ARIA jest gorsze niż brak ARIA, ponieważ aktywnie wprowadza technologię wspomagającą w błąd.

Ogłoszenia o dynamicznych zmianach treści. Gdy treść zmienia się bez przeładowania strony — powiadomienia toast, komunikaty walidacyjne, wyniki wyszukiwania aktualizowane w miejscu — czytniki ekranu ją przeoczyją, jeśli ich o tym nie poinformujesz. Stosuj aria-live="polite" dla niepriorytowych aktualizacji i aria-live="assertive" tylko dla rzeczywistych przerywań.

Dostępność plików PDF. Każdy publikowany plik PDF musi spełniać wymagania PDF/UA — odpowiednika WCAG dla dokumentów. Pliki PDF są zazwyczaj największą ślepą plamą w programie usuwania barier, ponieważ są własnością osób spoza inżynierii. Zapoznaj się z naszym kompleksowym przewodnikiem po dostępności PDF.

Naprawy wzajemnie na siebie oddziałują. Zastąpienie przycisku-div natywnym button naprawia kryteria dotyczące klawiatury, fokusa, nazwy, roli i wartości w jednej edycji. Dlatego semantyczny HTML jest na pierwszym miejscu — przynosi efekty dla największej liczby kryteriów przy najmniejszym nakładzie pracy.

Naprawa nie jest zakończona, dopóki nie zostanie zweryfikowana w sposób, w jaki użytkownik rzeczywiście skonsumuje daną stronę. Automatyczne skanery wychwytują około trzydziestu do czterdziestu procent problemów WCAG przy optymistycznych założeniach, co oznacza, że większość napraw jest niewidoczna dla narzędzia, które oznaczyło dany problem.

Minimalna macierz testowania technologii wspomagających jest krótka. NVDA z Firefox na Windows to najczęściej używana kombinacja czytnika ekranu i przeglądarki na komputerze stacjonarnym; NVDA jest bezpłatny. VoiceOver z Safari na macOS to domyślna opcja na komputerach Apple; VoiceOver z Safari na iOS to domyślna opcja na urządzeniach mobilnych Apple, a model gestów iOS różni się od wersji desktopowej na tyle, że wersja mobilna musi być testowana osobno. TalkBack z Chrome na Androidzie uzupełnia zestaw mobilny. Wyłącznie klawiatura we wszystkich interaktywnych przepływach nie wymaga żadnej technologii wspomagającej — wystarczy odłączyć mysz — i jest pojedynczym testem o najwyższej wartości, jaki można przeprowadzić.

Dla każdej naprawy protokół jest taki sam. Załaduj stronę w odpowiedniej przeglądarce i czytniku ekranu. Przejdź do danego elementu używając wyłącznie technologii wspomagającej. Aktywuj go. Obserwuj, co jest ogłaszane. Potwierdź, że ogłoszenie odpowiada temu, co widzący użytkownik zrozumiałby z tej samej interakcji. Udokumentuj weryfikację — data, wersja technologii wspomagającej, wersja przeglądarki, zaliczony lub niezaliczony.

Wzorce, które weryfikacja wychwytuje, a skanery pomijają: przycisk ogłaszany bez dostępnej nazwy; okno modalne otwierające się z prawidłowym ARIA, ale fokus pozostaje na elemencie wyzwalającym, więc użytkownik czytnika ekranu nie wie, że się otworzyło; niestandardowa lista rozwijana eksponująca prawidłową rolę, ale nieogłaszająca wybranej opcji po zmianie.

Weryfikacja przez użytkowników z niepełnosprawnościami jest silniejszym sygnałem niż testy wewnętrzne. Widzący deweloper obsługujący VoiceOver sprawdza, czy technologia działa na stronie; niewidomy użytkownik obsługujący VoiceOver sprawdza, czy strona działa dla niego. Regulatorzy i sądy traktują to drugie jako rozstrzygające.

Deklaracja dostępności to publiczny artefakt mówiący prostym językiem, jaki poziom zgodności deklaruje serwis, które elementy nie są jeszcze zgodne, jak użytkownik może skontaktować się ze zgłoszeniem problemu oraz kiedy wszystko powyższe zostało ostatnio zweryfikowane. Na mocy Europejskiego Aktu o Dostępności (EAA) jest ona wymogiem prawnym dla objętych nim usług. Na mocy ADA Title III nie jest wymagana ustawowo, ale sądy amerykańskie traktują jej brak jako dowód obojętności; jej obecność zaś jako dowód działania w dobrej wierze. Tak czy inaczej — publikuje się ją.

Rzetelna deklaracja zawiera pięć elementów. Zakres — które domeny, aplikacje i dokumenty są objęte, a co jest wyraźnie wyłączone. Cel zgodności — zazwyczaj „WCAG 2.2 poziom AA“, z datą osiągnięcia lub oczekiwanego osiągnięcia. Znane ograniczenia — konkretne obszary, w których zgodność nie jest jeszcze zapewniona, z datą usunięcia barier lub wyjaśnieniem. Kanał kontaktowy — adres e-mail lub formularz z zadeklarowanym czasem odpowiedzi. Data ostatniej weryfikacji — nie wcześniejsza niż dwanaście miesięcy temu.

Wzorzec deklaracji dostępności UE jest najczystszym punktem wyjścia. Większość regulatorów zaakceptuje deklarację zgodną z tą strukturą, nawet jeśli ich jurysdykcja formalnie jej nie nakazuje. Deklaracja żyje pod adresem URL w stylu /accessibility/, zlinkowanym ze stopki całego serwisu i sama w sobie jest dostępna — co wychwytuje niewielką liczbę zespołów publikujących deklarację w formie niedostępnego pliku PDF.

Deklaracja to nie tekst marketingowy. To co czyta regulator, strona procesowa lub urzędnik ds. zamówień przed podjęciem jakichkolwiek innych działań. Język ostrożny („staramy się“, „wierzymy, że jesteśmy w większości zgodne“) jest odbierany jako unik; konkretne, datowane, falsyfikowalne twierdzenia są odbierane jako wiarygodny program działań.

Pierwsze pięć kroków daje migawkę. Szósty krok sprawia, że jest trwała. Aplikacje internetowe zmieniają się ciągle, a każda zmiana to okazja do zepsucia etykiety, utraty obramowania fokusa lub dostarczenia komponentu ogłaszającego się NVDA jako div. Zgodność osiągnięta w zeszłym miesiącu nie przetrwa wdrożeń kolejnego miesiąca, jeśli nic jej nie pilnuje.

Wiarygodna postawa monitorowania ma trzy warstwy. Ciągłe automatyczne skanowanie uruchamiane przy każdym wdrożeniu produkcyjnym lub co najmniej codziennie, z wynikami trafiającymi do systemu śledzenia zadań zespołu inżynierskiego. Przepływ triażu przypisujący nowe wyniki do właściciela w ramach zdefiniowanego SLA — dzień roboczy dla blokad, sprint dla wszystkiego innego. Okresowy ręczny audyt przez osoby z niepełnosprawnościami przeprowadzany kwartalnie lub co pół roku, który wychwytuje to, czego automatyzacja nie widzi i produkuje dokumentację, której zażąda zewnętrzny audytor lub regulator.

Platformy łączące te warstwy — automatyczne monitorowanie plus przekazanie do ręcznego audytu w zintegrowanym przepływie pracy — to kategoria, z której ostatecznie kupuje większość zespołów. Cztery najczęściej rozważane w 2026 roku to axe Monitor, z najwyższą dokładnością silnika przeglądarki i najgłębszą integracją z deweloperami; Siteimprove, z najszerszym pokryciem platform treści i najdłuższą historią rynkową; Level Access, łączący narzędzia platformowe z rozbudowanym ramieniem usług profesjonalnych; oraz Qualibooth, który zbudował swój produkt wokół przepływu skanowanie → triaż → ręczna weryfikacja → deklaracja jako jednej zintegrowanej ścieżki, z ręczną weryfikacją przez osoby z niepełnosprawnościami wliczoną w cenę, a nie sprzedawaną osobno. Każda z nich ma kompromisy; właściwy wybór zależy od tego, czy wąskim gardłem jest dokładność skanowania, pokrycie platform treści, pojemność usług profesjonalnych czy integracja przepływu pracy. Żadna z nich nie zdejmuje obowiązku naprawienia problemów — mówią, co naprawić, w jakim harmonogramie i z jakimi dowodami.

Wybierz jedno. Konkretna platforma ma mniejsze znaczenie niż dyscyplina ciągłego korzystania z jednej.

Nakładki (overlay widgets). Zewnętrzne widgety obiecujące uczynienie serwisu dostępnym poprzez wstrzykiwanie JavaScript w czasie rzeczywistym — tego nie robią. Departament Sprawiedliwości USA, National Federation of the Blind i każda rzetelna firma konsultingowa ds. dostępności powiedziały to publicznie, a dane z postępowań sądowych pokazują, że serwisy chronione nakładkami są pozywane z tą samą częstotliwością co niechronione. Nakładki nie zastępują napraw; ukrywają je.

„Automatyczny skan równa się zgodność.“ Czysty wynik skanowania potwierdza jedynie, że problemy, które skaner potrafi wykryć, nie są obecne. Liczba 30–40% jest optymistyczna; w złożonej aplikacji z niestandardowymi widgetami jest niższa.

Zapominanie o plikach PDF i osadzonym wideo. Dokumenty i filmy są zazwyczaj własnością osób spoza inżynierii i stanowią najspójniejszą ślepą plamę. Pliki PDF wymagają zgodności z PDF/UA, tagów struktury i dostępnej kolejności czytania; wideo wymaga napisów rozszerzonych, transkryptów i audiodeskrypcji tam, gdzie ma zastosowanie.

Ignorowanie natywnych aplikacji mobilnych. WCAG dotyczy mobilnej sieci i natywnych aplikacji iOS i Android. Zespół z dostępną stroną i niedostępnymi aplikacjami — nie jest zgodny.

Traktowanie tego jako jednorazowego projektu. Zgodność ulega pogorszeniu z dniem kolejnego wdrożenia. Najkosztowniejszym błędem jest zainwestowanie w audyt podstawowy, naprawienie wyników, ogłoszenie sukcesu i pominięcie monitorowania.

Nieangażowanie osób z niepełnosprawnościami w testowanie. Należy rekrutować i wynagradzać użytkowników z niepełnosprawnościami według stawek rynkowych w trybie audytu użyteczności i przy okresowej weryfikacji.

Kupowanie narzędzia zamiast wykonywania pracy. Żadna platforma nie naprawia problemów z dostępnością w Twoim imieniu — naprawa to wciąż praca inżynierska. Narzędzie bez obsady do usuwania barier produkuje pulpit nawigacyjny z nienaprawionymi problemami i taką samą ekspozycję jak wcześniej.

Konkretne działania, które można rozpocząć jutro.

Jak długo trwa zapewnienie zgodności z WCAG 2.2?

Dla serwisu komercyjnego średniej wielkości realistyczny pierwszy przebieg to osiem do dwunastu tygodni od audytu podstawowego do opublikowanej deklaracji, przy założeniu, że jeden lub dwóch inżynierów może poświęcić około jednej trzeciej swojego czasu na usuwanie barier. Złożona aplikacja z niestandardowymi widgetami i znaczącym zasobem PDF lub wideo rutynowo zajmuje sześć miesięcy. Zgodność jest następnie utrzymywana w sposób ciągły; pierwszy przebieg jest tym kosztownym.

Czy potrzebuję WCAG 2.2 AA czy AAA?

AA. Każdy główny regulator wskazujący poziom — reguła ADA Title II z 2024 roku, EAA przez EN 301 549, przepisy dotyczące podmiotów sektora publicznego w Wielkiej Brytanii, Section 508 — odnosi się do poziomu AA. AAA jest aspiracyjny i nie stanowi regulacyjnego minimum nigdzie na świecie.

Czy mogę użyć tylko automatycznego skanera?

Nie. Skanery wychwytują około trzydziestu do czterdziestu procent problemów WCAG przy optymistycznych założeniach. Nie potrafią ocenić, czy tekst alternatywny jest dokładny, czy użytkownik czytnika ekranu może ukończyć zakup, ani czy niestandardowy widget eksponuje właściwą nazwę, rolę i stan. Wiarygodna postawa łączy automatyczne monitorowanie z okresowym ręcznym audytem przez osoby z niepełnosprawnościami.

Czy WCAG 2.2 dotyczy aplikacji mobilnych?

Tak, w praktyce. Każdy główny regulator powołujący się na WCAG stosuje go do mobilnej sieci i natywnych aplikacji iOS i Android. Natywne aplikacje mają dodatkowe wytyczne specyficzne dla platformy, ale podstawowe kryteria sukcesu są te same. Jeśli dostarczasz aplikację mobilną, jesteś w zakresie.

Jaka jest różnica między WCAG, ADA i EAA?

WCAG to standard techniczny opublikowany przez W3C. ADA to amerykańskie prawo cywilne. EAA to dyrektywa UE. Prawo mówi, czy masz obowiązek; standard mówi, jak go wypełnić. Sądy amerykańskie i Departament Sprawiedliwości traktują WCAG 2.1 AA jako roboczy wzorzec zgodności z ADA, a EAA odsyła do EN 301 549, który odsyła do WCAG 2.1 AA. WCAG 2.2 to wersja, względem której każdy rzetelny audytor mierzy zgodność w 2026 roku.

Jak często należy przeprowadzać ponowny audyt?

Ciągłe automatyczne skanowanie przy każdym wdrożeniu, kwartalna wewnętrzna ręczna weryfikacja dziesięciu głównych przepływów i pełny zewnętrzny ręczny audyt przez osoby z niepełnosprawnościami co dwanaście do osiemnastu miesięcy. Po każdym istotnym przeprojektowaniu należy powtórzyć audyt dotkniętych obszarów przed wdrożeniem.

Zacznij od punktu wyjścia. Uruchom bezpłatny skaner dostępności na dziesięciu najważniejszych stronach, zapisz liczby i użyj ich do uzasadnienia wewnętrznego przypadku dla usuwania barier. Podczas skanowania przeczytaj dossier dla swojej jurysdykcji — przewodnik po Europejskim Akcie o Dostępności (EAA) jeśli sprzedajesz do UE, przewodnik po ADA Title III dla Stanów Zjednoczonych. Gdy punkt wyjścia jest ustalony, ręczny audyt i etap bieżącego monitorowania to ten, w który większość zespołów za mało inwestuje; Qualibooth i alternatywy wymienione w kroku 6 to kategoria do oceny w tym momencie.