Blog

WCAG 2.2 wprowadza kilka nowych kryteriów sukcesu, ale jednocześnie usuwa jedno z dotychczasowych kryteriów znanych z WCAG 2.0 i WCAG 2.1. Chodzi o kryterium 4.1.1 Parsowanie, które w WCAG 2.2 zostało oznaczone jako przestarzałe i usunięte.

To ważna zmiana, ponieważ przez lata błędy walidacji kodu HTML, zduplikowane identyfikatory id, nieprawidłowe zagnieżdżenia elementów czy brakujące znaczniki były często raportowane właśnie jako naruszenie kryterium 4.1.1. W WCAG 2.2 takie podejście wymaga aktualizacji.

Nie oznacza to jednak, że jakość kodu przestaje mieć znaczenie. Oznacza to, że sam błąd parsowania nie powinien być już traktowany jako automatyczny błąd dostępności cyfrowej, jeżeli nie powoduje realnego problemu dla użytkownika lub technologii wspomagającej.

Czym było kryterium 4.1.1 Parsowanie?

Kryterium 4.1.1 Parsowanie należało do zasady „solidność”, czyli czwartej zasady WCAG. Jego celem było zapewnienie, że treści zapisane w językach znaczników, takich jak HTML, są poprawnie zbudowane i mogą być jednoznacznie interpretowane przez przeglądarki oraz technologie wspomagające.

W praktyce kryterium to dotyczyło między innymi takich problemów jak:

• nieprawidłowo zamknięte znaczniki HTML,

• błędne zagnieżdżenie elementów,

• powtarzające się atrybuty,

• zduplikowane wartości atrybutu id,

• kod, którego przeglądarka lub technologia wspomagająca mogła nie zinterpretować w przewidywalny sposób.

W starszym podejściu audytowym często wystarczyło wykrycie błędu walidacji HTML, aby oznaczyć problem jako niezgodność z 4.1.1 Parsowanie. WCAG 2.2 zmienia ten sposób myślenia.

Dlaczego WCAG 2.2 usuwa kryterium 4.1.1 Parsowanie?

Kryterium 4.1.1 powstało w czasach, gdy technologie wspomagające, takie jak czytniki ekranu, w większym stopniu musiały samodzielnie interpretować strukturę kodu HTML (pochodzi z WCAG 2,9 z 2008 roku). Jeżeli kod był błędny, istniało większe ryzyko, że technologia wspomagająca nieprawidłowo odczyta stronę albo w ogóle nie będzie w stanie poprawnie dotrzeć do jej elementów.

Obecnie sytuacja wygląda inaczej. Nowoczesne przeglądarki mają bardzo precyzyjnie określone zasady obsługi błędów w HTML. Nawet jeżeli autor strony popełni błąd składniowy, przeglądarka zwykle potrafi go naprawić lub zinterpretować w sposób przewidywalny. Technologie wspomagające nie analizują już bezpośrednio surowego kodu HTML tak jak kiedyś. Korzystają przede wszystkim z informacji udostępnianych przez przeglądarkę, drzewo DOM oraz drzewo dostępności.

Dlatego W3C uznało, że samo kryterium 4.1.1 nie daje już realnej, samodzielnej wartości dla użytkowników z niepełnosprawnościami. Problemy, które kiedyś były raportowane jako błędy parsowania, dzisiaj powinny być oceniane przez pryzmat ich rzeczywistego wpływu na dostępność.

Innymi słowy: jeżeli błąd w kodzie nie powoduje problemu z nazwą elementu, rolą, relacją, obsługą klawiaturą, kolejnością fokusu czy odczytem przez czytnik ekranu, nie powinien być automatycznie traktowany jako błąd WCAG tylko dlatego, że walidator HTML go wykrył.

Czy to oznacza, że błędy HTML nie mają już znaczenia?

Nie. To byłby bardzo niebezpieczny wniosek. Usunięcie 4.1.1 Parsowanie nie oznacza, że można ignorować jakość kodu. Poprawny, semantyczny i uporządkowany kod HTML nadal jest podstawą dostępnej strony internetowej. Zmienia się tylko sposób klasyfikowania błędów w audycie WCAG.

Przykład: zduplikowany identyfikator id nie powinien być już automatycznie raportowany jako naruszenie 4.1.1. Jeżeli jednak przez ten zduplikowany identyfikator etykieta formularza zostanie powiązana z niewłaściwym polem, problem nadal istnieje. Tylko że należy go przypisać do innego kryterium, na przykład 1.3.1 Informacje i relacje albo 4.1.2 Nazwa, rola, wartość.

Podobnie, jeżeli nieprawidłowe zagnieżdżenie elementów powoduje błędną strukturę nagłówków, nieczytelną tabelę, nieprawidłowe działanie menu lub utratę dostępnej nazwy przycisku, nadal mamy problem dostępności. Nie jest to jednak problem „parsowania” jako takiego, tylko problem konkretnej funkcji strony.

