WCAG 3: co roboczy projekt oznacza dla obecnych serwisów

Opis obrazu: Wydrukowany roboczy projekt WCAG 3 z kolorowymi zakładkami na biurku obok dokumentu WCAG 2.2 — wizualny wyróżnik preambuły do WCAG 3.

Czas czytania: 12 minut

WCAG 3 — wytyczne dostępności nowej generacji, które W3C opracowuje pod roboczą nazwą Silver od 2017 roku — to w połowie 2026 roku wciąż roboczy projekt W3C. Ten jeden fakt jest najważniejszą rzeczą, jaką należy o nim wiedzieć. Nie jest to Rekomendacja, nie jest to Rekomendacja Kandydacka i nic w nim nie może jeszcze być przytaczane przez regulatora, sąd ani urzędnika zamówień publicznych z mocą prawną. WCAG 2.2 pozostaje standardem, według którego świat przeprowadza dziś audyty, a EN 301 549, amerykańska Sekcja 508 i krajowe implementacje Dyrektywy o dostępności stron internetowych odwołują się do WCAG 2.x. WCAG 3 to zamierzone architektoniczne przepisanie sposobu pomiaru zgodności dostępności — i zapowiedź tego, jak będzie wyglądać kolejna dekada przyjmowania regulacji, gdy standard się ustabilizuje.

Niniejsze wprowadzenie omawia, czym jest WCAG 3, jakie zmiany strukturalne wprowadza, jak działają proponowane poziomy zgodności brąz/srebro/złoto, kiedy realnie może pojawić się Rekomendacja Kandydacka, jakie napięcia polityczne istnieją z WCAG 2.2 (które krajowe regulatorzy wciąż wdrażają), oraz co zespoły pracujące dziś na wersji 2.x powinny z tym zrobić. Krótka wersja: zapoznaj się z roboczym projektem, nie refaktoryzuj pod niego kodu i traktuj każdego dostawcę obiecującego dziś „zgodność z WCAG 3“ jako osobę albo zdezorientowaną, albo coś sprzedającą.

Czym WCAG 3 faktycznie jest — i czym nie jest

WCAG 3 to robocza nazwa nowej ścieżki Rekomendacji w Grupie Roboczej ds. Wytycznych Dostępności (AG WG) W3C, odrębnej od linii WCAG 2.x. Projekt ruszył w 2017 roku pod nazwą Silver (symbol chemiczny Ag — żart nawiązujący do „Accessibility Guidelines“) i pierwszy publiczny roboczy projekt ukazał się w styczniu 2021 roku. Najnowszy roboczy projekt to wersja dostępna pod adresem w3.org/TR/wcag-3.0/ — opatrzona, jak każdy poprzedni projekt, nagłówkiem ostrzegawczym: „Ten dokument jest roboczym projektem. Nie jest stabilny i nie powinien być cytowany ani stosowany jako podstawa implementacji.“

Ten nagłówek ma realne znaczenie. W procesie W3C dokument przechodzi przez pięć poziomów dojrzałości: Roboczy projekt, Rekomendacja Kandydacka (CR), Proponowana Rekomendacja (PR), Rekomendacja (REC) i wreszcie Rekomendacja Zastąpiona. WCAG 2.0 osiągnął status REC w grudniu 2008 roku. WCAG 2.1 — w czerwcu 2018 roku. WCAG 2.2 — w październiku 2023 roku. WCAG 3 nie wkroczył jeszcze w etap CR, a W3C wprost wskazał, że zanim to nastąpi, konieczne jest rozstrzygnięcie kilku istotnych kwestii projektowych. Aktualny stan, według najnowszego opublikowanego projektu, to dokument badawczo-projektowy z dopracowanymi sekcjami i wyraźnie oznaczonymi otwartymi problemami — nie stabilna specyfikacja.

Czym WCAG 3 nie jest: nie jest zastąpieniem WCAG 2.2. W3C stwierdził, że WCAG 2.2 i WCAG 3 będą prawdopodobnie współistnieć przez rozszerzony okres przejściowy po osiągnięciu przez WCAG 3 statusu Rekomendacji. WCAG 3 to też nie „WCAG 2.3“ — model treści, model zgodności i struktura redakcyjna są na tyle inne, że ponumerowanie w ramach linii 2.x zostało odrzucone na wczesnym etapie prac projektowych.

