W skrócie7 min czytania

Najważniejsze wnioski

  • WCAG opisuje testowalne kryteria dostępności treści internetowych.
  • WCAG 2.2 rozwija WCAG 2.1 i dodaje kolejne kryteria.
  • EN 301 549 obejmuje szerszy zakres ICT i odwołuje się do wymagań webowych.
  • Zakres prawny trzeba ustalać na podstawie ustawy i aktualnych norm, nie skrótu marketingowego.

„Musimy mieć WCAG 2.1 AA” — to zdanie pada na większości spotkań o dostępności i zwykle jest półprawdą. WCAG to wytyczne organizacji standaryzacyjnej, a nie akt prawny. Obowiązek wynika z ustawy, ustawa odsyła do normy, a norma dopiero powołuje się na WCAG. Warto rozumieć tę drabinę, bo od niej zależy, jaką wersję dokumentu faktycznie trzeba wziąć pod uwagę.

WCAG 2.1: podstawa odniesienia

WCAG 2.1 zostało opublikowane przez W3C w czerwcu 2018 r. jako rozszerzenie WCAG 2.0. Dodano wtedy 17 nowych kryteriów sukcesu, w dużej części dotyczących korzystania ze stron na urządzeniach mobilnych, osób słabowidzących oraz osób z trudnościami poznawczymi. Struktura pozostała ta sama: cztery zasady (postrzegalność, funkcjonalność, zrozumiałość, solidność), wytyczne i przypisane do nich testowalne kryteria na poziomach A, AA i AAA.

WCAG 2.2: dziewięć nowych kryteriów i jedno usunięte

WCAG 2.2 uzyskało status rekomendacji W3C w październiku 2023 r. Zmiana jest przyrostowa: dokument dodaje 9 nowych kryteriów sukcesu, z których 6 znajduje się na poziomie A lub AA. Łącznie WCAG 2.2 zawiera 86 kryteriów, z czego 55 na poziomach A i AA — czyli w zakresie typowym dla wymagań regulacyjnych.

Jednocześnie z WCAG 2.2 usunięto kryterium 4.1.1 Parsowanie. W3C uzasadniło to tym, że technologie asystujące nie parsują już bezpośrednio kodu HTML, więc kryterium przestało mieć praktyczną użyteczność. To rzadki przypadek, gdy nowa wersja standardu zmniejsza liczbę wymagań.

Nowe kryteria dotyczą przede wszystkim widoczności fokusu, obsługi gestów, rozmiaru celów dotykowych, spójnej pomocy, powtarzalnego wprowadzania danych i uwierzytelniania niewymagającego testów pamięciowych. Praktycznie oznacza to, że projektant interfejsu ma kilka nowych, konkretnych rzeczy do sprawdzenia.

DokumentStatusZakresKto go wydaje
WCAG 2.1Rekomendacja W3C z 2018 r.Treści internetoweW3C
WCAG 2.2Rekomendacja W3C z 2023 r.Treści internetoweW3C
EN 301 549Norma zharmonizowana, V3.2.1 z 2021 r.Produkty i usługi ICTETSI, CEN, CENELEC
Dyrektywa 2019/882Akt prawa UEWskazane produkty i usługiParlament Europejski i Rada
Ustawa krajowaAkt prawa polskiegoWskazane produkty i usługiSejm

EN 301 549: norma, a nie wytyczne

EN 301 549 to europejska norma zharmonizowana dotycząca wymagań dostępności produktów i usług ICT. Obowiązująca wersja V3.2.1 pochodzi z marca 2021 r. Jej zakres jest znacznie szerszy niż WCAG: obejmuje między innymi sprzęt, oprogramowanie, dokumentację, wsparcie użytkownika i usługi komunikacji w czasie rzeczywistym.