Co zamiast 4.1.1 Parsowanie?

Po usunięciu kryterium 4.1.1 audytorzy, wykonawcy stron i właściciele serwisów powinni skupić się na skutkach błędów, a nie na samym fakcie ich technicznego wystąpienia. Najczęściej problemy wcześniej przypisywane do 4.1.1 należy dziś analizować w kontekście innych kryteriów WCAG, między innymi:

1.3.1 Informacje i relacje

To kryterium będzie właściwe, jeżeli błąd w kodzie powoduje utratę struktury lub relacji między elementami.

Przykłady:

• etykieta formularza nie jest poprawnie powiązana z polem,

• tabela nie ma prawidłowych nagłówków,

• lista nie jest oznaczona jako lista,

• nagłówki nie tworzą logicznej struktury,

• treść wizualnie wygląda jak grupa informacji, ale w kodzie nie ma tej relacji.

W takim przypadku problemem nie jest samo „niepoprawne parsowanie”, lecz to, że użytkownik technologii wspomagającej nie otrzymuje tej samej informacji, którą widzi użytkownik wzrokowy.

4.1.2 Nazwa, rola, wartość

To jedno z najważniejszych kryteriów przy ocenie komponentów interaktywnych. Będzie miało zastosowanie, gdy przez błędny kod element nie ma poprawnej nazwy, roli lub stanu. Przykłady:

• przycisk nie ma dostępnej nazwy,

• ikona działa jak przycisk, ale nie ma roli przycisku,

• rozwijane menu nie przekazuje informacji, czy jest otwarte czy zamknięte,

• pole formularza nie ma etykiety,

• komponent JavaScript nie udostępnia technologii wspomagającej swojej funkcji.

W praktyce wiele błędów, które dawniej były wrzucane do 4.1.1, powinno być obecnie ocenianych właśnie przez 4.1.2.

2.4.3 Kolejność fokusu

Jeżeli błąd w strukturze kodu powoduje nielogiczną kolejność przechodzenia po stronie klawiaturą, problem należy analizować przez kryterium 2.4.3. Przykłady:

• fokus przeskakuje w nieoczekiwane miejsce,

• elementy modalnego okna nie są obsługiwane w logicznej kolejności,

• użytkownik klawiatury trafia najpierw do elementów ukrytych wizualnie,

• kolejność DOM nie odpowiada logicznej kolejności treści.

Tutaj również nie chodzi o samą poprawność kodu, ale o praktyczny wpływ na użytkownika.

2.4.7 Widoczny fokus

Błąd w kodzie lub CSS może powodować, że użytkownik nie widzi, gdzie aktualnie znajduje się fokus klawiatury. Taki problem nie powinien być opisywany jako parsowanie, lecz jako naruszenie kryterium dotyczącego widoczności fokusu. To bardzo częsty błąd na stronach internetowych, szczególnie tam, gdzie style CSS usuwają domyślny obrys fokusu, na przykład przez outline: none.

3.3.2 Etykiety lub instrukcje

Jeżeli błędna struktura formularza powoduje, że użytkownik nie wie, co ma wpisać w dane pole, problem może dotyczyć kryterium 3.3.2. Sam błąd HTML jest mniej istotny niż to, czy użytkownik otrzymuje zrozumiałą etykietę i instrukcję.

4.1.3 Komunikaty o stanie

W przypadku dynamicznych komunikatów, na przykład informacji o błędzie, dodaniu produktu do koszyka, zapisaniu formularza albo zmianie wyników wyszukiwania, problem należy analizować pod kątem kryterium 4.1.3. Jeżeli komunikat pojawia się wizualnie, ale nie jest ogłaszany przez czytnik ekranu, problem nadal jest poważny. Nie wynika jednak z samego parsowania, tylko z braku prawidłowego przekazania komunikatu o stanie.

Co powinien zrobić właściciel strony internetowej?

Właściciel strony nie musi usuwać z raportów historycznych wszystkich dawnych odniesień do 4.1.1, ale powinien wiedzieć, że w audytach zgodnych z WCAG 2.2 kryterium 4.1.1 nie powinno być już traktowane jako aktywne kryterium oceny.

