Wróć do wszystkich kryteriów

1.3.1 Informacje i relacje (ang.) Info and Relationships

Specjalizacje:

  • Content Creator
  • Designer
  • Deweloper

Elementy:

  • Formularze
  • Listy
  • Nagłówki i struktura
  • Tabele

Poziomy:

  • A

Spis treści

    Istota i cel kryterium

    Kryterium jest kluczowe dla dostępności technicznej, koncentrując się na strukturze i semantyce strony, a nie tylko na jej wyglądzie wizualnym.

    Najważniejsze jest zapewnienie, że informacje, struktura i relacje między elementami strony, które są przekazywane wizualnie (np. poprzez układ, rozmiar czcionki, kolor tła), są również programowo określone (semantyczne) i dostępne dla technologii wspomagających.

    Definicja w j. angielskim

    Definicja dostępna pod adresem (link otworzy się w nowej karcie):
    https://www.w3.org/WAI/WCAG22/quickref/#info-and-relationships

    Definicja w j. polskim

    Definicja dostępna pod adresem (link otworzy się w nowej karcie):
    https://www.w3.org/Translations/WCAG21-pl/#informacje-i-relacje

    Wpływ na dostępność (Kogo wspierasz?)

    Poprawna implementacja tego kryterium usuwa bariery dla wielu grup użytkowników:

    • Osoby z alternatywnymi metodami nawigacji: Użytkownicy klawiatur lub przełączników polegają na logicznej strukturze kodu, aby sprawnie poruszać się po serwisie.
    • Osoby korzystające z czytników ekranu: Programowa definicja nagłówków czy list pozwala tym narzędziom na prawidłową interpretację i przekazanie kontekstu treści.
    • Osoby z niepełnosprawnościami poznawczymi: Przejrzysta i uporządkowana struktura ułatwia orientację i zapobiega poczuciu dezorientacji.
    • Osoby z dysleksją: Logiczne zastosowanie nagłówków ułatwia skanowanie wzrokowe tekstu i szybsze przyswajanie informacji.
    • Wszyscy użytkownicy: Ignorowanie relacji semantycznych prowadzi do chaosu informacyjnego, który utrudnia korzystanie ze strony każdemu odbiorcy.

    Zasady wdrażania i wymagania techniczne

    Aby spełnić wymagania tego kryterium, zastosuj poniższe wytyczne techniczne:

    • Relacje programowe: Upewnij się, że struktura strony jest zakodowana w HTML w sposób zrozumiały dla przeglądarek.
    • Formularze: Powiąż każde pole edycyjne z etykietą <label> za pomocą atrybutów id oraz for. Do grupowania logicznych sekcji formularza używaj elementów <fieldset> i <legend>.
    • Tabele danych: Stosuj znaczniki <th> dla nagłówków oraz atrybuty scope, aby jasno określić relacje między danymi a ich opisem. Pamiętaj o dodaniu opisu tabeli w znaczniku <caption>.
    • Struktura list: Wykorzystuj semantyczne znaczniki: <ul> (nieuporządkowane), <ol> (uporządkowane) oraz <dl> (listy definicji).
    • Hierarchia nagłówków: Zachowaj logiczną kolejność znaczników od <h1> do <h6>. Nie wybieraj poziomu nagłówka na podstawie tego, jak duży ma być tekst wizualnie.
    • Atrybuty WAI-ARIA: Jeśli standardowy HTML nie wystarcza do opisania złożonych widżetów, zastosuj role i atrybuty ARIA, takie jak aria-labelledby czy aria-describedby.
    • Punkty orientacyjne (Landmarks): Definiuj główne regiony strony za pomocą tagów HTML5, takich jak <nav>, <main>, <header> czy <footer>.

    Wyjątki i sytuacje szczególne

    Istnieją rzadkie przypadki, w których programowe określenie relacji może być utrudnione:

    • Dostępność w tekście: W sytuacjach, gdy technologia nie pozwala na pełne zakodowanie relacji (np. starsze systemy), dopuszczalne jest jawne opisanie struktury bezpośrednio w treści tekstowej. Jest to jednak metoda ostateczna i mniej efektywna niż poprawne kodowanie semantyczne.

    Praktyczne wytyczne dotyczące zgodności

    Struktura nagłówków

    Struktura list

    Struktura tabel

    Struktura formularzy

    Orientacja i nawigacja (Elementy ARIA i Regiony punktów orientacyjnych)

    Wyróżnienia wizualne

    Najczęstsze błędy

    Unikaj poniższych praktyk, które są typowymi błędami audytowymi:

    • Używanie stylizacji CSS (np. font-weight: bold) do imitowania nagłówków zamiast użycia tagów <h1-h6>.
    • Brak powiązania etykiet tekstowych z polami formularza, co uniemożliwia ich identyfikację przez czytnik ekranu.
    • Stosowanie pustych wierszy lub znaków specjalnych do tworzenia wizualnych list zamiast znaczników <ul> lub <ol>.
    • Pomijanie poziomów nagłówków (np. przejście bezpośrednio z <h1> do <h3>).
    • Przekazywanie kluczowych informacji wyłącznie za pomocą koloru lub rozmiaru czcionki bez bez alternatywnego oznaczenia.

    Najlepsze praktyki

    Wznieś swoje projekty na wyższy poziom dostępności:

    • Zasada (ang.) „HTML First„: Zawsze w pierwszej kolejności korzystaj z natywnych elementów HTML. Sięgaj po ARIA tylko wtedy, gdy standardowe tagi nie oferują wymaganej semantyki.
    • Rozważne stosowanie ARIA: Pamiętaj, że błędne użycie atrybutów ARIA może przynieść więcej szkody niż pożytku.
    • Spójność strukturalna: Dbaj o to, aby struktura i nazewnictwo elementów były jednolite w całym serwisie.
    • Weryfikacja wizualna: Upewnij się, że każda informacja widoczna na ekranie (np. status „wymagane” w formularzu) ma swój odpowiednik dostępny dla technologii wspomagających.

    Metody testowania

    Zweryfikuj poprawność wdrożenia, korzystając z poniższych narzędzi:

    • Narzędzie deweloperskie (ang.) Developer Tools: Zbadaj element w narzędziach przeglądarki, aby zweryfikować rolę (role) i nazwę (name) poszczególnych elementów w drzewie dostępności.
    • (ang.) WAVE Evaluation Tool: Skorzystaj z widoku (ang.) „Structure„, aby ocenić poprawność hierarchii nagłówków oraz sprawdzić powiązania etykiet w formularzach.
    • (ang.) IBM Equal Access Toolkit: Przeprowadź pełny audyt strony, który automatycznie wykryje błędy w strukturze tabel danych oraz nieprawidłowe użycie znaczników HTML.
    • ANDI.js: Użyj narzędzia do analizy tabel i formularzy, aby upewnić się, że relacje (np. nagłówek kolumny – komórka danych) są programowo określone.
    • NVDA: Wykorzystaj klawisze szybkiej nawigacji (np. „H” dla nagłówków, „T” dla tabel, „F” dla pól formularzy), aby sprawdzić, czy struktura strony jest logiczna i czytelna bez patrzenia na ekran.

    Sprawdź swoją wiedzę

    W poniżej podanym linku znajduje się 5 przykładów struktur HTML (nagłówki, listy, formularze, tabele). Twoim zadaniem jest ocenić, czy relacje między informacjami są poprawnie przekazane programowo.

    Notatka: Zanim zajrzysz do rozwiązania, uruchom wybrane narzędzie testowe, zbadaj elementy i zapisz swoje wnioski na kartce.

    Proponowane narzędzia: Narzędzie deweloperskie (ang.) Developer Tools, (ang.) WAVE Evaluation Tool, (ang.) IBM Equal Access Toolkit, ANDI.js, NVDA

    Link: https://pdc.ambiscale.com/training/wcag-1-3-1/

    #1 BŁĄD

    Problem: Nielogiczna struktura nagłówków. Przeskok z <h1> od razu do <h4>.
    Niezgodność: Użytkownik czytnika może pomyśleć, że ominął ważne sekcje (poziomy H2 i H3). Nagłówki powinny tworzyć spójny spis treści.
    Naprawa: Zmienić <h4> na <h2>.

    #2 BŁĄD

    Problem: Pole tekstowe nie ma etykiety programowej. Tekst „Imię:” to zwykły <div>.
    Niezgodność: Dla czytnika ekranu to pole jest „nieopisane” (unlabeled). Użytkownik nie wie, co wpisać.
    Naprawa: Użyć znacznika <label for="..."> połączonego z id pola.

    #3 DOBRZE

    Dlaczego: Tabela jest poprawnie zbudowana. Posiada tytuł (caption), wydzieloną sekcję nagłówkową (thead) oraz komórki nagłówkowe (th) z atrybutem scope. Relacje między danymi są jasne.

    #4 BŁĄD

    Problem: „Fałszywa lista” stworzona z paragrafów i myślników.
    Niezgodność: Czytnik ekranu nie informuje o strukturze listy („Lista z 3 elementami”), a jedynie czyta kolejne zdania. Utrudnia to nawigację.
    Naprawa: Użyć znacznika <ul> i <li>.

    #5 BŁĄD

    Problem: Komunikat o błędzie jest tylko wizualny (czerwony tekst pod polem).
    Niezgodność: Nie ma programowego powiązania między polem a błędem. Użytkownik czytnika może nie usłyszeć komunikatu lub nie wiedzieć, którego pola dotyczy.
    Naprawa: Połączyć komunikat z polem za pomocą aria-describedby="id-bledu" i ewentualnie oznaczyć pole jako aria-invalid="true".

    Źródła

    Dodatkowe linki

    Wróć do wszystkich kryteriów