Solidność · Poziom A · usunięte w WCAG 2.2

4.1.1 Parsowanie

Kod powinien być możliwy do jednoznacznego odczytania przez przeglądarkę, ale w WCAG 2.2 to kryterium ma już status historyczny.

Krótko

4.1.1 wymagało, żeby kod w językach znaczników był poprawnie zagnieżdżony, miał kompletne znaczniki, nie miał zdublowanych atrybutów i nie powtarzał tych samych identyfikatorów.

W WCAG 2.2 kryterium zostało oznaczone jako przestarzałe i usunięte. W praktyce nadal warto wykrywać błędy parsowania, ale jako wsparcie diagnozy, a nie jako osobny błąd 4.1.1 w audycie WCAG 2.2.

Problem w praktyce

Stary audyt mógł oznaczyć duplikat id albo źle domknięty znacznik jako błąd 4.1.1. Dzisiaj taki sam problem trzeba ocenić przez realny wpływ: czy psuje relacje formularza, nazwę kontrolki, kolejność, semantykę albo działanie technologii wspomagających.

To nie jest ogólna ocena jakości HTML. Brzydki albo niespójny kod nie jest automatycznie błędem dostępności, jeśli nie powoduje konkretnego problemu dla użytkownika.

Kogo to dotyczy

  • Audytorów, którzy muszą rozróżnić historyczne 4.1.1 od aktualnych wymagań WCAG 2.2.
  • Developerów utrzymujących starsze raporty WCAG 2.0 lub 2.1.
  • Osób korzystających z technologii wspomagających, jeśli błąd kodu psuje semantykę albo nazwę elementu.
  • Zespołów QA, które używają walidatora HTML jako narzędzia pomocniczego.

Dobry przykład

  • Identyfikatory są unikalne, więc etykiety i opisy wskazują właściwe pola.
  • Znaczniki są poprawnie zagnieżdżone, więc drzewo dokumentu jest przewidywalne.
  • Walidator HTML jest używany do wykrywania ryzyk, ale audytor opisuje błąd pod właściwym, aktualnym kryterium.
  • W raporcie WCAG 2.2 przy 4.1.1 pojawia się jasna informacja: „kryterium usunięte w WCAG 2.2”.

Zły przykład

  • Raport WCAG 2.2 nadal wpisuje „błąd 4.1.1” bez wyjaśnienia, że kryterium zostało usunięte.
  • Automat zgłasza każdy błąd walidacji jako błąd dostępności, bez sprawdzenia wpływu na użytkownika.
  • Na stronie powtarza się ten sam id, przez co opis pola trafia do niewłaściwej kontrolki.
  • Kod ma źle zagnieżdżone elementy interaktywne, co psuje nazwę albo rolę komponentu.

Przykłady kodu

Dobry przykład: unikalne identyfikatory

Etykieta i podpowiedź odnoszą się do jednego konkretnego pola.

Kod — HTML

<label for="email">E-mail</label>
<input id="email" name="email" type="email" aria-describedby="email-help">
<p id="email-help">Podaj adres, na który wyślemy potwierdzenie.</p>

Zły przykład: powtórzony identyfikator

Ten sam id może popsuć powiązania między etykietą, opisem i polem.

Kod — HTML

<label for="number">Numer klienta</label>
<input id="number" name="client-number">

<label for="number">Numer faktury</label>
<input id="number" name="invoice-number">

Zły przykład: niepoprawne zagnieżdżenie kontrolek

Elementy interaktywne nie powinny być wkładane jeden w drugi.

Kod — HTML

<button type="button">
  Pobierz raport
  <a href="/raport.pdf">PDF</a>
</button>

Przykład graficzny

Źle

id="number" użyte dwa razy

Walidator pomaga wykryć ryzyko, ale audytor sprawdza wpływ na dostępność.

Dobrze

id="client-number" i id="invoice-number"

Powiązania w kodzie są jednoznaczne.

Schemat pokazuje, że błędy parsowania są dziś sygnałem do dalszej diagnozy, a nie automatycznie osobnym błędem 4.1.1 w WCAG 2.2.

Jak sprawdzić

  1. Sprawdź, według której wersji standardu prowadzony jest audyt: WCAG 2.1, WCAG 2.2 albo norma odwołująca się do konkretnej wersji WCAG.
  2. Jeśli audyt dotyczy WCAG 2.2, oznacz 4.1.1 jako kryterium usunięte, a znalezione problemy przypisz do aktualnych kryteriów, jeśli mają wpływ na użytkownika.
  3. Uruchom walidator HTML jako narzędzie pomocnicze.
  4. Zweryfikuj ręcznie problemy, które mogą psuć etykiety, opisy, semantykę, relacje albo obsługę komponentu.
  5. Nie opisuj jako błędu dostępności samego faktu, że kod nie jest estetyczny albo nie przechodzi wszystkich reguł jakościowych.

Co sprawdzi automat, a czego nie

Automat może wykryć

  • powtórzone identyfikatory,
  • zdublowane atrybuty,
  • część błędów zagnieżdżenia,
  • niekompletne albo nieprawidłowo zapisane znaczniki.

Automat nie oceni pewnie

  • czy problem nadal jest błędem w wybranej wersji WCAG,
  • czy błąd kodu ma realny wpływ na technologie wspomagające,
  • pod które aktualne kryterium należy przypisać problem.

Typowe błędy

  • Wpisywanie 4.1.1 jako aktywnego kryterium w raporcie WCAG 2.2.
  • Traktowanie każdego błędu walidatora jako błędu dostępności.
  • Powtórzone id w formularzu, przez które etykieta albo opis trafiają do złego pola.
  • Naprawianie „walidacji HTML” zamiast naprawiania konkretnej dostępnej nazwy, roli, relacji albo wartości.