WCAG 4.1.2: Nazwa, rola, wartość

Poziom: A

Wprowadzenie

Kryterium sukcesu 4.1.2 „Nazwa, rola, wartość” jest kluczowym elementem wytycznej 4.1 „Kompatybilność” standardu WCAG (Web Content Accessibility Guidelines) 2.0 i 2.1. Ma ono na celu zapewnienie, że wszystkie komponenty interfejsu użytkownika (UI), takie jak przyciski, linki, pola formularzy, przełączniki czy niestandardowe kontrolki, mogą być w pełni zrozumiane i obsługiwane przez technologie wspomagające (AT), takie jak czytniki ekranu, oprogramowanie do rozpoznawania mowy czy alternatywne urządzenia wejściowe.

Zgodnie z tym kryterium, każdy komponent UI musi mieć programowo określoną:

• Nazwę (accessible name): Tekst, który jednoznacznie identyfikuje komponent i jest odczytywany przez technologie wspomagające.
• Rolę (role): Typ komponentu (np. przycisk, pole edycji, link, checkbox), informujący o jego funkcji i sposobie interakcji.
• Wartość/Stan (value/state): Bieżący stan komponentu (np. zaznaczone, rozwinięte, zablokowane) lub jego aktualna wartość (np. tekst w polu wejściowym).

Dodatkowo, wszelkie zmiany w tych właściwościach muszą być dynamicznie aktualizowane i programowo dostępne dla technologii wspomagających.

Dlaczego to ważne? (Wpływ na dostępność)

Niespełnienie kryterium 4.1.2 może całkowicie uniemożliwić lub znacząco utrudnić korzystanie ze strony internetowej wielu grupom użytkowników. Ma to bezpośredni wpływ na:

• Użytkowników niewidomych i słabowidzących: Osoby korzystające z czytników ekranu polegają na programowo dostępnych nazwach, rolach i wartościach, aby zrozumieć, czym jest dany element i jak z nim wejść w interakcję. Bez tych informacji, czytnik ekranu może jedynie odczytać „przycisk” lub „nieoznakowany element”, co czyni stronę niezrozumiałą i niemożliwą do nawigacji.
• Użytkowników z niepełnosprawnością ruchową: Osoby używające oprogramowania do rozpoznawania mowy lub innych alternatywnych metod wprowadzania (np. przełączników) muszą być w stanie wydać polecenia odwołujące się do konkretnych elementów interfejsu (np. „kliknij przycisk Wyślij”, „wypełnij pole Email”). Jeśli komponent nie ma programowo dostępnej nazwy, aktywacja go staje się niemożliwa.
• Użytkowników z zaburzeniami poznawczymi: Przejrzysta i spójna informacja o elementach interfejsu pomaga w zrozumieniu ich funkcji i przewidywaniu zachowań. Programowo określone właściwości wspierają również spójność wizualną i funkcjonalną, redukując obciążenie poznawcze.
• Użytkowników klawiatury: Chociaż nawigacja klawiaturowa jest częściowo pokryta przez inne kryteria (2.1.1), możliwość zrozumienia, który element jest aktualnie aktywny (ma fokus), często zależy od jego programowo określonych właściwości.

Brak odpowiednich informacji programowych prowadzi do sytuacji, w której interfejs użytkownika jest funkcjonalnie niewidoczny dla technologii wspomagających, tworząc barierę nie do pokonania dla wielu osób.

Kryteria sukcesu i wymagania

Kryterium 4.1.2 wymaga, aby dla wszystkich komponentów interfejsu użytkownika:

1. Nazwa (Accessible Name): Programowo określona nazwa musi być dostępna dla wszystkich komponentów interfejsu użytkownika. Dla czytnika ekranu jest to zazwyczaj pierwsze, co jest odczytywane, informując użytkownika o celu danego elementu.
2. Rola (Role): Programowo określona rola musi być dostępna. Rola określa typ komponentu (np. przycisk, pole wyboru, link, pasek postępu) i informuje o jego interaktywności i oczekiwanym zachowaniu.
3. Wartość/Stan (Value/State): Dla komponentów, które mają stany (np. zaznaczone/niezaznaczone, rozwinięte/zwinięte) lub wartości (np. aktualna wartość suwaka, tekst w polu wejściowym), te informacje muszą być programowo dostępne.
4. Zmiany w stanie: Wszystkie zmiany w stanie, właściwościach i wartościach komponentu muszą być programowo dostępne i, jeśli to konieczne, zgłaszane technologiom wspomagającym (np. poprzez regiony ARIA live).