W praktyce warto wykonać kilka działań. Po pierwsze, należy zaktualizować listy kontrolne używane do audytów dostępności cyfrowej. Jeżeli w firmie, urzędzie lub instytucji nadal funkcjonuje checklista WCAG 2.1, trzeba oznaczyć 4.1.1 jako kryterium przestarzałe albo usunięte w WCAG 2.2. Po drugie, warto zmienić sposób raportowania błędów. Zamiast pisać „strona posiada zduplikowane identyfikatory ID – naruszenie 4.1.1”, należy sprawdzić, czy ten problem powoduje konkretny błąd dostępności. Jeżeli tak, trzeba przypisać go do właściwego kryterium, na przykład 1.3.1 lub 4.1.2. Po trzecie, nie należy rezygnować z walidacji kodu. Walidator HTML nadal jest użytecznym narzędziem technicznym. Pomaga wykrywać błędy, które mogą powodować problemy z dostępnością, stabilnością strony, obsługą JavaScript, SEO lub poprawnym działaniem komponentów. Różnica polega na tym, że wynik walidatora nie jest już sam w sobie wystarczającą podstawą do wykazania niezgodności z WCAG 2.2.

Czy strona z błędami walidacji HTML może być zgodna z WCAG 2.2?

Tak, może. Sama obecność błędów walidacji HTML nie oznacza automatycznie, że strona jest niezgodna z WCAG 2.2.

Ale trzeba zachować ostrożność. Błąd walidacji może nie być błędem WCAG, ale może prowadzić do błędu WCAG. Dlatego każdy przypadek trzeba ocenić indywidualnie.

Przykład: Jeżeli na stronie występuje zduplikowany identyfikator id, ale nie wpływa on na etykiety formularzy, relacje ARIA, działanie skryptów, fokus ani odczyt przez czytnik ekranu, nie powinien być raportowany jako naruszenie WCAG 2.2. Jeżeli jednak ten sam zduplikowany id powoduje, że czytnik ekranu odczytuje błędną etykietę pola formularza, problem jest realny i należy go raportować. Tylko nie jako 4.1.1, lecz jako naruszenie kryterium, którego dotyczy rzeczywisty skutek.

Czy warto dalej pisać poprawny kod HTML?

Zdecydowanie tak. Poprawny kod HTML nadal ma ogromne znaczenie. Wpływa na stabilność strony, dostępność, SEO, wydajność, utrzymanie serwisu i kompatybilność z różnymi urządzeniami. Usunięcie kryterium 4.1.1 nie jest zgodą na chaotyczny kod.

Dobrze napisany kod:

• ułatwia działanie czytników ekranu,

• poprawia obsługę strony klawiaturą,

• zmniejsza ryzyko błędów w formularzach,

• ułatwia rozwój strony,

• zmniejsza liczbę problemów po aktualizacjach CMS, szablonów i wtyczek,

• poprawia przewidywalność działania komponentów JavaScript,

• pomaga utrzymać stronę w dobrej kondycji technicznej.

Różnica polega na tym, że w WCAG 2.2 jakość kodu oceniamy przez skutki dla dostępności, a nie przez samo formalne naruszenie dawnego kryterium 4.1.1.

Co z WCAG 2.0 i WCAG 2.1?

To szczególnie ważne w kontekście przepisów, umów, zapytań ofertowych i audytów, które nadal odwołują się do WCAG 2.1.

W praktyce W3C wskazało, że kryterium 4.1.1 powinno być uznawane za spełnione dla treści tworzonych w HTML lub XML. Oznacza to, że nawet przy pracy z WCAG 2.0 lub WCAG 2.1 nie powinno się już mechanicznie oblewać strony wyłącznie za błędy parsowania, jeżeli nie powodują one realnych problemów dostępności. To bardzo ważna zmiana dla instytucji publicznych, wykonawców i audytorów, ponieważ wiele starszych raportów opierało się na automatycznych wynikach walidatorów. Obecnie takie podejście może prowadzić do nieprecyzyjnych lub przestarzałych wniosków.

Najważniejszy wniosek

WCAG 2.2 usuwa tylko jedno wcześniejsze kryterium sukcesu: 4.1.1 Parsowanie.

Nie oznacza to jednak, że poprawność kodu przestaje być ważna. Oznacza to, że sama niepoprawność składniowa kodu HTML nie jest już automatycznie uznawana za błąd dostępności cyfrowej. Liczy się realny wpływ na użytkownika. Dla właścicieli stron, urzędów, instytucji i wykonawców oznacza to konieczność aktualizacji podejścia do audytów WCAG. Raporty powinny wskazywać nie tylko błędy techniczne, ale przede wszystkim ich konsekwencje: czy użytkownik może obsłużyć stronę klawiaturą, czy czytnik ekranu odczytuje elementy poprawnie, czy formularze mają etykiety, czy komponenty mają właściwą nazwę, rolę i stan. To dobra zmiana. WCAG 2.2 przesuwa akcent z formalnej poprawności kodu na rzeczywistą dostępność cyfrową. A właśnie o to chodzi w profesjonalnym podejściu do dostępności: nie o odhaczanie walidatora, ale o zapewnienie, że strona działa dla wszystkich użytkowników.