WCAG 3 zmienia model zgodności. I bardzo dobrze, choć nie wszystko mnie przekonuje

10 września 2026 roku W3C opublikowało nową wersję roboczą WCAG 3.0. Dokument nadal jest projektem roboczym (Working Draft), a samo W3C wyraźnie zaznacza, że będzie się on jeszcze istotnie zmieniał. Wrześniowa wersja jest jednak ważna, bo po raz pierwszy tak wyraźnie pokazuje, jak może wyglądać przyszły model zgodności, raportowania wyników i dokumentowania procesu zapewniania dostępności.

To nie jest już tylko przebudowa listy kryteriów. W3C próbuje odpowiedzieć na problem, z którym audytorzy i organizacje mierzą się od dawna: dwa produkty mogą być opisane podobnym wynikiem zgodności, a jednocześnie dawać użytkownikowi zupełnie inne doświadczenie. Jeden może zawierać dziesiątki uciążliwych, ale możliwych do obejścia problemów, a drugi jeden błąd, który całkowicie blokuje złożenie wniosku, dokonanie płatności albo zalogowanie się do usługi.

W klasycznym podejściu wynik nadal sprowadza się przede wszystkim do tego, czy określone kryteria zostały spełnione. Taka jednoznaczność ma ogromną wartość, bo ogranicza uznaniowość i daje wspólny punkt odniesienia. Jednocześnie sama lista spełnionych i niespełnionych kryteriów nie zawsze wystarcza do ustalenia, co naprawdę dzieje się z użytkownikiem i co organizacja powinna naprawić najpierw.

WCAG 3 próbuje zachować twarde wymagania techniczne, ale jednocześnie dodać do nich więcej kontekstu. Pojawia się klasyfikowanie skutków barier, badanie całych zadań użytkownika, dokładniejsze określanie środowisk technologii asystujących oraz deklaracje dotyczące procesów stosowanych przez organizację. Moim zdaniem sam kierunek jest bardzo dobry, choć im bardziej rozbudowany staje się model raportowania, tym większe jest ryzyko, że standard stanie się trudniejszy do wyjaśnienia osobom, które nie zajmują się dostępnością zawodowo.

Jedna zgodność zamiast A, AA i AAA

Jedna z najważniejszych zmian dotyczy samego pojęcia zgodności. W aktualnym projekcie WCAG 3 nie ma znanego z WCAG 2.x podziału na poziomy A, AA i AAA. Aby określony zakres produktu był zgodny z WCAG 3, muszą zostać spełnione wszystkie wymagania podstawowe (core requirements).

Obok nich pojawiają się wymagania uzupełniające (supplemental requirements). Nie są one wymagane do podstawowej zgodności, ale mają pozwalać na poprawę dostępności ponad minimalny poziom. Mogą obejmować rozwiązania bardziej wymagające technicznie, droższe we wdrożeniu albo zapewniające wyższą jakość doświadczenia użytkownika. W3C

Trzecim elementem są deklaracje praktyk (assertions). To udokumentowane stwierdzenia dotyczące działań podejmowanych przez organizację, na przykład testów z technologiami asystującymi, szkoleń pracowników, testów użyteczności czy procesów oceny dostępności. W projekcie są jeszcze także zalecane praktyki (recommended practices), które mają charakter informacyjny i nie są wymagane do osiągnięcia zgodności.

Ten podział uważam za sensowny. Dzisiejszy poziom AAA nigdy nie był prostym „wyższym AA” i w wielu przypadkach pełna zgodność z nim była mało realistycznym celem dla całego produktu. Rozdzielenie tego, co jest wymaganym minimum, od rozwiązań zapewniających dodatkową jakość może być znacznie czytelniejsze.

Warunek jest jeden: wymagania dodatkowe i deklaracje organizacyjne nie mogą pozwolić na przykrywanie istotnych błędów technicznych. W tym miejscu projekt jest na razie jasny: deklaracja procesu nie zastępuje spełnienia wymagania podstawowego.

Sześć poziomów raportowania, ale tylko jeden próg zgodności

WCAG 3 proponuje jednocześnie sześć poziomów raportowania (reporting tiers). Nie są to jednak poziomy zgodności podobne do A, AA i AAA. W3C wprost zaznacza, że poziom trzeci odpowiada właściwej zgodności z WCAG 3, a pozostałe mają pokazywać postęp przed jej osiągnięciem albo działania wykraczające poza wymagane minimum.

