Wróć do wszystkich kryteriów

3.3.2 Etykiety lub instrukcje (ang.) Labels or instructions

Specjalizacje:

  • Content Creator
  • Designer
  • Deweloper

Elementy:

  • Formularze

Poziomy:

  • A

Spis treści

    Istota i cel kryterium

    Głównym zadaniem tego wymogu jest zagwarantowanie, że każdy człowiek – bez względu na stopień sprawności – bezbłędnie zorientuje się, jakie dane i w jakim formacie ma wprowadzić do pól formularza. Prawidłowo zaprojektowane opisy eliminują domysły, drastycznie zmniejszają zmęczenie psychiczne i zabezpieczają użytkownika przed popełnianiem błędów.

    Definicja w j. angielskim

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

    Definicja w j. polskim

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

    Słownik pojęć

    Etykieta (ang.) label
    –

    zwięzły komunikat tekstowy jednoznacznie definiujący przeznaczenie pojedynczego pola, trwale powiązany z nim bezpośrednio w strukturze kodu.

    Instrukcja (ang.) instruction
    –

    to rozbudowane wytyczne określające specyficzne reguły techniczne (np. wymagany format zapisu daty bądź kryteria dotyczące minimalnej złożoności haseł), umieszczone w bliskim sąsiedztwie danej kontrolki.

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

    • Osoby korzystające z czytników ekranu: Te technologie wspomagające potrzebują jednoznacznego tekstu, by oznajmić cel pola. Brak jasnej etykiety sprawia, że oprogramowanie odczyta element jako puste pole edycyjne, skazując użytkownika na całkowicie losową i chaotyczną nawigację.
    • Użytkowników z niepełnosprawnościami poznawczymi: Jasne instrukcje redukują obciążenie pamięciowe i poznawcze u osób z dysleksją czy ADHD, pomagając im zrozumieć zasady rządzące formularzem.
    • Osoby niedowidzące: Osoby używające silnego powiększenia ekranu widzą jedynie wycinek interfejsu. Wyrazistość bez kompromisów i bliskie sąsiedztwo etykiety pozwalają im natychmiast powiązać opis z właściwym polem.
    • Użytkowników sterujących systemem za pomocą głosu: Oprogramowanie do rozpoznawania mowy aktywuje elementy interaktywne na podstawie ich widocznych nazw. Gdy etykieta jest niewidoczna, nawigacja i obsługa formularza stają się niemożliwe.

    Zasady wdrażania i wymagania techniczne

    • Natywne powiązania w HTML: Zawsze używaj elementu <label> z atrybutem for, który musi perfekcyjnie odpowiadać wartości id pola wejściowego.
    • Grupowanie złożonych kontrolek: Wykorzystaj elementy <fieldset> oraz <legend> do spinania grup powiązanych pól (takich jak przyciski radiowe czy zestawy pól wyboru), co nada im nadrzędny, zrozumiały kontekst.
    • Przekazywanie formatów danych: Do skomplikowanych danych zastosuj atrybut aria-describedby wskazujący na identyfikator bloku tekstu z instrukcją formatowania.
    • Ważny balans techniczny (Niuanse standardu): Pamiętaj o kluczowym rozróżnieniu w specyfikacji WCAG. Kryterium 3.3.2 wymaga samego prezentowania i dostarczenia etykiety lub instrukcji dla użytkownika. Poprawność ich technicznego i programowego powiązania w drzewie DOM badana jest w ramach odrębnego kryterium 1.3.1 Informacje i relacje. Z kolei obecność ukrytej nazwy dostępnej (np. poprzez sam atrybut aria-label) to domena kryterium 4.1.2 Nazwa, rola, wartość – jeśli etykieta będzie widoczna tylko dla czytnika, a ukryta dla reszty, kryterium 3.3.2 zostanie niespełnione.
    • Unikaj pozornych rozwiązań: Nigdy nie polegaj wyłącznie na atrybucie placeholder. Tekst zastępczy znika po rozpoczęciu pisania i nie jest traktowany jako stała, stabilna etykieta.

    Wyjątki i sytuacje szczególne

    Reguła ta nie ma zastosowania do odnośników (linków) oraz elementów interaktywnych, które nie służą do wprowadzania danych przez użytkownika (np. widżety służące wyłącznie do rozwijania lub zwijania sekcji menu).

    W przypadku powszechnie zrozumiałych komponentów, takich jak globalna wyszukiwarka umieszczona w nagłówku portalu, dopuszczalne jest zrezygnowanie z rozbudowanych instrukcji tekstowych. Warunkiem jest jednak to, by pole było jednoznacznie zidentyfikowane wizualnie – na przykład poprzez bezpośrednio sąsiadujący przycisk z ikoną lupy, który pełni intuicyjną rolę wskazówki.

    Pamiętaj o zachowaniu umiaru – nadmiar informacji i przesadne przeładowanie tekstem instruktażowym może przynieść tyle samo szkody, co ich całkowity brak.

    Przykłady implementacji

    Najczęstsze błędy

    • F82: Całkowite niepowodzenie kryterium wynikające z wizualnego sformatowania zestawu pól (np. trzy oddzielne okienka na fragmenty numeru telefonu) bez dostarczenia jakiejkolwiek zrozumiałej etykiety tekstowej objaśniającej cel i strukturę tego podziału.
    • Zastępowanie etykiety przez tekst zastępczy: Wykorzystywanie wyłącznie atrybutu placeholder wewnątrz pola, który znika i bezpowrotnie odcina użytkownika od kontekstu w momencie wprowadzania danych.
    • Ukrywanie etykiet za pomocą stylów CSS: Stosowanie reguł takich jak display: none; lub visibility: hidden; dla elementów opisowych bez zapewnienia alternatywy, co usuwa je całkowicie z widoku oraz drzewa dostępności.
    • Pozorne opisy bez powiązania: Umieszczanie suchego tekstu wewnątrz elementu <span> obok pola wejściowego, co uniemożliwia technologiom wspomagającym właściwe odczytanie kontekstu.
    • Zbyt ogólne formułowanie komunikatów: Stosowanie lakonicznych i nieprecyzyjnych opisów typu „Wpisz dane”, które nie dają użytkownikowi żadnej realnej wiedzy o oczekiwanej zawartości.

    Najlepsze praktyki

    • Przewidywalne pozycjonowanie: Umieść etykiety tekstowe zawsze bezpośrednio nad lub przed polami edycyjnymi i obszarami tekstowymi. W przypadku pól wyboru (checkbox) i przycisków radiowych lokuj je konsekwentnie po prawej stronie kontrolki.
    • Jasne oznaczanie obowiązkowości: Informację o tym, że pole jest wymagane, wpisuj bezpośrednio w treść widocznej etykiety (np. poprzez dopisanie słowa „(wymagane)”).
    • Zwięzłość i bliskość wizualna: Dbaj o to, by etykiety były maksymalnie konkretne, wolne od skomplikowanego żargonu oraz ulokowane blisko pól, aby unikać ich optycznego rozdzielenia na dużych ekranach.

    Metody testowania

    • Narzędzie deweloperskie (ang.) Developer Tools: Wykonaj inspekcję kodu w strukturze drzewa (ang.) DOM, aby zweryfikować obecność opisów tekstowych dla każdego elementu interaktywnego oraz sprawdzić, czy etykiety nie zostały ukryte za pomocą stylów niszczących dostępność wizualną.
    • NVDA: Uruchom czytnik ekranu i przejdź kolejno przez wszystkie pola formularza wyłącznie za pomocą klawisza tabulacji. Zweryfikuj bez patrzenia na monitor, czy oprogramowanie poprawnie anonsuje przeznaczenie każdego pola oraz powiązane z nim instrukcje formatowania.
    • (ang.) WAVE Evaluation Tool: Wykorzystaj to rozszerzenie do błyskawicznego, wizualnego wykrycia kontrolek formularza pozbawionych jakichkolwiek etykiet lub wskazówek.
    • (ang.) IBM Equal Access Toolkit: Przeprowadź zautomatyzowany audyt strony, aby upewnić się, że dynamicznie generowane lub modyfikowane formularze zachowują pełną integralność informacyjną.
    • ANDI.JS: Wybierz dedykowany moduł analizy elementów formularzy i grafiki, aby precyzyjnie sprawdzić, jakie podpowiedzi wizualne i opisy są przekazywane bezpośrednio do technologii wspomagających.
    • Testowanie manualne: Wyłącz całkowicie style CSS i oceń, czy układ formularza, kolejność pól oraz towarzyszące im instrukcje formatowania pozostają w pełni logiczne i zrozumiałe dla odbiorcy.

    Sprawdź swoją wiedzę

    W linku poniżej znajduje się 6 przykładów pól formularzy. Twoim zadaniem jest ocenić, czy posiadają one wystarczające, widoczne etykiety lub instrukcje, które pozwalają bezbłędnie wprowadzić dane.

    Jak to sprawdzić?

    1. Sprawdź, czy każde pole ma widoczną etykietę jednoznacznie określającą jego cel.
    2. Zwróć uwagę, czy instrukcje dotyczące formatu danych (np. hasła, daty) są obecne i precyzyjne.
    3. Zbadaj, czy grupy powiązanych pól (np. fragmenty numeru telefonu, przyciski radiowe) posiadają nadrzędny, zrozumiały kontekst.
    4. Upewnij się, że etykiety nie opierają się wyłącznie na znikającym atrybucie placeholder.

    Notatka: Zanim zajrzysz do rozwiązania, przetestuj i zapisz swoje wnioski na kartce.
    Proponowane narzędzia: Klawiatura (Tab, Shift + Tab, Spacja, Enter ), Myszka, Narzędzie deweloperskie (ang.) Developer Tools, NVDA

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

    #1 DOBRZE

    Dlaczego: Pole posiada jasną, widoczną etykietę („Nowe hasło”). Dodatkowo, pod etykietą znajduje się precyzyjna instrukcja dotycząca wymagań formatowania (min. 8 znaków, cyfra), która jest programowo powiązana z polem za pomocą aria-describedby. Użytkownik od razu wie, co i w jakiej formie ma wpisać.

    #2 BŁĄD

    Problem: Pole wykorzystuje wyłącznie atrybut placeholder jako etykietę. Brak widocznego elementu <label>.
    Dlaczego: Tekst zastępczy znika w momencie rozpoczęcia wpisywania danych. Użytkownik, który przerwie wypełnianie formularza, traci kontekst i nie wie, jakie dane powinno zawierać to pole.
    Naprawa: Dodaj stałą, widoczną etykietę <label for="tc2-name"> nad lub obok pola.

    #3 BŁĄD

    Problem: Numer telefonu został rozbity na trzy osobne pola. W makiecie widać jedynie formatowanie wizualne („+48”, kreski) oraz ukryte atrybuty aria-label — brak jakiejkolwiek widocznej etykiety tekstowej objaśniającej cel pól.
    Dlaczego: Technika F82 dotyczy właśnie takiego przypadku: wizualne sformatowanie zestawu pól na numer telefonu bez dostarczenia zrozumiałej etykiety tekstowej. Ukryte aria-label nie ratują kryterium 3.3.2 (podobnie jak w przykładzie #5).
    Naprawa: Dodaj widoczną etykietę grupy (np. „Numer telefonu”) albo połącz pola w jedno z etykietą.

    #4 BŁĄD

    Problem: Etykieta „Wpisz dane:” jest zbyt lakoniczna i nieprecyzyjna.
    Dlaczego: Etykieta musi jednoznacznie definiować przeznaczenie pola. Komunikat „Wpisz dane” nie daje użytkownikowi żadnej realnej wiedzy o oczekiwanej zawartości (czy ma to być imię, PESEL, czy adres?).
    Naprawa: Zmień treść etykiety na konkretną, np. „Adres e-mail” lub „Numer dowodu osobistego”.

    #5 BŁĄD

    Problem: Etykieta „Miejscowość” została ukryta wizualnie za pomocą klasy .sr-only (screen-reader only).
    Dlaczego: Kryterium 3.3.2 wymaga, aby etykiety lub instrukcje były dostarczone (widoczne) dla wszystkich użytkowników, nie tylko dla osób korzystających z czytników ekranu. Ukrycie etykiety sprawia, że użytkownicy widzący nie wiedzą, do czego służy to pole.
    Naprawa: Usuń klasę ukrywającą etykietę, aby była ona stale widoczna na ekranie.

    #6 DOBRZE

    Dlaczego: Grupa przycisków radiowych została poprawnie objęta elementem <fieldset> z widocznym <legend> („Sposób dostawy”). Dzięki temu pojedyncze opcje („Kurier”, „Paczkomat”) zyskują nadrzędny, zrozumiały kontekst. Każdy przycisk ma też własną etykietę.

    Źródła

    Dodatkowe linki

    Wróć do wszystkich kryteriów