Cel i zakres: po co nowa linia

Trzy strukturalne problemy z WCAG 2.x zadecydowały o rozpoczęciu nowej linii zamiast kontynuowania numeracji 2.x.

Po pierwsze, zakres. WCAG 2.x to technicznie wytyczne dostępności treści internetowych — dotyczą treści renderowanych w kliencie użytkownika. Mandat Grupy Roboczej rozszerzył się jednak przez dekadę na cały obszar cyfrowej dostępności: natywne aplikacje mobilne, kioski, interfejsy głosowe, wirtualną i rozszerzoną rzeczywistość, narzędzia AAC (komunikacja wspomagająca i alternatywna), konwersacyjne powierzchnie AI. WCAG 3 jest projektowany od podstaw jako niezależny od treści i platformy — ten sam zestaw wytycznych ma obejmować stronę internetową, ekran aplikacji natywnej, przepływ głosowy i okno dialogowe kiosku bez konieczności sporządzania trzech różnych deklaracji zgodności ze standardem, którego nazwa wciąż zawiera słowo „Web“.

Po drugie, model zgodności. Zgodność z WCAG 2.x jest binarna: każde mające zastosowanie kryterium sukcesu albo jest spełnione, albo nie, a pojedyncze niespełnienie kryterium na poziomie AA niszczy deklarację zgodności strony. Sprawdza się to przy ostrych kryteriach na poziomie interfejsu, takich jak „używaj semantycznych nagłówków“ — gorzej działa przy kryteriach, gdzie leżąca u podstaw bariera jest stopniowalna, a nie kategoryczna, jak złożoność języka, obciążenie poznawcze czy zrozumiałość komunikatu o błędzie. WCAG 3 wprowadza mierzone wyniki, dzięki czemu strona może uzyskać mierzalnie lepszy rezultat w kategorii „przejrzysty język“ bez wymuszania binarnej oceny, której wymaga wersja 2.x.

Po trzecie, użytkownicy dotąd słabo obsługiwani. WCAG 2.x ma dobrze udokumentowane luki w zakresie użytkowników z niepełnosprawnościami poznawczymi, użytkowników z niskim poziomem piśmienności, użytkowników korzystających z urządzeń AAC, użytkowników interfejsów głosowych, użytkowników głuchoniewidomych obsługujących brajlowski wyświetlacz odświeżalny, a także nowych modalności technologii wspomagających, takich jak śledzenie wzroku i interfejsy mózg-komputer. Kryteria sukcesu 2.x można zastosować do tych użytkowników — ale były tworzone z myślą przede wszystkim o użytkownikach czytników ekranu, lup, klawiatury i słabowidzących. Architektura wytycznych WCAG 3 wyraźnie zaprasza do wniesienia wkładu w zakresie kognitywnych, głosowych, AAC i nowych modalności AT jako równorzędnych celów.

Kluczowe zmiany: wyniki zamiast kryteriów sukcesu

Najważniejsza zmiana w WCAG 3 — z której wynikają wszystkie pozostałe — to przejście od kryteriów sukcesu do wyników.

Kryterium sukcesu WCAG 2.x to binarne, weryfikowalne stwierdzenie. 1.4.3 Kontrast (minimalny) mówi: tekst i obrazy tekstu mają współczynnik kontrastu co najmniej 4,5:1, z dwoma konkretnymi wyjątkami. Strona albo spełnia kryterium, albo nie. Jest to doskonałe dla powtarzalnego testowania i zastosowań konfrontacyjnych (spory sądowe, audyty, zamówienia publiczne), ale karzące w przypadku kryteriów, gdzie leżąca u podstaw potrzeba użytkownika nie rozkłada się na zaliczone/niezaliczone.