Pierwszy poziom, Unikanie szkody fizycznej (Avoid physical harm), wymaga spełnienia wymagań związanych ze szkodą fizyczną i ryzykiem. Drugi, Podstawowy dostęp (Foundational access), dodaje wymagania oznaczone jako bariery. Trzeci poziom, Zgodność (Conformance), obejmuje również wymagania dotyczące utrudnień, a więc wszystkie wymagania podstawowe. W3C

Dopiero powyżej tego progu pojawiają się Bronze, Silver i Gold. Brąz (Bronze) ma wymagać dodatkowej liczby wymagań uzupełniających oraz deklaracji dotyczących treści. Srebro (Silver) ma oznaczać jeszcze szerszy zakres, natomiast Złoto (Gold) ma obejmować także deklaracje dotyczące całej organizacji. W3C nie ustaliło jeszcze dokładnej liczby dodatkowych wymagań potrzebnych do osiągnięcia tych poziomów. W tabeli nadal widnieją wartości oznaczone jako TBD.

To rozwiązanie ma dużą zaletę: pozwala pokazać postęp organizacji bez rozmywania samego pojęcia zgodności. Można powiedzieć, że produkt osiągnął określony poziom podstawowego dostępu, ale nadal nie spełnia wszystkich wymagań koniecznych do deklarowania zgodności.

Mam jednak wątpliwość, czy sześć poziomów nie okaże się zbyt skomplikowanych komunikacyjnie. Już dziś trzeba często tłumaczyć, czym różni się spełnienie pojedynczych kryteriów od pełnej zgodności z poziomem AA. Przy WCAG 3 może dojść konieczność wyjaśniania, dlaczego produkt na poziomie drugim nadal nie jest zgodny, a Bronze nie jest nowym odpowiednikiem A.

Nie każdy błąd ma mieć taki sam ciężar

Jedna z ciekawszych zmian dotyczy klasyfikowania wymagań według skutków ich niespełnienia. W aktualnym projekcie pojawiają się cztery kategorie: szkoda fizyczna (Physical harm), ryzyko (Risk), bariera (Barrier) oraz utrudnienie (Friction).

Kategoria szkody fizycznej dotyczy sytuacji, w których brak spełnienia wymagania może prowadzić do bezpośredniego zagrożenia zdrowia lub bezpieczeństwa. Ryzyko obejmuje między innymi nieuzasadnione zwiększenie ryzyka finansowego, medycznego, prawnego, dotyczącego prywatności albo bezpieczeństwa. Bariera to problem, który może uniemożliwić osobie z niepełnosprawnością dalsze wykonanie zadania, natomiast utrudnienie może sprawić, że wykonanie zadania będzie trudniejsze, wolniejsze albo bardziej obciążające.

To uważam za jedną z najmocniejszych części obecnego projektu. W praktycznych audytach i tak od dawna trzeba ustalać priorytety, bo organizacja musi wiedzieć, co poprawić najpierw. Informacja, że znaleziono 42 naruszenia, bez wskazania ich konsekwencji dla użytkownika jest po prostu mało użyteczna.

Trzeba jednak bardzo uważać na kategorię utrudnienia. Samo określenie może sugerować coś mało istotnego, podczas gdy kilka takich problemów występujących jednocześnie może faktycznie uniemożliwić użytkownikowi wykonanie zadania. W3C samo zwraca na to uwagę i wskazuje, że kumulacja wielu problemów oznaczonych jako utrudnienie może prowadzić do rzeczywistego zablokowania użytkownika.

W3C rozważa również alternatywny model oparty na punktacji. Jest on opisany w dokumencie wyjaśniającym (Explainer), ale nie stanowi obecnie przyjętej części modelu zgodności. To ważne rozróżnienie, bo na tym etapie nie ma podstaw, żeby mówić o „punktowym WCAG 3” jako o czymś przesądzonym.

Audyt będzie musiał dokładniej mówić, na czym wykonano test

Bardzo praktycznym elementem projektu jest rozwijane pojęcie wsparcia dostępności (accessibility supported). Sama metoda techniczna ma liczyć się jako sposób spełnienia wymagania tylko wtedy, gdy rzeczywiście jest obsługiwana przez przeglądarki i technologie asystujące używane przez odbiorców.

W tym celu WCAG 3 wykorzystuje zestaw wsparcia dostępności (accessibility support set). Ma on wskazywać konkretne środowiska, na których opiera się ocena, czyli między innymi przeglądarki, technologie asystujące oraz ustawienia dostępności. Projekt przewiduje zestaw domyślny oraz możliwość definiowania zestawów alternatywnych dla innych języków, regionów, technologii i środowisk.

