WCAG 2.5.3: Etykieta w nazwie

Co oznacza ta zasada

\n

WCAG 2.5.3 — Label in Name (etykieta w nazwie) — ma zastosowanie do każdego komponentu interfejsu użytkownika, który ma widoczną etykietę tekstową. Kryterium wymaga, aby nazwa dostępna tego komponentu albo dokładnie odpowiadała widocznej etykiecie tekstowej, albo przynajmniej zawierała widoczną etykietę tekstową jako podciąg. Zapobiega to sytuacji, w której użytkownik widzi na ekranie jedną etykietę, ale jego technologia asystująca lub oprogramowanie do rozpoznawania mowy rozpoznaje zupełnie inną nazwę „w tle”.

\n

Nazwa dostępna to nazwa ujawniana w drzewie dostępności i używana przez czytniki ekranu, oprogramowanie sterowane głosem oraz inne technologie asystujące. Może pochodzić z różnych źródeł, w tym z widocznej treści tekstowej elementu, atrybutu aria-label, odwołania aria-labelledby, atrybutu title lub powiązanego elementu <label>. Gdy deweloper nadpisuje nazwę dostępną czymś, co nie zawiera widocznej etykiety tekstowej, powstaje niedopasowanie i kryterium nie zostaje spełnione.

\n

Dotknięte elementy obejmują każdy interaktywny komponent, który wyświetla tekst i ma również nazwę dostępną: przyciski, linki, pola formularza z widocznymi etykietami, elementy menu, karty, pola wyboru (checkboxy), przyciski opcji (radio buttony) oraz niestandardowe widżety ARIA. Elementy nieinteraktywne, takie jak akapity czy nagłówki, nie są objęte tym kryterium.

\n

Co uznaje się za spełnienie: Nazwa dostępna zawiera widoczną etykietę tekstową jako ciągły podciąg, z pominięciem początkowych i końcowych znaków odstępu. Dopasowanie jest nieczułe na wielkość liter. Na przykład, jeśli na przycisku widnieje „Search Products”, nazwa dostępna „Search Products Now” spełnia kryterium, ponieważ zawiera „Search Products”. Nazwa dostępna „Find Products” nie spełnia kryterium, ponieważ nie zawiera widocznego tekstu.

\n

Co uznaje się za niespełnienie: Nazwa dostępna jest całkowicie inna niż widoczna etykieta lub nazwa dostępna pomija istotną część widocznej etykiety. Przycisk, który wizualnie wyświetla „Buy Now”, ale ma aria-label='Purchase item', nie spełnia tego kryterium. Podobnie, link, na którym widnieje „Contact Us”, ale jest opakowany w element z aria-label='Reach our team', również nie spełnia kryterium.

\n

Oficjalne wyjątki zdefiniowane w WCAG: Kryterium nie ma zastosowania do komponentów, w których etykieta jest czysto symboliczna lub piktograficzna i nie ma tekstowego odpowiednika (na przykład przycisk wyłącznie z ikoną, bez widocznego tekstu). Nie ma też zastosowania, gdy tekst jest częścią czysto dekoracyjnego elementu, który nie niesie znaczenia semantycznego. Wyłączone są również zapisy matematyczne oraz sytuacje specyficzne dla języka, w których reprezentacja tekstowa nie może zostać odwzorowana na słowo mówione. Dodatkowo, komponenty, w których nazwa dostępna jest celowo rozszerzona o dodatkowy kontekst — pod warunkiem, że widoczny tekst nadal jest obecny w nazwie dostępnej — są zgodne z kryterium.

\n\n

Dlaczego to ma znaczenie

\n

Kryterium to przede wszystkim chroni użytkowników polegających na oprogramowaniu do rozpoznawania mowy, takim jak Dragon NaturallySpeaking (obecnie Dragon Professional), Windows Speech Recognition czy Voice Control firmy Apple. Użytkownicy ci nawigują i aktywują elementy interfejsu, wypowiadając etykietę, którą widzą na ekranie. Gdy nazwa dostępna nie odpowiada widocznej etykiecie, oprogramowanie nie może znaleźć docelowego elementu, gdy użytkownik wypowiada jego nazwę, co w praktyce czyni kontrolkę nieosiągalną bez myszy lub klawiatury. Dla użytkowników z niepełnosprawnościami ruchowymi — w tym osób z zespołem cieśni nadgarstka, dystrofią mięśniową, porażeniem mózgowym czy urazami rdzenia kręgowego — sterowanie głosem jest często podstawowym lub jedynym sposobem obsługi komputera. Niedopasowanie na jednym przycisku może zablokować dostęp do całego procesu.