Dla stron internetowych kluczowy jest rozdział 9. Odwołuje się on do WCAG 2.1 na poziomie A i AA — zgodność z WCAG 2.1 AA odpowiada spełnieniu wymagań klauzul 9.1–9.4 oraz warunków zgodności z klauzuli 9.6. Stąd bierze się popularny skrót „WCAG 2.1 AA”. Skrót jest wygodny, ale gubi resztę normy, która dla sklepu z aplikacją mobilną albo z infolinią bywa równie istotna.

Uwaga: wersje norm się zmieniają. Przy sporządzaniu dokumentacji sprawdź, jaka wersja EN 301 549 jest aktualnie przywołana w odniesieniu do Twojego obowiązku, zamiast opierać się na zapamiętanym numerze.

WCAG mówi, jak zbudować dostępną stronę. Norma mówi, czego wymaga się od usługi. Ustawa mówi, kto musi to zrobić. Trzy różne pytania, trzy różne dokumenty.

Którą wersję wybrać w praktyce

Dla dokumentacji zgodności punktem odniesienia jest wersja przywołana w obowiązujących Cię przepisach i normie — dziś dla treści webowych zwykle WCAG 2.1 AA. Dla projektowania nowych interfejsów rozsądniejsze jest jednak celowanie od razu w WCAG 2.2. Powód jest prosty: nowe kryteria dotyczą rzeczy, które i tak trzeba zaprojektować — rozmiaru przycisków, widoczności fokusu, logowania bez zagadek pamięciowych. Dorabianie ich później kosztuje więcej niż uwzględnienie od początku.

Scenariusz: audyt pod dwie wersje naraz

Rozważmy scenariusz zespołu, który przebudowuje koszyk. Wymagania formalne wskazują WCAG 2.1 AA, ale projektant sprawdza równolegle nowe kryteria z WCAG 2.2. Wychodzi, że przyciski zmiany ilości mają cel dotykowy mniejszy niż zalecany, a przy przejściu do płatności użytkownik musi ponownie wpisać dane, które już podał przy rejestracji. Formalnie nic nie jest naruszone, praktycznie oba elementy podnoszą liczbę porzuconych koszyków. Poprawka kosztuje jeden sprint na etapie projektu i kilka razy więcej po wdrożeniu.

zależności dokumentów

Od wytycznych do obowiązku prawnego

1WCAG 2.1 / 2.22EN 301 5493Dyrektywa 2019/8824Ustawa krajowa5Obowiązek firmy
Każde ogniwo ma inny status. Skrót „musimy mieć WCAG 2.1 AA” pomija trzy z nich.

Jak to się łączy z obowiązkiem

Dyrektywa (UE) 2019/882, nazywana Europejskim Aktem o Dostępności, wyznacza wymagania dla wskazanych produktów i usług. Do polskiego porządku prawnego wprowadza ją ustawa z 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze. Co z tego wynika dla sklepu internetowego, rozkładamy na czynniki pierwsze w przewodniku po Polskim Akcie o Dostępności dla e-commerce.

Jeżeli szukasz praktycznego przełożenia kryteriów na własny serwis, zacznij od checklisty dostępności sklepu internetowego. Warto też z góry wiedzieć, czego widget dostępności nie załatwia, zanim wpiszesz go do planu zgodności. Samo uruchomienie funkcji wspierających opisujemy w tekstach o instalacji WCAGbot oraz o dostępnych funkcjach panelu.

Czego WCAG nie obejmuje

Równie ważne jak znajomość zakresu wytycznych jest wiedza o tym, co poza nim zostaje. WCAG to kryteria testowalne, więc świadomie pomija rzeczy trudne do jednoznacznej oceny.

Wytyczne nie oceniają, czy język tekstu jest zrozumiały dla przeciętnego odbiorcy — poza wąskimi kryteriami dotyczącymi na przykład definicji nietypowych słów. Nie rozstrzygają, czy proces zakupowy ma sensowną liczbę kroków. Nie mówią, czy formularz zbiera dane, których naprawdę potrzebujesz. Spełnienie wszystkich kryteriów na poziomie AA jest więc możliwe w serwisie, który wciąż jest uciążliwy w obsłudze.