To bardzo dobra zmiana. Stwierdzenie „sprawdzono czytnikiem ekranu” już dziś jest za mało precyzyjne. Interfejs może działać inaczej w NVDA z Chrome, inaczej w NVDA z Firefoxem, a jeszcze inaczej w VoiceOverze z Safari. Różnice mogą wynikać z technologii asystującej, przeglądarki albo samej implementacji komponentu.

Jeśli ten mechanizm pozostanie w finalnym WCAG 3, deklaracja zgodności będzie znacznie bardziej uczciwa. Nie będziemy mówić abstrakcyjnie, że „działa z technologiami asystującymi”, tylko wskazywać, w jakim rzeczywiście sprawdzonym środowisku zostało to potwierdzone.

To będzie też coraz ważniejsze wraz z rozwojem AI w technologiach asystujących. Jeżeli jedna technologia potrafi dzięki modelowi AI zinterpretować źle opisany element, a druga nie, nie oznacza to przecież, że sam produkt jest poprawnie dostępny. Trzeba będzie jeszcze dokładniej oddzielać poprawność produktu od zdolności konkretnego narzędzia do obejścia jego błędów.

WCAG 3 formalizuje badanie całych zadań użytkownika

Projekt coraz mocniej posługuje się pojęciem przepływu zadania (task flow). Chodzi o serię widoków i czynności potrzebnych użytkownikowi do osiągnięcia konkretnego celu. Z perspektywy dostępności to ważniejsze niż badanie ekranów w oderwaniu od siebie.

Użytkownik nie korzysta z urzędu elektronicznego po to, żeby otworzyć podstronę numer pięć. Chce złożyć wniosek, zapisać dziecko, dokonać płatności, zalogować się, pobrać decyzję albo przesłać dokument. Jeśli cały proces składa się z ośmiu kroków i jeden z nich blokuje obsługę klawiaturą, to nie ma większego znaczenia, że siedem pozostałych jest wykonanych idealnie.

Dobrzy audytorzy już dziś badają pełne procesy, więc sama idea nie jest rewolucyjna. Nowością jest raczej to, że takie podejście coraz wyraźniej trafia do struktury WCAG 3, zamiast pozostawać wyłącznie elementem dobrej metodologii badania.

Dla administracji publicznej jest to szczególnie istotne. Nie wystarczy sprawdzić sam formularz. Trzeba przejść cały proces: odnalezienie usługi, rozpoczęcie sprawy, uwierzytelnienie, wprowadzenie danych, obsługę błędów, zatwierdzenie, wysłanie i odebranie potwierdzenia.

Deklaracje praktyk: najciekawszy i jednocześnie najbardziej ryzykowny element

Najbardziej interesują mnie jednak deklaracje praktyk (assertions). W3C chce umożliwić organizacji formalne udokumentowanie działań, które wspierają dostępność produktu. Mogą one dotyczyć między innymi przeglądów prostego języka, badań użyteczności, testów z technologiami asystującymi, szkoleń pracowników czy publicznych deklaracji dotyczących dostępności.

W aktualnym projekcie deklaracje są podzielone między te dotyczące treści (Content) oraz te dotyczące organizacji (Organization). Pierwsza grupa może obejmować na przykład testy z technologiami asystującymi lub stosowanie określonego przewodnika redakcyjnego. Druga dotyczy mechanizmów organizacyjnych, takich jak szkolenia pracowników czy publiczne zobowiązania w zakresie dostępności.

W3C podaje już bardzo konkretne przykłady takich deklaracji. W obecnym dokumencie można znaleźć między innymi stwierdzenie, że organizacja dokonała przeglądu formularzy pod kątem ograniczenia możliwości popełniania błędów albo że produkty i procesy nie zawierają nieuzasadnionych ograniczeń czasowych.

To jest dla mnie bardzo ważny kierunek, bo dostępność rzeczywiście nie powstaje podczas audytu. Powstaje wcześniej: przy zamówieniu systemu, projektowaniu, tworzeniu komponentów, przygotowywaniu treści, kontroli przed publikacją, odbiorze wykonawcy i późniejszym utrzymaniu produktu.

Jednocześnie właśnie tutaj widzę największe ryzyko. Dobrze opisana procedura nie może stać się substytutem dostępnego produktu. Organizacja może mieć świetne szkolenia, piękną procedurę kontroli i rozbudowaną politykę dostępności, a jednocześnie udostępniać formularz, którego nie da się obsłużyć klawiaturą.