\n

Użytkownicy czytników ekranu również są dotknięci. Gdy czytnik ekranu ogłasza nazwę dostępną, która różni się od tego, co jest widoczne na ekranie, powoduje to dezorientację poznawczą. Użytkownik widzący, który jednocześnie korzysta z czytnika ekranu — na przykład osoba słabowidząca, która używa jednocześnie informacji wizualnych i dźwiękowych — może słyszeć jedno, a czytać coś innego na ekranie, co zaburza jego mentalny model interfejsu.

\n

Użytkownicy z niepełnosprawnościami poznawczymi odnoszą korzyść ze spójności między tym, co czytają, a tym, co jest wypowiadane lub ogłaszane. Nieoczekiwane zmiany nazw zwiększają obciążenie poznawcze i mogą powodować zamieszanie lub błędy, szczególnie u użytkowników z zaburzeniami pamięci lub u osób, które dopiero uczą się korzystania z systemu.

\n

Konkretny scenariusz z rzeczywistości: Rozważ stronę finalizacji zakupu w e‑commerce z przyciskiem, który wizualnie wyświetla tekst „Place Order”. Deweloper dodaje aria-label='Submit purchase form', aby zapewnić — w jego ocenie — bardziej opisową nazwę. Klient korzystający z Dragon NaturallySpeaking mówi „Click Place Order” — Dragon skanuje drzewo dostępności, nie znajduje żadnego elementu o nazwie „Place Order” i nie może aktywować przycisku. Klient nie może dokończyć zakupu bez przełączenia się na sterowanie myszą, co może być dla niego niemożliwe. Porzuca transakcję. Nie jest to hipotetyczny przypadek brzegowy; to częsty wzorzec błędu wykrywany w zautomatyzowanych audytach na stronach sklepów i banków.

\n

Zgodnie z danymi Światowej Organizacji Zdrowia ponad miliard ludzi na całym świecie żyje z jakąś formą niepełnosprawności. Raport WebAIM Million z 2023 roku wykazał, że niedopasowania etykiet w kontekście WCAG 2.5.3 pojawiały się w istotnej części audytowanych stron, często wprowadzane przez dobrze intencjonowane, ale niewłaściwie zastosowane ARIA. Poza dostępnością, spójne etykietowanie poprawia SEO, ponieważ roboty wyszukiwarek indeksujące tekst linków i przycisków na potrzeby rankingu trafności otrzymują bardziej znaczące sygnały, gdy nazwy dostępne są zgodne z widocznym tekstem.

\n\n

Powiązane reguły Axe-core

\n

\n
• label-content-name-mismatch: To podstawowa zautomatyzowana reguła powiązana z WCAG 2.5.3. Reguła sprawdza elementy interaktywne — takie jak przyciski, linki oraz role ARIA, takie jak role='button', role='link', role='menuitem' i role='tab' — które mają zarówno widoczną etykietę tekstową, jak i nazwę dostępną. Oznacza każdy element, w którym nazwa dostępna nie zawiera widocznego tekstu jako podciągu (z nieczułością na wielkość liter). Reguła w szczególności celuje w elementy, w których nazwa dostępna jest nadpisana przez aria-label lub aria-labelledby w sposób odbiegający od tekstu na ekranie. Axe raportuje je jako naruszenia o poziomie wpływu „serious”, ponieważ bezpośrednio uniemożliwiają użytkownikom sterującym głosem aktywowanie kontrolek.
\n
• Ograniczenia automatycznego wykrywania: Narzędzia automatyczne, takie jak axe-core, mogą wiarygodnie wykrywać niedopasowania, gdy widoczny tekst jest renderowany jako zwykłe węzły tekstowe w elemencie, a nazwa dostępna pochodzi ze statycznego atrybutu aria-label lub aria-labelledby. Jednak testy manualne są wymagane, gdy: (1) widoczny tekst jest renderowany za pomocą pseudoelementów CSS ::before lub ::after, ponieważ mogą one być uwzględniane w drzewie dostępności lub nie — w zależności od przeglądarki i wersji technologii asystującej; (2) etykieta jest dynamicznie wstawiana przez JavaScript po załadowaniu strony; (3) widoczny tekst zawiera ikony lub tekst w formie obrazu, gdzie komponent tekstowy trzeba wywnioskować; (4) obliczona nazwa dostępna elementu obejmuje złożone łańcuchy aria-labelledby, które łączą wiele elementów. W takich przypadkach tester‑człowiek korzystający z czytnika ekranu musi zweryfikować, co jest faktycznie ogłaszane w porównaniu z tym, co jest widoczne.
\n

