WCAG 1.3.1 Informacje i relacje

Kryterium sukcesu 1.3.1 zapewnia, że struktura widoczna dla oka — nagłówki, listy, tabele, etykiety pól formularzy, grupy opcji — jest także zapisana w kodzie. Czytniki ekranu, sterowanie głosem i tryby czytania wykorzystują tę strukturę, aby odczytywać stronę i poruszać się po niej. To poziom A i część normy EN 301 549 (punkt 9.1.3.1).

Czego wymaga kryterium

Informacje, struktura i relacje przekazywane przez prezentację muszą być możliwe do programowego określenia lub dostępne w formie tekstu. W HTML oznacza to, że:

• nagłówki używają h1–h6, a nie tylko dużego pogrubionego tekstu;
• listy używają ul, ol lub dl, z elementami listy bezpośrednio w środku;
• tabele z danymi używają th dla nagłówków (oraz scope lub headers w złożonych tabelach) i podpisu, jeśli tabela ma tytuł;
• pola formularzy mają etykiety połączone w kodzie (label for), a powiązane pola, np. przyciski opcji, są zgrupowane (fieldset i legend);
• informacje przekazywane formatowaniem — pole wymagane oznaczone czerwoną gwiazdką, wyróżniony bieżący krok — są dostępne również w tekście lub w kodzie.

Typowe błędy w sklepie internetowym

• tytuły sekcji, np. „Bestsellery” lub „Opis”, wystylizowane jak nagłówki, ale zakodowane jako div lub pogrubiony p;
• tabele rozmiarów i specyfikacji zbudowane z elementów div albo bez komórek nagłówkowych;
• pola w procesie zamówienia, których widoczna etykieta nie jest połączona z polem w kodzie;
• opcje płatności i dostawy jako przyciski opcji bez etykiety grupy;
• „wymagane” sygnalizowane tylko czerwoną gwiazdką, której nie ma w etykiecie;
• role ARIA, np. list lub menu, użyte bez wymaganych ról podrzędnych.

Jak to sprawdzić

Automatycznie: nasz skaner wychwytuje wiele błędów strukturalnych: listy i listy definicji z niewłaściwymi elementami podrzędnymi, komórki danych bez nagłówków, pogrubione akapity używane jako nagłówki, udawane podpisy tabel, role ARIA bez wymaganych elementów nadrzędnych lub podrzędnych oraz aria-hidden na elemencie body (reguły list, listitem, td has header, p as heading i pokrewne). Nie widzi jednak, czy coś tylko wygląda jak nagłówek lub grupa, więc czysty wynik skanu nie jest dowodem.

Ręcznie: należy użyć konspektu nagłówków (rozszerzenie przeglądarki lub lista nagłówków w czytniku ekranu) i porównać go z tym, co widać na ekranie. Sprawdzić każdą tabelę, formularz i listę w kodzie lub czytnikiem ekranu. Upewnić się, że każda wskazówka wizualna, np. „wymagane”, jest również w tekście.

Jak to naprawić

• Używać prawdziwych elementów nagłówków w motywie i edytorze; zachować logiczną kolejność (jeden h1, potem sekcje h2).
• Budować tabele specyfikacji z użyciem table, th i caption.
• Nadać każdemu polu widoczną etykietę label; grupować zestawy przycisków opcji i pól wyboru za pomocą fieldset i legend.
• Wpisać „wymagane” w tekst etykiety albo dodać aria-required i wyjaśnić znaczenie gwiazdki.
• Przedkładać natywne elementy HTML nad role ARIA.

Powiązane kryteria

• 1.3.2 Zrozumiała kolejność — kolejność czytania w kodzie.
• 1.3.5 Określenie pożądanej wartości — autouzupełnianie pól z danymi osobowymi.
• Reguły sprawdzane przez nasz skaner — wszystkie reguły automatyczne i ich kryteria.

Najczęstsze pytania

Czy WCAG 1.3.1 wymaga poprawnej kolejności nagłówków?

Kryterium 1.3.1 wymaga, aby tekst, który wygląda jak nagłówek, był oznaczony jako nagłówek. Pominięcie poziomów (z h2 do h4) samo w sobie nie jest naruszeniem 1.3.1, ale logiczna kolejność znacznie ułatwia nawigację po stronie i jest dobrą praktyką.

Jak przetestować WCAG 1.3.1?

Uruchomić automatyczne sprawdzenie błędów w strukturze list, tabel i ARIA, a potem porównać wygląd strony z jej kodem lub z tym, co odczytuje czytnik ekranu: każdy nagłówek, lista, nagłówek tabeli, etykieta pola i grupa powinny być w kodzie.

Czy tekst zastępczy (placeholder) wystarczy jako etykieta pola?

Nie jest niezawodną etykietą: znika, gdy użytkownik zaczyna pisać, i nie zawsze jest odczytywany. Należy użyć widocznego elementu label połączonego z polem w kodzie; kryterium 3.3.2 Etykiety lub instrukcje również wymaga widocznych etykiet.

Czy tabele układu strony są błędem?

Używanie tabel do układu strony jest odradzane, ale samo w sobie nie jest błędem, jeśli nie zawierają komórek nagłówkowych, podpisów ani streszczeń. Tabele z danymi natomiast potrzebują prawdziwych komórek nagłówkowych.