Na obecnym etapie WCAG 3 chroni przed takim rozmyciem, ponieważ deklaracje nie zastępują wymagań podstawowych. Co więcej, sama grupa robocza zaznacza, że nie zdecydowała jeszcze, czy jakiekolwiek deklaracje powinny być wymagane do osiągnięcia podstawowej zgodności.

W projekcie są już konkretne wymagania, nie tylko model raportowania

WCAG 3 nie jest wyłącznie dyskusją o poziomach i sposobie raportowania. W wersji z 10 września znajdują się już wymagania oznaczone jako rozwijane (Developing), czyli takie, które osiągnęły bardziej zaawansowany etap prac. W3C zaznacza jednocześnie, że wymagania nadal na wcześniejszym etapie pozostają w wersji redakcyjnej dokumentu.

Przykładowe wymaganie podstawowe dotyczące automatycznego wprowadzania danych mówi, że interfejs nie może blokować automatycznego wprowadzania danych osobowych przez przeglądarkę, narzędzia zewnętrzne czy wklejanie. Do informacji osobowych zaliczono między innymi nazwiska i hasła.

Inne wymaganie podstawowe dotyczy testów funkcji poznawczych. Proces powinien być możliwy do ukończenia bez konieczności wykonywania zadania wymagającego określonej funkcji poznawczej. W dokumencie jako przykład podano uwierzytelnianie i logowanie.

W projekcie znalazło się również wymaganie, zgodnie z którym wybory niosące konsekwencje prawne, finansowe, dotyczące prywatności lub bezpieczeństwa powinny być uzupełnione opisem korzyści, ryzyka i potencjalnych konsekwencji dokonywanego wyboru. To przykład bardzo dobrze pokazujący, że WCAG 3 chce wyjść poza klasyczne techniczne patrzenie na interfejs.

Są też wymagania uzupełniające. Przykładowo w procesach z ograniczeniem czasowym użytkownik powinien mieć możliwość przedłużenia czasu albo wyłączenia limitu, jeśli czas nie jest istotą samego zadania. Jeszcze bardziej rygorystyczny wariant zakłada całkowity brak niepotrzebnych ograniczeń czasowych.

Warto też zwrócić uwagę na wymagania dotyczące spójności pomiędzy widokami. Projekt przewiduje między innymi zachowanie względnie stałego położenia kontrolek o tym samym przeznaczeniu oraz spójnego układu elementów strukturalnych. To szczególnie ciekawe w kontekście interfejsów generowanych dynamicznie przez AI, gdzie możliwość automatycznej przebudowy ekranu może bardzo łatwo wejść w konflikt z potrzebą przewidywalności interfejsu.

WCAG 3 ma obejmować znacznie więcej niż klasyczną stronę internetową

Zmienia się również zakres. Aktualny projekt został przygotowany z myślą nie tylko o statycznej zawartości stron internetowych, ale również o aplikacjach, urządzeniach mobilnych i ubieralnych, treściach interaktywnych, multimediach oraz rozwiązaniach rozszerzonej i wirtualnej rzeczywistości. W3C uwzględnia też powiązane narzędzia: przeglądarki, technologie asystujące, systemy zarządzania treścią, narzędzia autorskie i narzędzia testowe.

To nie jest tylko kosmetyczna zmiana nazwy. WCAG 3 rozwijane jest jako Wytyczne W3C dotyczące dostępności (W3C Accessibility Guidelines), a nie wyłącznie jako Web Content Accessibility Guidelines. Ambicją jest stworzenie modelu lepiej odpowiadającego środowisku, w którym granica pomiędzy stroną, aplikacją, urządzeniem, technologią asystującą i usługą cyfrową jest coraz mniej wyraźna.

Moim zdaniem to konieczna zmiana. Próba ciągłego dopasowywania standardu zaprojektowanego pierwotnie wokół dokumentów i stron internetowych do aplikacji mobilnych, zaawansowanych aplikacji webowych, rzeczywistości rozszerzonej czy generatywnych interfejsów ma swoje granice. Jeśli WCAG 3 ma być standardem na kolejne lata, musi być projektowane dla środowiska szerszego niż tradycyjny Web.

Czy ten model będzie lepszy od WCAG 2?

Na tym etapie nie da się jeszcze odpowiedzieć jednoznacznie. Sama grupa W3C prosi obecnie szczególnie o komentarze dotyczące modelu zgodności i sprawdza, czy zaproponowany system rzeczywiście będzie lepszy od wcześniejszych wersji. Równolegle analizowane jest alternatywne podejście punktowe.

