- Poziom
- A
- Od wersji
- WCAG 2.0
- Pozycje
- 128 / 193
4.1.2 Nazwa, rola, wartość
Każda kontrolka potrzebuje nazwy i roli w kodzie strony, inaczej technologia wspomagająca nie powie, czym jest.
/ Czego wymaga
Technologia wspomagająca nie patrzy na ekran. Pyta przeglądarkę, jak nazywa się każda kontrolka, jakiego jest rodzaju i w jakim jest stanie. Kryterium wymaga, żeby wszystkie trzy informacje były dostępne w kodzie dla każdego komponentu interfejsu: nazwa, rola oraz każdy stan i wartość, które użytkownik może zmienić, przy czym zmiany mają być zgłaszane na bieżąco. Bez nich czytnik ekranu mówi „przycisk” i nic więcej albo nie mówi nic, a sterowanie głosem nie potrafi wskazać kontrolki.
Natywne kontrolki HTML użyte zgodnie ze specyfikacją spełniają to domyślnie: element button z tekstem, pole input z etykietą, link z treścią. Kryterium daje o sobie znać przy tym, co autorzy budują sami, czyli przy elemencie div reagującym na kliknięcia, własnej liście rozwijanej albo akordeonie. Takie elementy potrzebują roli, nazwy dostępnej i atrybutów stanu, na przykład aria-expanded lub aria-checked, które skrypt na bieżąco aktualizuje. Kryterium nie wymienia żadnych wyjątków. Kontrolka, która działa myszą, a nie ma jej w drzewie dostępności, nie spełnia wymogu.
/ Jak strony go nie spełniają
- Przycisk zawiera samą ikonę i nie ma tekstu, atrybutu aria-label ani title.
- Element div lub span z obsługą kliknięcia działa jak przycisk i nie ma żadnej roli.
- Pole tekstowe nie ma elementu label, atrybutu aria-label ani aria-labelledby.
- Akordeon albo przycisk menu otwiera się i zamyka, a atrybut aria-expanded nigdy się nie zmienia.
- Atrybut aria-labelledby podaje id, którego nie ma na stronie, więc wyliczona nazwa jest pusta.
/ Jak sprawdzić samodzielnie
- Przejdź przez stronę tabulatorem z włączonym darmowym czytnikiem ekranu, na przykład NVDA. Przy każdym zatrzymaniu fokusu powinno być słychać nazwę, rolę i tam, gdzie to ma zastosowanie, stan.
- Zbadaj każdą kontrolkę w panelu Accessibility narzędzi deweloperskich przeglądarki i odczytaj jej nazwę (Name), rolę (Role) i właściwości stanu.
- Użyj każdego własnego widżetu: otwórz akordeon, przestaw przełącznik, wybierz opcję. Sprawdź, czy stan pokazany w drzewie dostępności zmienia się razem z nim.
- Uruchom darmowe rozszerzenie przeglądarki, takie jak axe DevTools lub WAVE, żeby wypisać kontrolki bez nazwy, a potem potwierdź jego wyniki ręcznie.
- Wyszukaj w źródle atrybuty aria-labelledby, aria-describedby i aria-controls i potwierdź, że każde wymienione w nich id istnieje.
/ Jak to naprawić
- Najpierw sięgaj po element natywny: button do akcji, a z atrybutem href do nawigacji oraz input, select i textarea do danych.
- Przyciski z ikonami nazwij atrybutem aria-label albo wizualnie ukrytym tekstem wewnątrz przycisku, a każdemu elementowi iframe daj atrybut title.
- Połącz każde pole z elementem label za pomocą atrybutów for i id albo użyj aria-labelledby tam, gdzie widoczny tekst już pełni rolę etykiety.
- We własnych widżetach ustaw rolę i utrzymuj aria-expanded, aria-checked lub aria-selected w zgodzie z tym, co widżet pokazuje, w tym samym skrypcie, który go zmienia.
- Nie nadawaj aria-hidden="true" niczemu, co zawiera elementy przyjmujące fokus, a otwartemu oknu dialogowemu daj aria-modal="true" i nazwę.
/ Co sprawdza nasz skaner
Analiza statyczna liczy pola bez aria-label, aria-labelledby, title ani pasującego label for. Na wyrenderowanej stronie nasze reguły zgłaszają puste nazwy dostępne, odwołania ARIA do nieistniejących id, fokus wewnątrz aria-hidden, iframe bez tytułu oraz okna dialogowe, pola kombi i akordeony bez atrybutów stanu. axe i HTML_CodeSniffer dodają przyciski, linki i pola bez nazwy oraz niepoprawne wartości ARIA. Nic nie obsługuje widżetów, więc zmiany stanu pozostają niesprawdzone.
/ Kto je łamie, według naszych pomiarów
Jedna strona na podmiot, mierzona automatycznie w tygodniowym cyklu. Jeśli podmiot coś naprawił od ostatniego pomiaru, zmiana będzie widoczna przy następnym, a każdy podmiot może odpowiedzieć na swojej stronie.
/ Pytania o to kryterium
Co to jest nazwa dostępna?
To tekst, który przeglądarka udostępnia technologii wspomagającej jako nazwę elementu. Przeglądarka wylicza ją w ustalonej kolejności: najpierw aria-labelledby, potem aria-label, potem źródło natywne, czyli element label, atrybut alt albo tekst wewnątrz przycisku lub linku, a na końcu atrybut title. Czytnik ekranu odczytuje ją razem z rolą, na przykład „Szukaj, przycisk”.
Czy do spełnienia kryterium Nazwa, rola, wartość potrzebuję ARIA?
Często nie. Natywne elementy HTML mają już rolę, biorą nazwę ze swojej treści lub etykiety i same zgłaszają swój stan. ARIA jest potrzebna, gdy budujesz kontrolkę, której HTML nie oferuje, albo gdy natywna kontrolka nie ma widocznego tekstu, który mógłby ją nazwać. ARIA na elemencie, który nie zachowuje się jak rola, którą deklaruje, pogarsza sprawę.
Dlaczego czytnik ekranu mówi na mojej stronie tylko „przycisk”?
Bo przycisk ma rolę, a nie ma nazwy dostępnej. Najczęstsza przyczyna to przycisk z ikoną: svg albo obraz w tle wewnątrz elementu button bez tekstu. Dodaj aria-label mówiący, co przycisk robi, albo umieść w nim wizualnie ukryty tekst. Jeśli ikona jest elementem img, daj jej tekst alternatywny, który stanie się wtedy nazwą przycisku.