\n\n

Jak testować

\n

\n
1. Automatyczne skanowanie za pomocą axe DevTools lub Lighthouse: Zainstaluj rozszerzenie przeglądarki axe DevTools (Chrome lub Firefox) lub uruchom audyt dostępności Lighthouse w Chrome DevTools. Uruchom skanowanie na w pełni wyrenderowanej stronie — upewnij się, że treści dynamiczne, okna modalne i rozwinięte menu są otwarte, jeśli zawierają elementy interaktywne. W panelu wyników axe przefiltruj według identyfikatora reguły label-content-name-mismatch. Każdy oznaczony element wyświetli swoją obliczoną nazwę dostępną obok widocznego tekstu, co natychmiast uwidoczni niedopasowanie. Zanotuj selektor elementu i sprawdź DOM, aby zidentyfikować źródło nadpisania nazwy dostępnej. Lighthouse pokaże te same błędy w kategorii „Accessibility” z odniesieniem do WCAG 2.5.3.
\n
2. Ręczna inspekcja za pomocą narzędzi deweloperskich przeglądarki: Otwórz panel Accessibility (Chrome DevTools → Elements → zakładka Accessibility lub Firefox DevTools → zakładka Accessibility). Wybierz każdy element interaktywny, który ma widoczny tekst. Sprawdź sekcję „Computed Properties” dla pola Name elementu. Porównaj tę wartość z widoczną etykietą. Jeśli obliczona nazwa nie zawiera widocznego tekstu etykiety jako podciągu, element nie spełnia 2.5.3.
\n
3. Testowanie z czytnikiem ekranu NVDA + Firefox: Otwórz Firefoksa z uruchomionym NVDA. Nawiguj do każdego elementu interaktywnego za pomocą klawisza Tab. Słuchaj, co NVDA ogłasza jako nazwę elementu. Zanotuj wszelkie rozbieżności między ogłaszaną nazwą a tekstem wyświetlanym na ekranie. Użyj listy elementów NVDA (Insert+F7), aby przeglądać wszystkie linki i przyciski oraz hurtowo porównywać ogłaszane nazwy z etykietami wizualnymi.
\n
4. Testowanie z czytnikiem ekranu JAWS + Chrome: Otwórz Chrome z uruchomionym JAWS. Przechodź po wszystkich kontrolkach interaktywnych za pomocą klawisza Tab. JAWS będzie ogłaszać nazwę dostępną, a następnie rolę. Gdy ogłaszana nazwa nie zawiera widocznego tekstu, zanotuj ten element. Dodatkowo użyj „Browse Mode” JAWS i wirtualnego widoku, aby zobaczyć obliczoną nazwę dostępną dla każdej kontrolki.
\n
5. Testowanie z czytnikiem ekranu VoiceOver + Safari (macOS/iOS): Włącz VoiceOver (Command+F5 na macOS). Używaj klawisza Tab lub VO+Strzałka w prawo, aby nawigować po elementach interaktywnych. VoiceOver ogłasza nazwę dostępną każdej kontrolki. Na iOS przesuń palcem w prawo, aby przechodzić między elementami i nasłuchiwać rozbieżności między nazwą a etykietą.
\n
6. Test rozpoznawania mowy z Voice Control (macOS/iOS) lub Dragon: Włącz Voice Control w macOS (System Settings → Accessibility → Voice Control). Powiedz „Show names”, aby wyświetlić etykiety wszystkich elementów interaktywnych. Sprawdź, czy etykiety pokazywane przez Voice Control odpowiadają widocznemu tekstowi na ekranie. Spróbuj aktywować kontrolki, wypowiadając widoczny tekst etykiety — każda kontrolka, która nie reaguje na swoją widoczną nazwę, stanowi naruszenie 2.5.3. Powtórz z Dragon NaturallySpeaking w systemie Windows, jeśli jest dostępny, używając komendy „Click [label]”.
\n