Wynik WCAG 3, w obecnym projekcie, to weryfikowalne stwierdzenie powiązane z co najmniej jedną metodą opisującą sposób weryfikacji wyniku i sposób punktowania. Wyniki mogą być binarne tam, gdzie taka forma jest właściwa (pole formularza albo ma etykietę, albo nie), ale mogą być też punktowane w skali numerycznej, gdy potrzeba użytkownika jest stopniowalna (jak czytelny jest ten akapit; jak możliwy do naprawienia jest ten stan błędu; jak przewidywalna jest ta nawigacja). Wynik zgodności produktu jest następnie obliczany na podstawie wszystkich wyników, a nie uzależniony od spełnienia każdego kryterium.

Z tego wynikają kolejne zmiany architektoniczne:

• Wytyczne jako jednostka organizacyjna. WCAG 3 grupuje wyniki w wytyczne (odpowiadające mniej więcej warstwie zasad i wytycznych WCAG 2.x, ale sformułowane bardziej deklaratywnie).
• Metody, nie techniki. WCAG 2.x zawiera informacyjne techniki sugerujące sposoby spełnienia kryterium sukcesu. WCAG 3 ma normatywne metody opisujące weryfikację wyniku. Przejście od „informacyjnych“ do „normatywnych“ ma znaczenie: procedura testowania jest integralną częścią wytycznych, a nie odrębnym, podważalnym uzupełnieniem.
• Testy atomowe i holistyczne. Niektóre wyniki są testowane na poziomie atomowym (jeden element, jedna reguła), inne holistycznie — w całym widoku lub przepływie zadań. Wyniki dotyczące obciążenia poznawczego i przejrzystości języka są z natury holistyczne; wyniki dotyczące kontrastu i etykietowania — z natury atomowe. WCAG 3 czyni to rozróżnienie wyraźnym w metodzie.
• Kategorie potrzeb funkcjonalnych. Projekt wprowadza potrzeby funkcjonalne — wzrok, słuch, poznanie, mowa, mobilność, percepcja wielozmysłowa — jako oś przekrojową. Każdy wynik jest powiązany z potrzebami funkcjonalnymi, które adresuje, dzięki czemu tester lub regulator może zapytać „pokaż mi wszystko, co dotyczy użytkowników z potrzebami poznawczymi“ bez konieczności ponownego czytania całego dokumentu.

Poziomy zgodności: brąz, srebro, złoto

Gdzie WCAG 2.x ma trzy poziomy zgodności — A, AA, AAA — WCAG 3 proponuje trzy poziomy zgodności: Brąz, Srebro i Złoto. Etykiety celowo nie są literami i celowo nie kumulują się regułami; sygnalizują, że wyższe poziomy odzwierciedlają znacząco lepsze doświadczenie dla użytkowników — nie „ten sam produkt z większą liczbą odhaczonych pól“.

Brąz to minimalny poziom zgodności. Ma odpowiadać mniej więcej „odpowiednikowi WCAG 2.x AA“ — produkt zgodny z Brązem nie powinien być istotnie gorszy niż dzisiejszy produkt zgodny z AA. Zgodność z Brązem wymaga zaliczenia wszystkich błędów krytycznych (wyniki oznaczone w projekcie jako fundamentalne bariery — na przykład brak tekstu alternatywnego dla obrazów informatywnych) i osiągnięcia zdefiniowanego progu punktowego w produktcie. Projekt zakłada, że błędy krytyczne pozostają binarne nawet w modelu punktowanym: każdy błąd krytyczny blokuje zgodność z Brązem niezależnie od wyników w innych obszarach.

Srebro to poziom pośredni, odpowiadający mniej więcej produktowi solidnie AA-plus — lepszemu od progu WCAG 2.x AA, ale nie osiągającemu jeszcze AAA. Srebro wymaga zazwyczaj wyższego progu punktowego dla tych samych wyników oraz zaliczenia dodatkowych wyników niewymaganych na poziomie Brązu. Konkretne progi są wciąż przedmiotem konsultacji w roboczym projekcie.

Złoto to najwyższy poziom. Ma reprezentować produkt zaprojektowany i przetestowany pod kątem pełnego zakresu potrzeb funkcjonalnych ujętych w wytycznych — nie tylko tych, które dotychczas były objęte kryteriami WCAG 2.x AA. To poziom, w którym wyniki dotyczące modalności kognitywnych, głosowych, AAC i nowych AT mają największe znaczenie, ponieważ dotyczą grup użytkowników, w przypadku których zgodność z wersją 2.x nie daje porównywalnych rezultatów.