Dlatego testy z udziałem użytkowników, w tym osób korzystających z technologii asystujących, są uzupełnieniem, którego nie zastąpi żadna lista kontrolna. Kryteria pilnują podłogi, a nie sufitu.

Jak śledzić zmiany w dokumentach

Wersje wytycznych i norm żyją własnym rytmem, a błędne przywołanie wersji w dokumentacji potrafi podważyć cały opis zgodności. Trzy nawyki wystarczą, żeby nie zostać w tyle.

Po pierwsze, w dokumentacji zawsze zapisuj pełne oznaczenie: nazwę dokumentu, numer wersji, poziom i datę badania. „Zgodne z WCAG” bez tych danych nie niesie informacji. Po drugie, przy każdym większym projekcie sprawdź aktualne brzmienie normy przywołanej w Twoim obowiązku, zamiast opierać się na numerze zapamiętanym z poprzedniego wdrożenia. Po trzecie, projektuj z zapasem — celowanie w nowszą wersję wytycznych przy nowych interfejsach kosztuje niewiele, a chroni przed przepisywaniem komponentów po zmianie odniesienia.

Przełożenie tej wiedzy na konkretny serwis zaczyna się od stanu faktycznego, czyli od przeglądu ścieżki zakupowej i uczciwej oceny, które bariery da się złagodzić warstwą prezentacji, a które wymagają pracy w kodzie.

Najczęstsze pytania

Czy WCAG jest prawem?

Nie. WCAG to wytyczne W3C. Moc prawną nadaje im dopiero odesłanie w normie i w przepisach krajowych lub unijnych.

Ile kryteriów ma WCAG 2.2?

86 kryteriów sukcesu, z czego 55 na poziomie A i AA. To efekt dodania 9 nowych kryteriów i usunięcia kryterium 4.1.1 Parsowanie.

Czy zgodność z WCAG 2.1 AA oznacza zgodność z WCAG 2.2 AA?

Nie automatycznie. Serwis zgodny z 2.1 AA nadal musi spełnić nowe kryteria z 2.2 na poziomie A i AA, żeby można było mówić o zgodności z nowszą wersją.

Dlaczego usunięto kryterium 4.1.1 Parsowanie?

Ponieważ technologie asystujące nie parsują już bezpośrednio kodu HTML, a problemy, którym kryterium miało zapobiegać, są dziś wychwytywane przez inne wymagania. W3C uznało je za nieaktualne.

Czy EN 301 549 dotyczy tylko sektora publicznego?

Nie. Norma jest technicznym punktem odniesienia także dla wymagań adresowanych do podmiotów gospodarczych, wynikających z Europejskiego Aktu o Dostępności i przepisów krajowych.

Poziom AA czy AAA?

W regulacjach punktem odniesienia jest zwykle poziom AA. Poziom AAA nie jest wymagany dla całych serwisów i w wielu przypadkach nie da się go osiągnąć dla wszystkich treści.

Co z aplikacją mobilną sklepu?

Aplikacja mobilna również mieści się w zakresie normy ICT. Kryteria WCAG stosuje się do niej odpowiednio, a EN 301 549 zawiera dodatkowe wymagania dla oprogramowania.

Jak udokumentować zgodność?

Opisem wyników testów dla wskazanych stron i procesów, ze wskazaniem wersji wytycznych, poziomu, daty badania, zastosowanej metody oraz listy stwierdzonych niezgodności i planu ich usunięcia.

Źródła i materiały

  1. www.w3.org
  2. www.etsi.org
  3. www.w3.org
  4. www.w3.org
  5. eur-lex.europa.eu
Graf wiedzy

Powiązane zagadnienia

EN 301 54919 wpisów WCAG 2.11 wpisów WCAG 2.1 a EN 301 5491 wpisów Norma europejska1 wpisów Poziom AA1 wpisów W3C1 wpisów WCAG 2.226 wpisów standardy dostępności1 wpisów