Mnie przekonują trzy rzeczy. Pierwszą jest wyraźniejsze rozróżnienie między problemem powodującym niewygodę a takim, który całkowicie blokuje zadanie. Drugą jest dokładniejsze dokumentowanie technologii, na których rzeczywiście zweryfikowano dostępność. Trzecią jest uznanie, że trwała dostępność produktu ma również wymiar organizacyjny i nie da się jej utrzymać wyłącznie okresowymi audytami.

Najwięcej obaw mam natomiast wobec złożoności całego modelu. Sześć poziomów raportowania, wymagania podstawowe, wymagania uzupełniające, deklaracje, zalecane praktyki, tagi skutków i zestawy wsparcia dostępności dają bardzo bogaty opis produktu. Mogą jednak stworzyć standard, który będzie precyzyjny dla specjalistów i bardzo trudny do komunikowania użytkownikowi, zamawiającemu czy kierownictwu organizacji.

WCAG potrzebuje precyzji, ale potrzebuje też zrozumiałości. Jeżeli po opublikowaniu standardu będziemy musieli poświęcać pół spotkania na tłumaczenie, dlaczego Bronze jest poziomem powyżej zgodności, a poziom drugi nadal oznacza jej brak, będzie to realny problem praktyczny.

Co powinien zrobić audytor dzisiaj?

Na pewno nie zaczynać oferować „audytów WCAG 3”. W3C samo bardzo wyraźnie ostrzega, że jest to nieukończony projekt, który będzie się istotnie zmieniał, i że nie należy powoływać się na niego inaczej niż na rozwijany dokument roboczy. W3C Lista Mailingowa

Nie ma również powodu, żeby wpisywać WCAG 3 do deklaracji dostępności albo wymagań przetargowych jako standard zastępujący WCAG 2.2. Tego etapu jeszcze nie osiągnęliśmy.

Możemy natomiast już dzisiaj wykorzystywać część pomysłów zawartych w projekcie, bo po prostu poprawiają jakość audytu. Warto dokładnie zapisywać środowisko testowe, wskazywać użyte technologie asystujące i przeglądarki, badać kompletne zadania zamiast przypadkowych ekranów oraz wyraźniej opisywać konsekwencje poszczególnych barier dla użytkownika.

Warto również po audycie zadawać drugie pytanie: nie tylko „co jest niedostępne?”, ale również „dlaczego organizacja dopuściła do powstania tego problemu?”. Jeżeli po każdej aktualizacji wracają źle opisane formularze, niedostępne dokumenty czy problemy z klawiaturą, kolejne poprawienie tych samych błędów nie rozwiązuje przyczyny.

To akurat nie wymaga czekania na WCAG 3.

Najważniejsze jest to, czego nie da się zamknąć w jednym wyniku

WCAG 2.x dało dostępności cyfrowej coś niezwykle cennego: wspólny język i zestaw sprawdzalnych kryteriów. Nie chciałbym, żeby WCAG 3 utraciło tę jednoznaczność w pogoni za bardziej rozbudowanym modelem. Dostępność nadal musi opierać się na wymaganiach, które można sprawdzić i których niespełnienie można jednoznacznie wskazać.

Jednocześnie obecny model nie mówi wszystkiego. Sam wynik zgodności nie zawsze pokazuje, czy użytkownik faktycznie może wykonać kluczowe zadanie, jak poważne są znalezione bariery, na jakich technologiach przeprowadzono badanie i czy organizacja potrafi utrzymać dostępność po zakończeniu audytu.

Wrześniowy projekt WCAG 3 próbuje te elementy połączyć. Na razie robi to miejscami bardzo dobrze, a miejscami tworzy konstrukcję, która może okazać się zbyt skomplikowana. Dlatego najbardziej interesujące pytanie na kolejne etapy prac nie brzmi dla mnie: „kiedy WCAG 3 zastąpi WCAG 2?”. Znacznie ważniejsze jest to, czy W3C uda się stworzyć standard, który będzie jednocześnie bardziej zbliżony do rzeczywistego doświadczenia użytkownika i nadal wystarczająco jednoznaczny, żeby można go było rzetelnie audytować.

Jeśli to się uda, WCAG 3 nie będzie po prostu kolejną wersją checklisty. Może zmienić sposób, w jaki w ogóle opisujemy dostępność produktu: od pojedynczego kryterium, przez całe zadanie użytkownika, aż po proces organizacyjny, który ma sprawić, że po kolejnej aktualizacji nie zaczniemy wszystkiego od początku.