Dwie ważne właściwości modelu poziomów warte odnotowania. Po pierwsze, zakres dotyczy widoku lub przepływu, a nie strony: produkt może mieć różne poziomy zgodności na różnych powierzchniach, co jest bardziej uczciwe niż model per-strona WCAG 2.x dla złożonych aplikacji. Po drugie, deklaracja zgodności jest powiązana z metodami użytymi do jej weryfikacji — tak więc deklaracja Srebra w WCAG 3 powinna być powtarzalna przez innego testera podążającego tymi samymi metodami, czego deklaracje WCAG 2.x AA (opierające się w dużej mierze na ocenie testera na granicy) często nie zapewniają.

Nowe modalności technologii wspomagających

Istotnym zobowiązaniem redakcyjnym projektu WCAG 3 jest równorzędne traktowanie modalności technologii wspomagających, które WCAG 2.x historycznie adresował jedynie pośrednio.

Dostępność poznawcza to największy z tych obszarów rozszerzenia. Obecny projekt włącza prace nad wynikami opracowane wcześniej przez odrębną Grupę Zadaniową ds. Dostępności Poznawczej W3C (dokument Making Content Usable for People with Cognitive and Learning Disabilities). Wyniki w tym obszarze dotyczą przejrzystości języka, przewidywalności nawigacji, wsparcia dla orientacji i wyszukiwania drogi, zapobiegania błędom i odzyskiwania po nich oraz minimalizowania zbędnego obciążenia poznawczego. Wiele z tych wyników jest punktowanych, a nie binarnych — nie ma czystego zaliczone/niezaliczone dla „czy to zdanie jest wystarczająco czytelne“ — i właśnie do obsługi takich przypadków zbudowano model zgodności oparty na punktach.

Interfejsy głosowe i konwersacyjne są wyraźnie ujęte w zakresie. Wyniki dotyczą rozpoznawalności poleceń głosowych, wykrywalności komend, ścieżki naprawczej po błędnym rozpoznaniu głosu oraz równoważności interakcji głosowej i wizualnej w interfejsach dwumodalnych. To ta część projektu, w której architektura wytycznych niezależnych od platformy ma największe znaczenie: przepływ wyłącznie głosowy na inteligentnym głośniku nie może w sensowny sposób być testowany według kryteriów sukcesu „treści internetowych“ WCAG 2.x, ale może być testowany według wyników WCAG 3 opracowanych jako modalnie neutralne.

Użytkownicy AAC (komunikacja wspomagająca i alternatywna) — osoby komunikujące się głównie za pomocą tablic symboli, systemów wymiany obrazkowej lub urządzeń generujących mowę — są wyraźnie uwzględnieni w celach badań użytkowników projektu. Wyniki odnoszą się tu do spójności symboli, traktowania wejścia AAC jako równorzędnego trybu interakcji oraz poznawczej przewidywalności stanów dialogowych, po których musi się poruszać użytkownik AAC.

Nowe AT — śledzenie wzroku, przełączniki, interfejsy mózg-komputer, śledzenie głowy i powierzchnie wspomagające urządzeń mieszanej rzeczywistości — są wymienione w harmonogramie projektu. Robocze stanowisko Grupy Roboczej zakłada, że architektura wytycznych powinna uwzględniać te modalności bez konieczności enumerowania każdej możliwej AT; oś potrzeb funkcjonalnych jest jednym z mechanizmów to umożliwiających.

Harmonogram: kiedy może pojawić się Rekomendacja Kandydacka

Uczciwa odpowiedź brzmi: nikt spoza AG WG nie może podać pewnej daty, a nikt wewnątrz nie opublikował żadnej. Proces W3C jest oparty na konsensusie, a kwestie projektowe wciąż otwarte w WCAG 3 — precyzyjna metodologia punktowania, dokładne progi dla Brązu/Srebra/Złota, format deklaracji zgodności, weryfikowalność wyników poznawczych, relacja z WCAG 2.2 w okresie przejściowym — są niebanalne. Robocze projekty w każdej linii standardów mogą pozostawać na tym poziomie dojrzałości przez lata.

