4.1.2 Nazwa, rola, wartość

Krótko

Każdy przycisk, link, pole formularza, przełącznik, zakładka albo inny komponent musi mieć programowo dostępną nazwę, rolę, stan i wartość. Czytnik ekranu powinien wiedzieć, czym jest element i co się z nim dzieje.

Najpierw używaj natywnego HTML. ARIA jest potrzebna dopiero wtedy, gdy tworzysz komponent, którego natywny HTML nie opisuje wystarczająco.

Problem w praktyce

Na ekranie widać ikonę koszyka. Dla czytnika ekranu jest to jednak przycisk bez nazwy albo zwykły div, którego nie da się obsłużyć z klawiatury. Użytkownik słyszy „przycisk” bez kontekstu albo w ogóle nie trafia na element.

To kryterium nie dotyczy tylko widocznego tekstu. Widoczny napis może być poprawny wizualnie, a dostępna nazwa komponentu nadal może być pusta, myląca albo niespójna.

Kogo to dotyczy

• Osób korzystających z czytników ekranu, które potrzebują nazwy i roli elementu.
• Osób korzystających z rozpoznawania mowy, które uruchamiają kontrolki po nazwie.
• Użytkowników klawiatury, jeśli komponent jest zrobiony z nieinteraktywnych elementów.
• Developerów tworzących własne komponenty, na przykład przełączniki, zakładki, dialogi i listy rozwijane.

Dobry przykład

• Akcja jest przyciskiem button, a przejście do innej strony linkiem a href.
• Pole formularza ma powiązaną etykietę label.
• Przycisk ikonowy ma dostępną nazwę, na przykład „Usuń produkt z koszyka”.
• Jeśli komponent ma stan, na przykład rozwinięty lub zwinięty, stan jest przekazywany programowo.

Zły przykład

• Klikalny div udaje przycisk.
• Przycisk z ikoną nie ma żadnej dostępnej nazwy.
• Przełącznik wizualnie pokazuje „włączone”, ale technologia wspomagająca nie dostaje tej wartości.
• Niestandardowa lista rozwijana nie informuje o roli, stanie i wybranej wartości.

Przykłady kodu

<button type="button">Zapisz ustawienia</button>

<button type="button" aria-label="Usuń produkt z koszyka">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

<div onclick="saveSettings()" class="button">
  Zapisz ustawienia
</div>

Przykład graficzny

Jak sprawdzić

1. Znajdź wszystkie interaktywne elementy: linki, przyciski, pola, kontrolki niestandardowe, zakładki, menu i przełączniki.
2. Sprawdź, czy są zrobione natywnymi elementami HTML tam, gdzie to możliwe.
3. Sprawdź w narzędziach deweloperskich albo accessibility tree, jaką mają nazwę, rolę i stan.
4. Przetestuj obsługę z klawiatury: Tab, Enter, Spacja i kierunek fokusu.
5. Jeśli użyto ARIA, sprawdź, czy nie dubluje natywnej semantyki i czy stan zmienia się razem z interfejsem.

Co sprawdzi automat, a czego nie

Automat może wykryć

• przyciski bez dostępnej nazwy,
• pola formularzy bez etykiety,
• część błędnego użycia ARIA,
• część elementów z rolą bez wymaganych stanów.

Automat nie oceni pewnie

• czy nazwa elementu jest zrozumiała w kontekście procesu,
• czy niestandardowy komponent ma pełną obsługę klawiaturą,
• czy stan komponentu zmienia się poprawnie w każdej ścieżce użycia.

Typowe błędy

• Klikalne div lub span zamiast przycisku albo linku.
• Przycisk z samą ikoną bez dostępnej nazwy.
• Checkbox albo switch, którego stan wizualny nie jest przekazywany programowo.
• Dodanie ARIA do elementu, który powinien być po prostu natywnym HTML.

Powiązane kryteria

• 2.5.3 Etykieta w nazwie: gdy widoczna etykieta musi być częścią dostępnej nazwy.
• 3.3.2 Etykiety lub instrukcje: gdy problem dotyczy treści etykiety albo instrukcji.
• 4.1.3 Komunikaty o stanie: gdy zmiana w interfejsie ma być zakomunikowana bez przenoszenia fokusu.

Źródła

• WCAG 2.2: 4.1.2 Name, Role, Value (otwiera się w nowym oknie)
• Understanding WCAG 4.1.2: Name, Role, Value (otwiera się w nowym oknie)
• How to Meet WCAG 4.1.2: Name, Role, Value (otwiera się w nowym oknie)
• H91: Using HTML form controls and links (otwiera się w nowym oknie)
• F68: Failure due to a user interface control not having a programmatically determined name (otwiera się w nowym oknie)