Te informacje są przekazywane technologiom wspomagającym poprzez interfejsy API dostępności (Accessibility API) przeglądarki, które czerpią dane z drzewa dostępności (Accessibility Tree) generowanego na podstawie DOM (Document Object Model) strony.

Praktyczne wytyczne dotyczące zgodności

Aby spełnić kryterium 4.1.2, należy przestrzegać następujących zasad:

1. Preferuj natywne elementy HTML

Standardowe elementy HTML (<button>, <input>, <a>, <select>, <textarea>) posiadają wbudowaną semantykę, co oznacza, że ich nazwa, rola i podstawowe stany są automatycznie udostępniane technologiom wspomagającym przez przeglądarkę.

• Używaj <button> zamiast <div> z obsługą kliknięcia.
• Używaj <a> dla linków nawigacyjnych, a nie <span>.
• Stosuj semantyczne nagłówki (<h1>–<h6>) i listy (<ul>, <ol>).

2. Etykietowanie pól formularzy

Każde pole formularza powinno mieć programowo powiązaną etykietę. Najlepszą praktyką jest użycie elementu <label> z atrybutem for, który odwołuje się do id pola formularza.

• <label for="email">Adres e-mail</label><input type="email" id="email">
• Dla ukrytych etykiet lub przypadków, gdzie <label> nie może być użyty, stosuj atrybuty ARIA: aria-label="Opis pola" lub aria-labelledby="ID_etykiety".
• Używaj atrybutu placeholder tylko jako wskazówki, nigdy jako jedynej etykiety.

3. Tekst alternatywny dla obrazów i multimediów

Dla każdego znaczącego obrazu (<img>) wymagany jest atrybut alt z opisowym tekstem. Dla obrazów czysto dekoracyjnych, alt="" (pusty atrybut) jest odpowiedni.

• <img src="logo.png" alt="Logo firmy ExampleCorp">
• Dla bardziej złożonych multimediów (audio, wideo), zapewnij napisy, transkrypcje i/lub ścieżki audiodeskrypcji.

4. Opisowy tekst linków

Tekst linku (pomiędzy <a> i </a>) powinien być zrozumiały poza kontekstem, informując użytkownika o celu linku. Unikaj „kliknij tutaj” lub „więcej”.

• <a href="/#">Przeglądaj nasze produkty</a> zamiast <a href="/#">Kliknij tutaj</a>.
• W przypadku ikon linków bez widocznego tekstu, użyj aria-label: <a href="/facebook" aria-label="Odwiedź nas na Facebooku"><i class="fa fa-facebook"></i></a>.

5. Użycie WAI-ARIA dla niestandardowych komponentów

Gdy natywne elementy HTML nie są wystarczające do stworzenia złożonego komponentu UI, należy użyć atrybutów WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) do zdefiniowania nazwy, roli i stanu:

• role: Zdefiniuj typ komponentu, np. role="button", role="tab", role="slider".
• aria-label: Ustaw dostępną nazwę, jeśli nie ma widocznej etykiety lub etykieta jest niewystarczająca.
• aria-labelledby: Odwołuje się do id istniejącego elementu tekstowego na stronie, który służy jako nazwa komponentu.
• aria-describedby: Odwołuje się do id elementu zawierającego dodatkowy opis komponentu (nie jest częścią nazwy, ale dostarcza kontekst).
• Stany i wartości ARIA: Używaj atrybutów takich jak aria-checked="true/false" (dla checkboxów, przełączników), aria-expanded="true/false" (dla akordeonów, menu), aria-selected="true/false" (dla zakładek), aria-valuenow, aria-valuemin, aria-valuemax (dla suwaków).
• JavaScript: Należy dynamicznie aktualizować atrybuty ARIA za pomocą JavaScriptu, gdy stan komponentu się zmienia (np. po kliknięciu przycisku rozwijającego menu, zmienić aria-expanded="false" na aria-expanded="true").

Przykłady implementacji

Poprawne implementacje

<label for="firstName">Imię:</label>
<input type="text" id="firstName" name="firstName">

<button type="submit">Wyślij formularz</button>

<img src="wykres-sprzedazy.png" alt="Wykres przedstawiający wzrost sprzedaży o 20% w ostatnim kwartale">

<div id="toggleSwitch" role="switch" aria-checked="false" tabindex="0" aria-label="Włącz powiadomienia e-mail">
  <span class="sr-only">Włącz powiadomienia e-mail</span>
  <span class="switch-indicator"></span>
