WCAG 2.5.3: Etykieta w nazwie
Wstęp do WCAG 2.5.3 „Etykieta w nazwie”
Kryterium sukcesu WCAG 2.5.3, zatytułowane „Etykieta w nazwie”, jest fundamentalne dla zapewnienia spójności między wizualną prezentacją elementu interfejsu użytkownika a jego reprezentacją dla technologii wspomagających. Wymaga ono, aby widoczna etykieta tekstowa lub graficzna elementu była zawarta w jego nazwie dostępnej (accessible name). Jest to kryterium na poziomie dostępności A i ma na celu ułatwienie interakcji użytkownikom, którzy polegają na widocznych wskazówkach, a jednocześnie korzystają z technologii wspomagających, takich jak czytniki ekranu lub oprogramowanie do rozpoznawania mowy.
Czym jest „Nazwa dostępna”?
„Nazwa dostępna” to programistycznie określona nazwa elementu interfejsu użytkownika, za pomocą której technologie wspomagające identyfikują i odczytują ten element. Jest to tekst, który jest przekazywany użytkownikom czytników ekranu i może być używany do sterowania interfejsem za pomocą poleceń głosowych. Nazwa dostępna może pochodzić z różnych źródeł, takich jak zawartość tekstowa elementu (np. tekst przycisku), treść elementu <label>
, atrybuty ARIA (aria-label
, aria-labelledby
) lub atrybut alt
dla obrazów.
Dlaczego „Etykieta w nazwie” jest ważna?
Spójność między tym, co użytkownik widzi, a tym, co jest przekazywane technologiom wspomagającym, ma kluczowe znaczenie dla wielu grup użytkowników:
- Użytkownicy czytników ekranu: Osoby niewidome lub niedowidzące mogą skanować wzrokowo stronę w poszukiwaniu etykiet, a następnie używać czytnika ekranu do interakcji. Jeśli nazwa dostępna nie zawiera widocznej etykiety, może to prowadzić do dezorientacji i braku pewności, czy interakcja nastąpi z właściwym elementem.
- Użytkownicy oprogramowania do rozpoznawania mowy: Osoby te często wydają polecenia, odwołując się do widocznych etykiet na ekranie (np. „Kliknij Wyślij”). Jeśli nazwa dostępna przycisku „Wyślij” to „Prześlij formularz”, oprogramowanie może nie rozpoznać polecenia lub wybrać niewłaściwy element. Spójność pozwala na bezproblemową interakcję głosową.
- Użytkownicy z niepełnosprawnością poznawczą lub dysleksją: Niespójność może zwiększać obciążenie poznawcze i utrudniać zrozumienie interfejsu. Przewidywalność i spójność są kluczowe dla łatwości użytkowania i zmniejszenia frustracji.
- Użytkownicy powiększenia ekranu: Osoby, które powiększają ekran, mogą widzieć tylko część etykiety lub elementu. Dopasowanie widocznej etykiety do nazwy dostępnej pomaga im zrozumieć kontekst, nawet jeśli nie widzą całego elementu naraz.
Zapewnienie, że nazwa dostępna zawiera widoczną etykietę, buduje zaufanie i poprawia ogólną użyteczność, czyniąc interfejs bardziej intuicyjnym i przewidywalnym.
Kryteria Sukcesu i Wymagania WCAG 2.5.3
Oficjalne brzmienie kryterium sukcesu 2.5.3 to:
Label in Name: For user interface components with labels that include text or images of text, the accessible name contains the text that is presented visually.
Czyli w tłumaczeniu:
Etykieta w nazwie: Dla komponentów interfejsu użytkownika z etykietami zawierającymi tekst lub obrazy tekstu, nazwa dostępna zawiera tekst, który jest prezentowany wizualnie.
Kluczowe aspekty tego kryterium:
- „Komponenty interfejsu użytkownika”: Obejmuje to przyciski, linki, pola formularzy (input, textarea, select), elementy sterujące niestandardowe i wszystko, z czym użytkownik może wchodzić w interakcję.
- „Etykiety zawierające tekst lub obrazy tekstu”: Kryterium odnosi się do elementów, które posiadają widoczną etykietę w formie tekstu (np. tekst przycisku „Wyślij”, tekst w
<label>
) lub obrazu zawierającego tekst (np. obraz z napisem „Menu”). Jeśli element ma widoczną ikonę, która jest wyłącznie graficznym symbolem (np. lupa symbolizująca wyszukiwanie) i nie zawiera tekstu, kryterium to nie wymaga, aby nazwa dostępna zawierała „tekst” z tej ikony, ponieważ go tam nie ma. Niemniej jednak, taki element nadal musi mieć nazwę dostępną. - „Nazwa dostępna zawiera tekst, który jest prezentowany wizualnie”: Oznacza to, że widoczny tekst nie musi być identyczny z całą nazwą dostępną, ale musi być jej podciągiem. Wielkość liter, interpunkcja i spacje nie muszą być identyczne (np. „wyślij” w „Wyślij formularz” jest zgodne). Ważne jest, aby widoczny tekst był rozpoznawalny w nazwie dostępnej.
Praktyczne wytyczne dotyczące zgodności
Aby zapewnić zgodność z WCAG 2.5.3, postępuj zgodnie z poniższymi wskazówkami:
Pola formularzy (<input>
, <textarea>
, <select>
)
- Używaj
<label>
: Zawsze powiązuj pola formularzy z elementem<label>
za pomocą atrybutówfor
iid
. Tekst wewnątrz<label>
automatycznie staje się nazwą dostępną, spełniając kryterium. aria-label
iaria-labelledby
: Jeśli używasz tych atrybutów do nadawania nazwy dostępnej, upewnij się, że ich wartość zawiera cały widoczny tekst etykiety związanej z danym polem.placeholder
: Tekst wplaceholder
może być traktowany jako widoczna etykieta, jeśli nie ma innej widocznej etykiety. W takim przypadku nazwa dostępna (np. zaria-label
) musi zawierać tekstplaceholder
.
Przyciski (<button>
, <input type="button">
)
- Tekst przycisku: Jeśli przycisk ma widoczny tekst, ten tekst powinien być jego zawartością (
<button>Tekst</button>
). Wtedy ten tekst jest automatycznie nazwą dostępną. - Przyciski ikonowe z tekstem: Jeśli przycisk zawiera ikonę ORAZ widoczny tekst (np. „ Zapisz”), nazwa dostępna musi zawierać ten widoczny tekst.
- Przyciski z obrazami tekstu: Jeśli przycisk wykorzystuje obraz, który zawiera tekst (np. obraz z napisem „MENU”), nazwa dostępna musi zawierać ten tekst.
- Przyciski ikonowe bez widocznego tekstu: Dla przycisków, które mają tylko ikonę (np. lupa) i nie zawierają żadnego widocznego tekstu (ani jako zawartość, ani jako obraz tekstu), kryterium 2.5.3 nie wymaga „zawierania” widocznego tekstu. Jednak nadal musisz zapewnić nazwę dostępną za pomocą
aria-label
(np.aria-label="Wyszukaj"
) lub wizualnie ukrytego tekstu.
Linki (<a>
)
- Tekst linku: Tekst między tagami
<a></a>
zazwyczaj stanowi jego nazwę dostępną. aria-label
dla linków: Jeśli używaszaria-label
dla linku, upewnij się, że jego wartość zawiera widoczny tekst linku. Np. dla linku<a href="#">Czytaj więcej</a>
,aria-label="Czytaj więcej o naszych usługach"
jest zgodne, alearia-label="O usługach"
nie jest.
Komponenty niestandardowe
- Dla niestandardowych elementów interfejsu upewnij się, że ich widoczne etykiety są uwzględnione w atrybutach ARIA, takich jak
aria-label
lubaria-labelledby
.
Przykłady prawidłowych i nieprawidłowych implementacji
Prawidłowe implementacje
Pola formularzy
Przykład 1: Standardowa etykieta <label>
Widoczna etykieta: „Imię”
<label for="firstName">Imię:</label>
<input type="text" id="firstName">
Nazwa dostępna: „Imię” (generowana automatycznie z <label>
)
Przykład 2: aria-label
zawierająca tekst placeholder
Widoczna etykieta: „Szukaj” (z placeholder
)
<input type="search" aria-label="Szukaj na stronie" placeholder="Szukaj...">
Nazwa dostępna: „Szukaj na stronie” (zawiera widoczny tekst „Szukaj”)
Przyciski
Przykład 1: Przycisk z widocznym tekstem
Widoczna etykieta: „Zapisz zmiany”
<button>Zapisz zmiany</button>
Nazwa dostępna: „Zapisz zmiany”
Przykład 2: Przycisk z ikoną i widocznym tekstem
Widoczna etykieta: „Dodaj”
<button>
<img src="add-icon.svg" alt="" aria-hidden="true">
Dodaj
</button>
Nazwa dostępna: „Dodaj”
Przykład 3: Przycisk z obrazem tekstu i aria-label
Widoczna etykieta: Obraz z napisem „Menu”
<button aria-label="Otwórz menu nawigacyjne">
<img src="menu-text.svg" alt="Menu" aria-hidden="true">
</button>
Nazwa dostępna: „Otwórz menu nawigacyjne” (zawiera widoczny tekst „Menu”)
Linki
Przykład 1: Link z widocznym tekstem i aria-label
Widoczna etykieta: „Regulamin”
<a href="/regulamin" aria-label="Przeczytaj pełny regulamin serwisu">Regulamin</a>
Nazwa dostępna: „Przeczytaj pełny regulamin serwisu” (zawiera widoczny tekst „Regulamin”)
Nieprawidłowe implementacje
Pola formularzy
Przykład 1: placeholder
jako jedyna etykieta bez nazwy dostępnej
Widoczna etykieta: „Email” (z placeholder
)
<input type="email" placeholder="Email">
Nazwa dostępna: Brak (lub zależy od przeglądarki/technologii wspomagającej, ale jest niezgodne z WCAG, ponieważ widoczny tekst nie jest zawarty w nazwie dostępnej)
Przykład 2: aria-label
nie zawiera widocznego tekstu <label>
Widoczna etykieta: „Hasło”
<label for="password">Hasło:</label>
<input type="password" id="password" aria-label="Twoje dane logowania użytkownika">
Nazwa dostępna: „Twoje dane logowania użytkownika”. NIE zawiera widocznego tekstu „Hasło”.
Przyciski
Przykład 1: aria-label
nie zawiera widocznego tekstu przycisku
Widoczna etykieta: „Zamknij”
<button aria-label="Dezaktywuj">Zamknij</button>
Nazwa dostępna: „Dezaktywuj”. NIE zawiera widocznego tekstu „Zamknij”.
Przykład 2: Przycisk ikonowy z widocznym tekstem, którego brakuje w aria-label
Widoczna etykieta: „X” (jako tekst, np. ikona zamknięcia)
<button aria-label="Zamknij okno">
<span>X</span>
</button>
Nazwa dostępna: „Zamknij okno”. NIE zawiera widocznego tekstu „X”.
Linki
Przykład 1: aria-label
nie zawiera widocznego tekstu linku
Widoczna etykieta: „Więcej”
<a href="#" aria-label="Szczegóły produktu">Więcej</a>
Nazwa dostępna: „Szczegóły produktu”. NIE zawiera widocznego tekstu „Więcej”.
Najlepsze praktyki i typowe pułapki
Najlepsze praktyki
- Używaj semantycznego HTML: Zawsze preferuj natywne elementy HTML (
<label>
,<button>
, tekst w<a>
) nad niestandardowymi rozwiązaniami ARIA, gdy to możliwe. Są one najbardziej odporne i zapewniają najlepszą kompatybilność. - Spójność jest kluczem: Upewnij się, że każdy element interfejsu, który ma widoczną etykietę tekstową lub graficzną, ma nazwę dostępną, która zawiera tę etykietę.
- Testuj za pomocą technologii wspomagających: Regularnie testuj swoje strony i aplikacje za pomocą czytników ekranu (np. NVDA, JAWS, VoiceOver) i oprogramowania do rozpoznawania mowy, aby upewnić się, że doświadczenie użytkownika jest spójne i przewidywalne.
- Zrozum kontekst: Jeśli widoczna etykieta jest częścią dłuższego wyrażenia (np. „Imię: [pole tekstowe]”), nazwa dostępna powinna nadal zawierać „Imię”.
- Kolejność źródeł nazwy dostępnej: Pamiętaj, że atrybuty ARIA (
aria-label
,aria-labelledby
) mają wysoki priorytet w określaniu nazwy dostępnej i mogą nadpisać natywne etykiety. Używaj ich świadomie i zawsze upewnij się, że widoczny tekst jest uwzględniony.
Typowe pułapki
- Używanie tylko
placeholder
jako etykiety: Tekstplaceholder
znika po wpisaniu tekstu i nie jest odpowiednio eksponowany dla wszystkich technologii wspomagających jako nazwa dostępna. Zawsze używaj<label>
lub odpowiedniegoaria-label
. Jeśliplaceholder
jest widoczny i jest jedyną etykietą, upewnij się, żearia-label
go zawiera. - Przyciski ikonowe bez odpowiedniej nazwy dostępnej: Jeśli ikona nie zawiera widocznego tekstu, kryterium 2.5.3 nie nakłada wymogu „zawierania” tekstu, ale element nadal musi mieć nazwę dostępną (np. za pomocą
aria-label
), która opisuje jego funkcję. Błędem jest, jeśli ta nazwa jest nieadekwatna lub jej brakuje. aria-label
, który nadpisuje i nie zawiera: To najczęstsza pułapka. Deweloperzy często używająaria-label
, aby zapewnić bardziej opisową nazwę, ale zapominają o włączeniu do niej oryginalnego widocznego tekstu. Zawsze dodawaj widoczny tekst do wartościaria-label
, jeśli jest on obecny.- Automatyczne generowanie nazw dostępnych: Niektóre frameworki lub narzędzia mogą automatycznie generować nazwy dostępne, które mogą nie być zgodne z widocznymi etykietami. Zawsze weryfikuj wynik i, jeśli to konieczne, ręcznie koryguj.
Podsumowanie
Kryterium sukcesu WCAG 2.5.3 „Etykieta w nazwie” jest kluczowe dla zapewnienia przewidywalnego i spójnego doświadczenia użytkownika. Dzięki niemu osoby korzystające z technologii wspomagających mogą łatwiej nawigować i wchodzić w interakcję z komponentami interfejsu, odwołując się do widocznych etykiet. Proste praktyki, takie jak prawidłowe użycie elementów <label>
, <button>
i przemyślane stosowanie atrybutów ARIA, znacząco przyczyniają się do osiągnięcia pełnej zgodności i poprawy dostępności dla wszystkich użytkowników.