Co można powiedzieć z rozsądną pewnością, to kształt ścieżki. Rekomendacja Kandydacka jest kolejnym krokiem po obecnym roboczym projekcie, a CR nie może być wdrożona, dopóki Grupa Robocza nie rozwiąże otwartych problemów wskazanych w projekcie i nie wykaże, że proponowane wyniki są weryfikowalne (proces, który W3C nazywa przeglądem „funkcji zagrożonych“ i który wymaga znacznego doświadczenia implementacyjnego). Kilka publicznych oświadczeń pracowników W3C w 2025 roku wskazywało, że CR dla WCAG 3 jest wciąż odległa i że projekt należy traktować jako dzielony od stabilnej specyfikacji latami, a nie miesiącami.

Po wejściu w etap CR standardowy harmonogram przewiduje co najmniej jeden okres implementacyjny trwający kilka miesięcy, podczas którego grupa robocza zbiera dowody, że wyniki zostały zweryfikowane na rzeczywistych produktach. Następuje PR. Następnie REC. Po REC zaczyna się powolny proces przyjmowania przez regulatorów — historycznie mierzony w latach, a nie miesiącach. Cytowanie WCAG 3 w stylu EAA poprzez zmienioną EN 301 549 (w wersji 5 lub późniejszej) jest, przy realistycznej ocenie, perspektywą końca lat dwudziestych, a nie perspektywą natychmiastową.

Napięcie z WCAG 2.2

WCAG 3 pozostaje w realnym napięciu politycznym z WCAG 2.2, które stanowi podtekst każdej branżowej dyskusji o WCAG 3. WCAG 2.2 osiągnął status Rekomendacji w październiku 2023 roku — opublikowany, stabilny, cytowalny standard, który krajowi regulatorzy wciąż wdrażają. Część z nich już to zrobiła. Część jeszcze nie. Nadchodząca wersja 4 EN 301 549 włączy WCAG 2.2; amerykańska Sekcja 508 jest w trakcie aktualizacji odwołującej się do WCAG 2.x; obrona w prywatnych sporach sądowych w Stanach Zjednoczonych domyślnie cytuje WCAG 2.x.

Napięcie nie dotyczy w zasadzie tego, który dokument jest „lepszy“. Chodzi o to, czy regulatorzy mogą przyjąć standard, który wciąż się zmienia — i czy zespoły, które właśnie zainwestowały w zgodność z WCAG 2.2, powinny uwierzyć, że inny framework jest tuż za rogiem. Oficjalne stanowisko Grupy Roboczej brzmi, że obie linie nie wykluczają się wzajemnie: WCAG 2.2 pozostaje obowiązującym standardem dla regulatorów, a WCAG 3 to kolejna generacja, która z czasem go zastąpi. Oba dokumenty będą utrzymywane po stronie W3C równolegle, gdy WCAG 3 osiągnie status Rekomendacji, a W3C zaznaczył, że okres przejściowy będzie celowo wystarczająco długi, by zespoły nie stanęły przed przymusową migracją.

W praktyce oznacza to trzy rzeczy. Prace audytowe WCAG 2.2 nie są zmarnowane — leżące u ich podstaw bariery dostępności nie znikają pod WCAG 3, są jedynie reorganizowane w wyniki. Regulatorzy będący w trakcie wdrażania WCAG 2.2 nie popełniają błędu — wykonują pracę potrzebną w tej dekadzie. A dostawcy sprzedający „zgodność z WCAG 3“ w oparciu o roboczy projekt wprowadzają w błąd co do dojrzałości standardu; żadna deklaracja zgodności z niestabilnym roboczym projektem nie ma znaczenia.

WCAG 2.2 a WCAG 3: porównanie wymiarów

Implikacje dla serwisów pracujących na wersji 2.x