</div>

const toggleSwitch = document.getElementById('toggleSwitch');
toggleSwitch.addEventListener('click', () => {
  let isChecked = toggleSwitch.getAttribute('aria-checked') === 'true';
  toggleSwitch.setAttribute('aria-checked', !isChecked);
});
toggleSwitch.addEventListener('keydown', (e) => {
  if (e.key === ' ' || e.key === 'Enter') {
    e.preventDefault();
    let isChecked = toggleSwitch.getAttribute('aria-checked') === 'true';
    toggleSwitch.setAttribute('aria-checked', !isChecked);
  }
});

Niepoprawne implementacje

<input type="text" placeholder="Wpisz swoje imię">

<button><img src="ikona-szukaj.png" alt=""></button>

<img src="glowna-grafika.jpg">

<div class="custom-button" onclick="doSomething()">Kliknij mnie</div>

Najlepsze praktyki i typowe pułapki

Najlepsze praktyki:

• Prioritet dla HTML semantycznego: Zawsze, gdy jest to możliwe, używaj natywnych elementów HTML. To najbardziej solidna i przewidywalna podstawa dostępności.
• Uważne stosowanie ARIA: Jeśli musisz użyć niestandardowych komponentów, stosuj ARIA zgodnie ze specyfikacją. ARIA powinna być używana jako uzupełnienie, a nie zastępstwo dla poprawnego HTML.
• Testowanie z czytnikami ekranu: Regularnie testuj swoją stronę za pomocą różnych czytników ekranu (np. NVDA, JAWS na Windowsie, VoiceOver na macOS/iOS) oraz innych technologii wspomagających. Tylko to da Ci pełny obraz doświadczeń użytkownika.
• Spójność wizualnych etykiet z nazwami dostępnymi: Upewnij się, że tekst, który jest widoczny na ekranie, jest taki sam lub bardzo podobny do programowo dostępnej nazwy (np. aria-label). Rozbieżności mogą dezorientować użytkowników z dysleksją lub osoby używające oprogramowania do rozpoznawania mowy.
• Dynamiczne aktualizacje ARIA: Jeśli stan komponentu się zmienia (np. menu rozwija się, checkbox jest zaznaczany), upewnij się, że odpowiednie atrybuty ARIA (np. aria-expanded, aria-checked) są również aktualizowane za pomocą JavaScriptu.

Typowe pułapki:

• Brak etykiet dla pól formularzy: Jedna z najczęstszych usterek dostępności. Zawsze powiązuj <label> z <input> lub używaj aria-label/aria-labelledby.
• Opieranie się na placeholder jako etykiecie: Tekst zastępczy znika po rozpoczęciu wpisywania i nie jest poprawnie obsługiwany jako etykieta przez wszystkie technologie wspomagające.
• Brak tekstu alternatywnego dla znaczących obrazów: Pozostawianie pustego alt="" dla obrazów niosących treść lub całkowite pomijanie atrybutu alt.
• Tworzenie interaktywnych elementów za pomocą <div>/<span> bez ARIA i obsługi klawiatury: Przykładowo, tworzenie „przycisku” za pomocą <div onclick="..."> bez role="button", tabindex="0" i obsługi zdarzeń klawiatury (Enter/Space).
• Nadmierne lub nieprawidłowe użycie ARIA: Stosowanie atrybutów ARIA, gdy nie są one potrzebne (np. role="button" na natywnym <button>) lub używanie ich w sposób niezgodny ze specyfikacją, co może pogorszyć dostępność (tzw. „No ARIA is better than bad ARIA”).
• Niedostępne regiony aktualizacji (ARIA live regions): Ważne komunikaty i dynamicznie zmieniająca się treść powinny być ogłaszane technologiom wspomagającym za pomocą ARIA live regions (np. <div role="status" aria-live="polite">) w odpowiednich scenariuszach.

Podsumowanie

Kryterium 4.1.2 „Nazwa, rola, wartość” jest fundamentalne dla stworzenia dostępnego interfejsu użytkownika. Zapewnia, że wszystkie komponenty UI są zrozumiałe i obsługiwane przez technologie wspomagające, umożliwiając pełną interakcję z treścią witryny. Staranne przestrzeganie tych wytycznych, z naciskiem na semantyczny HTML i przemyślane użycie ARIA, jest niezbędne do zapewnienia inkluzywnego doświadczenia dla wszystkich użytkowników.