\n\n

Jak naprawić

\n\n

Przycisk z nadpisującym aria-label — niepoprawne

\n

<!-- FAIL: aria-label całkowicie zastępuje widoczny tekst \"Search\"\n     tekstem \"Execute query\", co psuje sterowanie głosem -->\n<button aria-label='Execute query'>\n  Search\n</button>

\n\n

Przycisk z nadpisującym aria-label — poprawne

\n

<!-- PASS: Całkowicie usuń niedopasowany aria-label.\n     Widoczny tekst przycisku \"Search\" automatycznie staje się jego nazwą dostępną.\n     Użytkownicy sterujący głosem mogą powiedzieć \"Click Search\", aby go aktywować. -->\n<button>\n  Search\n</button>\n\n<!-- PASS (alternatywa): Jeśli potrzebny jest dodatkowy kontekst,\n     upewnij się, że nazwa dostępna ZAWIERA widoczny tekst. -->\n<button aria-label='Search products'>\n  Search\n</button>

\n\n

Link z aria-labelledby wskazującym na niepowiązany tekst — niepoprawne

\n

<!-- FAIL: aria-labelledby odwołuje się do nagłówka \"Our Services\",\n     ale link wizualnie wyświetla \"Learn more\",\n     więc nazwa dostępna to \"Our Services\" zamiast \"Learn more\" -->\n<h2 id='services-heading'>Our Services</h2>\n<p>\n  <a href='/services' aria-labelledby='services-heading'>Learn more</a>\n</p>

\n\n

Link z aria-labelledby wskazującym na niepowiązany tekst — poprawne

\n

<!-- PASS: Użyj aria-labelledby, aby połączyć własny tekst linku z nagłówkiem.\n     Nazwa dostępna staje się \"Learn more Our Services\",\n     co zawiera widoczną etykietę \"Learn more\". -->\n<h2 id='services-heading'>Our Services</h2>\n<p>\n  <a href='/services' id='learn-link' aria-labelledby='learn-link services-heading'>\n    Learn more\n  </a>\n</p>\n\n<!-- PASS (alternatywa): Spraw, aby widoczny tekst linku był sam w sobie opisowy,\n     tak aby nie było potrzeby nadpisywania. -->\n<a href='/services'>Learn more about our services</a>

\n\n

Przycisk z ikoną, w którym aria-label jest sprzeczne z widocznym tekstem — niepoprawne

\n

<!-- FAIL: Przycisk pokazuje ikonę koszyka ORAZ tekst \"Cart\".\n     Atrybut aria-label 'View shopping basket' nie zawiera \"Cart\",\n     więc użytkownicy mówiący \"Click Cart\" nie uzyskają reakcji. -->\n<button aria-label='View shopping basket'>\n  <svg aria-hidden='true'><!-- cart icon --></svg>\n  Cart\n</button>

\n\n

Przycisk z ikoną, w którym aria-label jest sprzeczne z widocznym tekstem — poprawne

\n

<!-- PASS: Atrybut aria-label zawiera widoczny tekst \"Cart\" jako podciąg.\n     Użytkownicy sterujący głosem mogą powiedzieć \"Click Cart\" lub \"Click View Cart\" i oba zadziałają. -->\n<button aria-label='View Cart'>\n  <svg aria-hidden='true'><!-- cart icon --></svg>\n  Cart\n</button>\n\n<!-- PASS (preferowane): Usuń aria-label i ukryj ikonę w drzewie dostępności.\n     Tekst przycisku \"Cart\" staje się bezpośrednio nazwą dostępną. -->\n<button>\n  <svg aria-hidden='true' focusable='false'><!-- cart icon --></svg>\n  Cart\n</button>

\n\n

Pole formularza z widoczną etykietą, ale niedopasowanym aria-label — niepoprawne

\n\n

(Content truncated due to token limit — please retry this article.)