Wróć do wszystkich kryteriów

2.5.3 Etykieta w nazwie (ang.) Label in Name

Specjalizacje:

  • Content Creator
  • Designer
  • Deweloper

Elementy:

  • Formularze
  • Linki
  • Przyciski i kontrolki

Poziomy:

  • A

Spis treści

    Istota i cel kryterium

    To kryterium gwarantuje nienaruszalną spójność pomiędzy warstwą wizualną interfejsu a jego techniczną interpretacją przez technologie wspomagające. Kluczowym założeniem jest wymaganie, aby każdy tekst lub obraz tekstu widoczny na ekranie jako etykieta elementu był bezpośrednio odzwierciedlony w jego programistycznej nazwie. Brak tej korelacji to rażące uchybienie, które wprowadza chaos i uniemożliwia intuicyjną interakcję z serwisem.

    Dzięki temu wdrożeniu użytkownicy posługujący się głosem lub czytnikami ekranu zyskują pełną przewidywalność zachowania aplikacji. Eliminujesz w ten sposób sytuacje, w których system asystujący interpretuje co innego, niż człowiek widzi na ekranie.

    Definicja w j. angielskim

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

    Definicja w j. polskim

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

    Słownik pojęć

    Nazwa dostępna (ang.) accessible name
    –

    to precyzyjnie określona w kodzie właściwość elementu interfejsu, za pomocą której technologie asystujące identyfikują i odczytują dany komponent. Może ona pochodzić z zawartości tekstowej, tagu <label>, atrybutu alt lub dyrektyw standardu ARIA. Stanowi ona tekstowy komunikat przekazywany bezpośrednio do syntezatora mowy lub oprogramowania sterującego głosowo.

    Obrazy tekstu
    –

    Grafiki, które prezentują tekst w formie obrazu (JPEG, PNG, BMP, GIF, TIFF itp.) lub wektora (SVG) zamiast standardowego kodu HTML, co często utrudnia ich skalowanie bez utraty jakości.

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

    • Użytkownicy oprogramowania do rozpoznawania mowy: Osoby sterujące komputerem za pomocą komend głosowych wypowiadają słowa widoczne na ekranie (np. „Kliknij Wyślij”). Jeśli nazwa dostępna różni się od widocznego napisu, oprogramowanie całkowicie zignoruje komendę, co wywołuje u użytkownika ogromną frustrację.
    • Użytkownicy czytników ekranu: Osoby słabowidzące, łączące wzrokowe skanowanie strony z syntezą mowy, napotykają barierę, gdy czytnik anonsuje zupełnie inne słowa niż te obecne na ekranie. Zgodność eliminuje dezorientację i brak pewności, czy interakcja nastąpi z właściwym elementem.
    • Użytkownicy z niepełnosprawnością poznawczą lub dysleksją: Niespójne komunikaty znacząco zwiększają obciążenie poznawcze. Przewidywalność i spójność interfejsu drastycznie zmniejsza zmęczenie psychiczne i eliminuje niepotrzebną frustrację.
    • Użytkownicy z ograniczeniami sprawności manualnej (ruchowej): Osoby te bardzo często łączą korzystanie z oprogramowania do rozpoznawania mowy z fizycznymi urządzeniami wskazującymi (np. specjalnymi myszami, przełącznikami czy emulatorami klawiatury). Głosowe wywoływanie elementów interfejsu chroni ich przed fizycznym zmęczeniem i bólem, które wywołuje długotrwałe, precyzyjne celowanie kursorem w małe obiekty na ekranie. Gdy widoczny tekst pozwala im natychmiast aktywować przycisk głosem, drastycznie zmniejsza to liczbę wymaganych operacji manualnych.
    • Użytkownicy powiększenia ekranu: Osoby korzystające z dużego powiększenia widzą jedynie mały wycinek interfejsu. Pełne dopasowanie etykiety wizualnej do nazwy programistycznej pomaga im błyskawicznie zrozumieć kontekst, nawet gdy nie widzą całego elementu naraz.
    • Użytkownicy systemów sterowania głosem w sytuacjach mobilnych: Osoby pełnosprawne, które obsługują aplikacje bezdotykowo (np. podczas jazdy samochodem lub gotowania przy użyciu komend głosowych), napotykają tę samą barierę, co osoby z niepełnosprawnościami, jeśli nazwa kodowa przycisku różni się od napisu na ekranie.

    Zasady wdrażania i wymagania techniczne

    • Linki (<a>): Zadbaj o to, aby tekst umieszczony między znacznikami stanowił jasną nazwę dostępną. Jeżeli stosujesz atrybut aria-label w celu rozszerzenia kontekstu, musisz bezwzględnie powtórzyć w nim widoczną etykietę. Dla odnośnika „Więcej”, zapis aria-label="Więcej informacji o naszych usługach" jest w pełni poprawny, ale aria-label="Szczegóły oferty" to najpoważniejsze uchybienie.
    • Przyciski (<button>, <input type="button">): Umieszczaj widoczny tekst bezpośrednio jako zawartość przycisku. W przyciskach ikonowych zawierających tekst (np. grafika plus słowo „Dodaj”), nazwa dostępna musi zawierać to słowo. Jeśli przycisk wyświetla obraz tekstu (np. grafika z napisem „MENU”), nazwa programistyczna musi zawierać ten tekst.
    • Pola formularzy (<input>, <textarea>, <select>): Łącz elementy formularza z natywnym znacznikiem <label> przy użyciu pasujących atrybutów id oraz for. Tekst z etykiety automatycznie wygeneruje prawidłową nazwę dostępną. Gdy używasz aria-label lub aria-labelledby, przypisz im wartość zawierającą widoczną etykietę. Tekst w placeholder traktuj jako etykietę wizualną tylko w ostateczności – wówczas nazwa dostępna musi go powielać.
    • Komponenty niestandardowe: Wykorzystaj atrybuty ARIA w autorskich elementach interfejsu w taki sposób, aby widoczny tekst etykiety został precyzyjnie wdrożony do wartości przekazywanej technologiom wspomagającym.

    Wyjątki i sytuacje szczególne

    Jeśli komponent interfejsu posiada wyłącznie ikonę będącą symbolem graficznym (np. ikona samej lupy bez jakichkolwiek liter czy słów) i nie zawiera tekstu ani obrazu tekstu, kryterium to nie nakłada wymogu inkluzji tekstu z tej ikony do nazwy dostępnej. Pamiętaj jednak, że taki element wciąż bezwzględnie musi posiadać poprawną nazwę dostępną (np. poprzez aria-label="Wyszukaj"), aby zapewnić podstawową dostępność UX.

    Przykłady implementacji

    Najczęstsze błędy

    • F96: Najpoważniejsze uchybienie polegające na tym, że obliczona nazwa dostępna nie zawiera w sobie widocznego tekstu etykiety. Dzieje się tak, gdy deweloper używa atrybutu aria-label do podania opisu, zapominając o włączeniu do niego oryginalnego tekstu, bądź gdy ukryte znaczniki przerywają ciąg znaków etykiety widocznej.
    • F111: Sytuacja, w której komponent posiada widoczną etykietę tekstową, ale całkowicie brakuje mu programistycznej nazwy dostępnej (np. podpis pod polem zrealizowany jako zwykły tekst w akapicie, bez powiązania za pomocą natywnego <label> lub atrybutów ARIA).
    • Zaburzenie kolejności słów w nazwie dostępnej: Poważne uchybienie polegające na tym, że nazwa programistyczna zawiera wszystkie słowa z widocznej etykiety, jednak ich szyk w kodzie został zmieniony (np. na ekranie widnieje napis „Zaloguj się”, a w atrybucie aria-label wpisano „Się zaloguj”). Oprogramowanie do rozpoznawania mowy oczekuje naturalnej sekwencji słów – każda zmiana kolejności blokuje możliwość głosowej aktywacji elementu.
    • Rozdzielanie widocznych słów innymi wyrazami: Błąd polegający na wtrącaniu dodatkowych, niewidocznych słów pomiędzy wyrazy tworzące etykietę wizualną (np. na przycisku umieszczono tekst „Anuluj subskrypcję”, a nazwa dostępna w kodzie brzmi „Anuluj moją subskrypcję”). Takie wdrożenie przerywa ciągłość frazy, przez co użytkownik dyktujący komendę głosową opartą na tym, co widzi, nie uruchomi żądanej akcji.
    • Stosowanie wyłącznie atrybutu placeholder jako jedynej etykiety: Znikający tekst uniemożliwia stabilne odczytywanie nazwy przez część technologii wspomagających i prowadzi do niezgodności.
    • Automatyczne generowanie nazw przez frameworki: Poleganie na skryptach, które generują losowe lub generyczne nazwy programistyczne, całkowicie oderwane od widocznego dla użytkownika tekstu.

    Najlepsze praktyki

    • Używaj semantycznego HTML: Zawsze preferuj natywne rozwiązania systemowe (<label>, <button>, tekst wewnątrz <a>) ponad skomplikowane i sztuczne konstrukcje ARIA. Gwarantują one wyrazistość bez kompromisów i najwyższą kompatybilność.
    • Zrozum hierarchię nadpisywania nazw: Pamiętaj, że atrybuty aria-label oraz aria-labelledby posiadają najwyższy priorytet i całkowicie usuwają tekst natywny. Stosuj je świadomie i zawsze powtarzaj w nich widoczny zwrot.
    • Zachowaj pełną spójność: Pilnuj, aby każdy interaktywny element z widocznym napisem posiadał programistyczną nazwę zawierającą ten napis na samym początku, co drastycznie ułatwi obsługę głosową.
    • Wykonuj regularne audyty: Testuj interfejs na różnych etapach produkcji przy pomocy rzeczywistych technologii wspomagających w celu natychmiastowego wychwycenia niespójności.

    Metody testowania

    • Narzędzie deweloperskie (ang.) Developer Tools: Otwórz zakładkę inspekcji kodu w przeglądarce i przeanalizuj sekcję (ang.) Event Listeners dla kluczowych elementów interaktywnych. Sprawdź, czy skrypty nie są powiązane ze zdarzeniami mousedown lub pointerdown. Upewnij się, że dominują zdarzenia click, mouseup lub pointerup.
    • Testowanie manualne: Wykonaj manualny test użytkownika za pomocą myszy oraz ekranu dotyczącego. Najedź na przycisk, naciśnij i przytrzymaj lewy klawisz myszy (lub dociśnij palec do ekranu), a następnie – bez zwalniania nacisku – przesuń kursor całkowicie poza obszar tego przycisku i dopiero wtedy puść. Jeśli akcja mimo to się wykonała, system zawiera krytyczny błąd dostępności.
    • Narzędzie deweloperskie (ang.) Developer Tools: Zweryfikuj w drzewie DOM (w zakładce dotyczącej dostępności / ułatwień dostępu), czy nazwa dostępna wybranego elementu interaktywnego zawiera w całości tekst prezentowany wizualnie na ekranie.
    • NVDA: Uruchom czytnik ekranu i przejdź tabulatorem do testowanego komponentu. Oceń słuchowo, czy wypowiadana przez syntezator fraza zawiera słowa widoczne dla oka na przycisku lub odnośniku.
    • (ang.) WAVE Evaluation Tool: Użyj tego narzędzia do błyskawicznego wykrywania błędów w strukturze pól formularzy oraz weryfikacji powiązań między komunikatami a etykietami.
    • (ang.) IBM Equal Access Toolkit: Przeprowadź zautomatyzowany audyt strony, aby zweryfikować, czy dynamiczne zmiany w interfejsie nie powodują nadpisania nazw dostępnych w sposób niezgodny z widocznymi etykietami.
    • ANDI.JS: Wybierz moduł analizujący elementy interaktywne lub moduł graficzny. Narzędzie podświetli dany komponent i wskaże jego dokładną nazwę programistyczną ((ang.) accessible name), co pozwoli Ci od razu ocenić jej spójność z tekstem wizualnym.

    Sprawdź swoją wiedzę

    W linku poniżej znajduje się 6 modułów testowych. Twoim zadaniem jest sprawdzenie, czy nazwa programistyczna przekazywana technologiom asystującym pokrywa się z etykietą tekstową, którą fizycznie widać na ekranie.

    Jak to sprawdzić?

    1. Zbadaj element używając Narzędzi Deweloperskich w przeglądarce (F12).
    2. Przejdź do zakładki Dostępność (Accessibility).
    3. Odszukaj pole „Nazwa” (Name) lub „Obliczona nazwa” (Computed Name).
    4. Sprawdź, czy wyświetlana tam nazwa zawiera dokładnie te same słowa, które widać na ekranie, zachowując spójny, nierozdzielony ciąg znaków.

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

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

    #1 DOBRZE

    Dlaczego: Idealne i najbezpieczniejsze rozwiązanie. Użyto natywnego tekstu wewnątrz znacznika <button>. Nazwa programistyczna odczytana przez drzewo dostępności to w 100% „Wyślij formularz”, czyli dokładnie to samo, co widzi oko użytkownika.

    #2 BŁĄD

    Problem: Atrybut aria-label="Rozpocznij" całkowicie nadpisuje tekst na przycisku. Nazwa w kodzie to „Rozpocznij”, choć wizualnie widnieje „Szukaj”.
    Dlaczego: Błąd opisany techniką F96. Użytkownik powie do mikrofonu „Kliknij Szukaj”, a oprogramowanie zignoruje komendę, bo technicznie przycisk ma inną nazwę.
    Naprawa: Usuń aria-label (przycisk i tak już ma tekst) lub upewnij się, że jego wartość zawiera słowo „Szukaj”.

    #3 BŁĄD


    Problem:     Widzimy tekst „Imię i nazwisko” nad polem, ale w kodzie to zwykły element <div>, niepowiązany z wejściem formularza.
    Dlaczego: Błąd opisany techniką F111. Pole nie ma żadnej programistycznej nazwy dostępnej (accessible name), mimo że wizualnie posiada etykietę.
    Naprawa: Zastąp <div> natywnym znacznikiem <label for="imie"> i dodaj id="imie" do inputa.

    #4 DOBRZE

    Dlaczego: Atrybut aria-label prawidłowo rozszerza kontekst linku, powtarzając widoczny tekst „Więcej” i dodając resztę frazy („informacji o usługach”). Został też umieszczony na początku nazwy, dzięki czemu użytkownik bez problemu aktywuje go głosem poleceniem „Więcej”.

    #5 BŁĄD

    Problem: Dodatkowe słowo „moją” zostało umieszczone w aria-label tuż pomiędzy wyrazami, które normalnie widzi użytkownik („Anuluj subskrypcję”).
    Dlaczego: Narusza to ciągłość frazy. Oprogramowanie sterowane głosem oczekuje, że widoczne słowa wystąpią w kodzie obok siebie w nienaruszonym szyku.
    Naprawa: Zmień atrybut na aria-label="Anuluj subskrypcję swojego konta" (widoczne słowa są koło siebie) lub całkowicie usuń ten atrybut.

    #6 DOBRZE

    Dlaczego: Przycisk składa się wyłącznie z ikony (SVG) i nie zawiera żadnego widocznego tekstu (w tym obrazów tekstu). Z racji tego, że nie ma fizycznej etykiety, zasada spójności „Label in Name” dla 2.5.3 naturalnie tu nie obowiązuje. Nadana mu etykieta aria-label="Dodaj do ulubionych" prawidłowo załatwia wymóg nazwy programistycznej dla czytników (4.1.2), a dla wzrokowców pozostaje ikonka.

    Źródła

    Dodatkowe linki

    Wróć do wszystkich kryteriów