WCAG 4.1.2 Nazwa, rola, wartość
Zaktualizowano 14 października 2026 · 3 min czytania
- Poziom
- A · WCAG 2.0
- EN 301 549
- 9.4.1.2
- Co sprawdza checker
- Częściowo automatycznie: Klikalne obszary obrazka nie mają opisu, Atrybuty dostępności użyte w niewłaściwych elementach, Niektóre elementy mają etykietę dla brajla, ale nie mają zwykłej nazwy, Niestandardowe przyciski nie mają nazwy, Atrybuty dostępności użyto w niewłaściwej sytuacji, Niektóre elementy używają przestarzałych ról dostępności, Cała strona jest ukryta przed czytnikami ekranu, Ukryte elementy nadal są dostępne z klawiatury, Niestandardowe pola formularza nie mają etykiety, Niektóre etykiety są tam, gdzie czytniki ekranu je pomijają, Niestandardowym kontrolkom brakuje wymaganych informacji, Niektóre elementy mają rolę, która nie istnieje, Niektóre przełączniki i pola wyboru nie mają nazwy, Niektóre podpowiedzi są puste, Atrybuty dostępności zawierają literówki, Atrybuty dostępności mają nieprawidłowe wartości, Niektóre przyciski nie mają nazwy, Niektóre etykiety wskazują niewłaściwy element, Osadzona treść nie ma nazwy, Kilka osadzonych ramek ma tę samą nazwę, Niektóre przyciski formularzy nie mają nazwy, Przycisk graficzny nie ma opisu tekstowego, Pola formularza nie mają etykiet, Niektóre linki nie mówią, dokąd prowadzą, Klikalne elementy są zagnieżdżone jeden w drugim, Lista rozwijana nie ma etykiety, Niektóre rozwijane sekcje nie mają nazwy
- Oficjalny tekst
- Understanding 4.1.2 Name, Role, Value (W3C, po angielsku)
Kryterium sukcesu 4.1.2 sprawia, że czytniki ekranu, sterowanie głosowe i inne technologie wspomagające mogą zrozumieć i obsłużyć każdy element sterujący na stronie. Użytkownik czytnika ekranu słyszy „przycisk, Dodaj do koszyka”; użytkownik sterowania głosowego mówi „kliknij Dodaj do koszyka”. Jeśli kontrolka nie ma nazwy, ma złą rolę albo stan, który nigdy się nie aktualizuje, ci użytkownicy nie mogą robić zakupów. To poziom A; w normie EN 301 549 kryterium to występuje jako punkt 9.4.1.2.
Czego wymaga kryterium
Dla wszystkich komponentów interfejsu użytkownika — między innymi elementów formularzy, linków i komponentów generowanych przez skrypty:
- nazwa i rola mogą być określone programowo;
- stany, właściwości i wartości, które może ustawiać użytkownik, mogą być ustawiane programowo;
- powiadomienia o zmianach tych elementów są dostępne dla programów użytkownika, w tym technologii wspomagających.
W3C zaznacza, że kryterium dotyczy głównie autorów, którzy budują lub oskryptowują własne komponenty. Standardowe kontrolki HTML używane zgodnie ze specyfikacją już je spełniają. Własne widżety — menu, karty, akordeony, suwaki, własne listy rozwijane — potrzebują ról i stanów nadanych przez ARIA, a te stany muszą się zmieniać wraz ze zmianą widżetu.
Typowe błędy w sklepie internetowym
- przyciski z samą ikoną (koszyk, wyszukiwanie, zamknij, serduszko listy życzeń) bez tekstu i bez
aria-label; - linki ze zdjęciem produktu, którego obraz nie ma tekstu alternatywnego, więc link nie ma nazwy;
- wybór rozmiaru lub koloru zbudowany z elementów
divz obsługą kliknięć, bez roli i bez stanu zaznaczenia; - przycisk menu mobilnego, którego
aria-expandedpozostaje „false”, gdy menu jest otwarte; - pola formularzy bez etykiety albo element select bez nazwy;
- elementy ukryte przez
aria-hidden="true", które nadal otrzymują fokus klawiatury; - ramki iframe z wideo, mapą lub płatnością bez atrybutu
title; - atrybuty ARIA z literówkami, niedozwolone dla danej roli lub z nieprawidłowymi wartościami.
Jak to sprawdzić
Automatycznie: nasz skaner stosuje dla tego kryterium wiele reguł, m.in. button-name, link-name, label, select-name, input-button-name, frame-title, aria-hidden-focus, nested-interactive, aria-required-attr, aria-valid-attr-value i pozostałe reguły ARIA (zob. listę reguł). Każdy błędny element zgłasza wraz z selektorem. Nie oceni, czy nazwa ma sens ani czy stany aktualizują się podczas korzystania z kontrolki.
Ręcznie: należy użyć czytnika ekranu (NVDA w Windows, VoiceOver w macOS lub iOS) i przejść przez nagłówek, stronę produktu i proces zamówienia. Przy każdym elemencie sterującym sprawdzić, czy słychać sensowną nazwę, właściwą rolę i bieżący stan. Otworzyć i zamknąć menu, akordeony i wybór wariantów i sprawdzić, czy zmiany stanu są ogłaszane.
Jak to naprawić
- Używać elementów natywnych:
<button>do akcji,<a href>do linków,<input>,<select>z<label>. - Nadać kontrolkom z samą ikoną nazwę dostępną — tekstem ukrytym wizualnie lub przez
aria-label. - Przy własnych widżetach stosować wzorce ARIA Authoring Practices i aktualizować
aria-expanded,aria-checked,aria-selectedrazem z interfejsem. - Nigdy nie umieszczać elementów przyjmujących fokus w treści z
aria-hidden; nadać każdej ramce iframe atrybuttitle.
Powiązane kryteria
- 1.1.1 Treść nietekstowa — teksty alternatywne dla obrazów.
- 2.5.3 Etykieta w nazwie — nazwa dostępna zawiera widoczną etykietę.
- 3.3.2 Etykiety lub instrukcje — widoczne etykiety pól formularza.
Najczęstsze pytania
Co oznacza nazwa, rola, wartość?
Nazwa to sposób, w jaki element sterujący się nazywa („Dodaj do koszyka”), rola to rodzaj elementu (przycisk, link, pole wyboru), a wartość lub stan to jego bieżące ustawienie (zaznaczony, rozwinięty, 3 produkty). Technologie wspomagające potrzebują wszystkich trzech.
Czy standardowe elementy HTML spełniają 4.1.2?
Tak, jeśli są używane zgodnie ze specyfikacją. Prawdziwy przycisk, link, pole input lub select z etykietą przekazuje nazwę, rolę i wartość. Problemy zwykle wynikają z własnych kontrolek zbudowanych z elementów div i span.
Czy automatyczne narzędzie znajdzie problemy z 4.1.2?
Znajduje wiele z nich: przyciski i linki bez nazwy, pola formularzy bez etykiety, nieprawidłowe lub brakujące atrybuty ARIA, ukryte elementy, które wciąż mogą otrzymać fokus. Nie oceni, czy nazwa ma sens ani czy stany poprawnie się aktualizują podczas korzystania z kontrolki.
Czy dodanie ARIA zawsze rozwiązuje problem?
Nie. Natywny element HTML jest zwykle solidniejszy niż ARIA dodana do elementu div. Błędna ARIA może sprawić, że kontrolka działa gorzej niż bez ARIA w ogóle.