Praktyczne pytanie dla każdego zespołu prowadzącego serwis, aplikację lub produkt oparty na WCAG 2.x brzmi: czy powinniśmy cokolwiek robić inaczej, bo WCAG 3 nadchodzi? Odpowiedź składa się z trzech elementów.

Przeprowadzaj audyt i remediację zgodnie z WCAG 2.2 AA. To standard, który wdrażają regulatorzy, który zostanie włączony do EN 301 549 V4 i który cytują sądy w jurysdykcjach z prywatnymi prawami do działania. Dobrze przeprowadzony audyt 2.2 AA w 2026 roku nie jest pracą wyrzuconą w błoto — leżące u podstaw bariery będą nadal barierami pod WCAG 3, a nakład pracy na ich usunięcie jest taki sam. Zespoły, które odkładają prace nad wersją 2.2 w nadziei na „zrobienie od razu WCAG 3“, wybierają gorszy wynik na dłuższej osi czasu.

Zapoznaj się z roboczym projektem WCAG 3, nie refaktoryzuj pod niego kodu. Projekt to użyteczne okno na kierunek, w którym zmierza standard, i na potrzeby użytkowników, które w kolejnej dekadzie staną na pierwszym planie. Zespoły powinny go przeczytać (jest bezpłatnie dostępny na stronie W3C TR), udostępnić wewnętrznie w działach projektowania i inżynierii, oraz użyć go do zainicjowania rozmów o dostępności poznawczej, interfejsach głosowych i AAC. Nie powinny jednak zaczynać pisać deklaracji zgodności z nim, formułować klauzul zamówień publicznych ani restrukturyzować programów audytowych w jego antycypacji. Projekt nie jest wystarczająco stabilny dla żadnej z tych aktywności.

Inwestuj w zdolności badań użytkowników i projektowych, których WCAG 3 będzie wymagał. Wyniki WCAG 3 — punktowane, holistyczne, modalnie agnostyczne — nie mogą być weryfikowane wyłącznie przez automatyczne narzędzia skanujące. Potrzebują badań projektowych z użytkownikami z niepełnosprawnościami poznawczymi, użytkownikami AAC, użytkownikami interfejsów głosowych. Zespoły, które będą gotowe, gdy WCAG 3 osiągnie status Rekomendacji, to nie te z najbardziej zaawansowanym automatycznym oprzyrządowaniem — to te z ugruntowanymi relacjami badań użytkowników obejmującymi pełen zakres potrzeb funkcjonalnych. Budowanie tych relacji teraz to inwestycja opłacalna pod każdym ze standardów.

WCAG 3 w grafie standardów, który już znasz

Jeśli śledzisz łuk standardów dostępności — od Sekcji 508 przez EN 301 549, od WCAG 2.0 W3C przez 2.1 do 2.2 — WCAG 3 to kolejna generacja tego łuku, będąca aktualnie w trakcie projektowania. To dokument, który społeczność standardów buduje, ponieważ ograniczenia binarnego, wyłącznie webowego modelu kryteriów sukcesu WCAG 2.x stały się trudne do zignorowania w miarę jak cyfrowa dostępność rozszerzyła się na interfejsy mobilne, głosowe, AAC i poznawcze. To również niestabilny roboczy projekt, którego żaden regulator nie może jeszcze cytować i na który żaden odpowiedzialny dostawca nie może jeszcze powoływać się w deklaracji zgodności.

Dla praktyków planujących pozostałą część tej dekady: WCAG 2.2 to standard, względem którego należy przeprowadzać audyty, EN 301 549 V4 to instrument zamówień publicznych, z którym należy się dostosować, a WCAG 3 to dokument do czytania w piątkowe popołudnie, by rozumieć, dokąd zmierza praca. Właściwa postawa to świadoma cierpliwość — trzymaj WCAG 3 w polu widzenia, wykonuj pracę nad WCAG 2.2 przed sobą i buduj zdolność badań użytkowników, która będzie miała znaczenie niezależnie od tego, który dokument będą cytować audytorzy za pięć lat. Kolejny odcinek tej serii primerów znajdziesz w ankiecie dotyczącej tempa wdrażania WCAG 2.2, śledzącej, którzy krajowi regulatorzy już przekroczyli tę granicę.