4.1.2 Nazwa, rola, wartość (ang.) Name, role, value

Specjalizacje:

Content Creator
Deweloper

Elementy:

Dialogi i warstwy
Formularze
Nawigacja
Przyciski i kontrolki

Poziomy:

Spis treści

Istota i cel kryterium

Zrozumienie tego kryterium to absolutny fundament tworzenia dostępnych, interaktywnych stron internetowych. To kryterium zapewnienia, że każdy element interfejsu użytkownika – od prostego przycisku po najbardziej skomplikowane, niestandardowe widżety – potrafi bezbłędnie komunikować się z technologiami wspomagającymi.

Gdy użytkownik korzysta z czytnika ekranu lub sterowania głosowego, oprogramowanie to musi precyzyjnie odczytać cyfrową strukturę strony. Aby to osiągnąć, każdy element strony musi posiadać programowo określoną:

Nazwę ((ang.) accessible name): Unikalną etykietę tekstową, która jednoznacznie identyfikuje dany element i informuje, do czego on służy.
Rolę ((ang.) role): Definicję typu komponentu (np. przycisk, pole edycji, link, pole wyboru), która natychmiast podpowiada użytkownikowi, jakich interakcji może się spodziewać.
Wartość lub stan ((ang.) value/state): Aktualną kondycję elementu (np. czy pole jest zaznaczone, czy menu zostało rozwinięte) lub wprowadzone do niego dane.

Pamiętaj, że wszelkie modyfikacje tych właściwości muszą być dynamicznie aktualizowane i programowo przekazywane do (ang.) Accessibility API przeglądarki, która czerpie te dane bezpośrednio z drzewa dostępności ((ang.) Accessibility Tree) wygenerowanego na podstawie struktury DOM. Jeśli powstanie tutaj zaniedbanie kod stanie się dla technologii asystujących całkowicie niewidoczny, odcinając użytkowników od podstawowych funkcji serwisu.

Definicja w j. angielskim

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

Definicja w j. polskim

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

Drzewo dostępności (ang.) accessibility tree: –
specjalna struktura generowana przez przeglądarkę na podstawie kodu DOM, zawierająca wyłącznie informacje niezbędne dla prawidłowego działania technologii wspomagających.

Dostępna nazwa (ang.) accessible name: –
programowa etykieta elementu, która informuje użytkownika o celu danego obiektu; może pochodzić z jego bezpośredniej treści, atrybutu lub powiązanej etykiety tekstowej.

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

Użytkowników niewidomych oraz słabowidzących: Osoby te całkowicie polegają na czytnikach ekranu. Gdy komponent nie ma nazwy lub roli, syntezator mowy odczyta jedynie enigmatyczne „przycisk” lub „nieoznakowany element”, zamieniając poruszanie się po stronie w błądzenie po omacku.
Użytkowników z niepełnosprawnością ruchową i sterujących głosem: Osoby wydające komendy głosowe (np. „kliknij przycisk Wyślij”) muszą mieć pewność, że programowa nazwa komponentu pokrywa się z tekstem widocznym na ekranie. Brak tej spójności całkowicie uniemożliwia im aktywację elementów i nawigację.
Użytkowników z zaburzeniami poznawczymi: Precyzyjne określenie ról i stanów eliminuje chaos informacyjny. Jasna, spójna i przewidywalna informacja o zachowaniu interfejsu drastycznie zmniejsza zmęczenie psychiczne i eliminuje frustrację.
Użytkowników korzystających wyłącznie z klawiatury: Poprawne właściwości programowe determinują stabilne zarządzanie fokusem i pozwalają użytkownikowi natychmiast zorientować się, który element interfejsu jest w danej chwili aktywny.

Zasady wdrażania i wymagania techniczne

Aby wdrożyć to kryterium w sposób bezbłędny i unikalny, podziel proces implementacji na cztery fundamentalne kroki techniczne.

Krok 1: Wykorzystaj fundamenty, czyli regułę (ang.) „HTML First”

Zanim zaczniesz pisać skomplikowane skrypty lub dodawać atrybuty ARIA, wykorzystaj pełen potencjał semantycznego kodu HTML. To najprostsza i najbezpieczniejsza droga do sukcesu.

Zastosuj natywne znaczniki, takie jak <button>, <a href>, <input> czy <select>. Wybierając je, automatycznie i bez żadnego dodatkowego wysiłku przekazujesz przeglądarce informację o roli elementu oraz jego domyślnych stanach.

Pamiętaj o złotej zasadzie dostępności: najlepsze ARIA to brak ARIA. Używaj niestandardowych rozwiązań opartych na znacznikach <div> i <span> tylko wtedy, gdy natywny HTML absolutnie nie pozwala na uzyskanie pożądanego efektu wizualnego lub funkcjonalnego.

Krok 2: Zaprogramuj niezbywalną tożsamość (dostępna nazwa)

Technologia wspomagająca musi wiedzieć, jak dany element nazwać, aby użytkownik bezwzrokowy precyzyjnie rozumiał, do czego on służy. Stworzenie dostępnej nazwy to kluczowy obowiązek.

W przypadku pól formularzy zawsze stosuj jawne, programowe powiązanie etykiety z polem za pomocą pary atrybutów for i id. Tekst ukryty w atrybucie placeholder nigdy nie zastąpi prawdziwej etykiety – znika on podczas pisania i jest ignorowany przez wiele czytników ekranu.

Jeśli budujesz element czysto graficzny (np. przycisk z samą ikoną koszyka), nadaj mu unikalną nazwę tekstową. Możesz to zrobić za pomocą atrybutu aria-label="Usuń produkt z koszyka" lub wskazać istniejący na stronie opis tekstowy poprzez aria-labelledby.

Krok 3: Ręczna deklaracja roli w komponentach typu (ang.) „Custom UI”

Jeżeli sytuacja zmusiła Cię do stworzenia niestandardowego komponentu (np. rozwijanego drzewa kategorii opartego na listach <ul> i <li>), musisz ręcznie nadać mu odpowiednie znaczenie w drzewie dostępności.

Użyj precyzyjnie dobranych ról ARIA (np. role="tablist", role="tab", role="dialog"), aby oszukać czytnik ekranu i zmusić go do traktowania zwykłego kontenera jak zaawansowanej kontrolki systemowej.

Pamiętaj jednak, że sama deklaracja roli to tylko obietnica. Nadając role="button" dla elementu <div>, musisz samodzielnie dopisać obsługę klawiatury (zdarzenia keydown dla klawiszy Enter i Spacja) oraz zarządzać fokusem za pomocą parametru tabindex="0".

Krok 4: Dynamiczne zarządzanie cyklem życia stanu i wartości

Komponenty żyją i zmieniają się pod wpływem interakcji użytkownika. Kryterium 4.1.2 kategorycznie wymaga, aby te zmiany były natychmiast rejestrowane przez technologie asystujące.

Napisz kod JavaScript w taki sposób, aby każda zmiana wizualna (np. otwarcie menu, zaznaczenie checkboxa) szła w parze z natychmiastową aktualizacją atrybutów stanu w kodzie HTML.

Jeśli menu się rozwija, przełącz stan aria-expanded="false" na true. Jeśli użytkownik zaznacza niestandardowy kafelek wyboru, zaktualizuj aria-checked lub aria-selected. Gdy wartość w zaawansowanym suwaku ulega zmianie, dynamicznie modyfikuj atrybuty aria-valuenow, aria-valuemin oraz aria-valuemax.

Wyjątki i sytuacje szczególne

Kryterium 4.1.2 ma charakter bezkompromisowy i dotyczy bezwzględnie wszystkich interaktywnych komponentów interfejsu użytkownika.

Jedynym formalnym odstępstwem od reguły pełnego opisu są elementy o charakterze czysto dekoracyjnym (np. grafiki tła lub ikony powielające treść znajdującą się obok), które intencjonalnie ukrywamy przed technologiami wspomagającymi za pomocą pustego atrybutu alt="" lub usuwamy z drzewa dostępności, aby nie generować szumu informacyjnego.

Pamiętaj również o żelaznej zasadzie: jeśli stosujesz w pełni natywne, semantyczne elementy HTML, nie musisz dublować ich roli za pomocą atrybutów ARIA (np. dopisywanie role="button" do elementu <button>), ponieważ przeglądarka robi to automatycznie.

Przykłady implementacji

Najczęstsze błędy

F59 i F15: Nie twórz „atrap” komponentów z <div> lub <span> – unikaj używania skryptów do przekształcania elementów <div> lub <span> w kontrolki interfejsu użytkownika bez nadania im odpowiedniej roli. Nie dopuszczaj do sytuacji, w której wdrażasz niestandardowe komponenty nieskomunikowane z systemowym (ang.) accessibility API. Taki kod staje się dla technologii asystujących całkowicie niewidoczny, co zamienia nawigację w chaotyczną i losową.
F68 i F111: Nie porzucaj kontrolek bez programowej nazwy dostępnej – zgłoś absolutne weto wobec praktyki, w której element interfejsu nie posiada programowo określonej nazwy. Unikaj tworzenia pól, które posiadają wyłącznie wizualną etykietę tekstową, ale brakuje im (ang.) accessible name w kodzie. Pamiętaj, że dla użytkownika czytnika ekranu takie pole jest całkowicie anonimowe i uniemożliwia jakąkolwiek interakcję.
F42: Kategorycznie unikaj emulowania linków – nigdy nie zastępuj natywnego znacznika <a> innymi elementami, próbując udawać link za pomocą skryptów. To najpoważniejsze uchybienie, które odcina użytkowników od standardowej nawigacji klawiaturowej i fałszuje strukturę strony przekazywaną drzewa dostępności.
F89: Wyeliminuj „ślepe” linki ikonowe – unikaj pozostawiania obrazu bez dostępnej nazwy, jeśli stanowi on jedyną zawartość linku. Nie dopuszczaj do sytuacji, w której ikona wewnątrz odnośnika ma pusty atrybut alt="" lub role="presentation". Taki brak nazwy sprawia, że kolorystyka i cel elementu zlewają się z tłem, a syntezator mowy odczyta jedynie surowy, niezrozumiały adres URL.
F86: Nigdy nie ignoruj poszczególnych części pól wieloczęściowych– zadbaj o to, aby każda pojedyncza sekcja formularza składającego się z wielu części posiadała własną, niezależną nazwę. Unikaj podpisywania wyłącznie całego bloku (np. numeru telefonu rozbitego na kilka okienek). Pamiętaj, że użytkownik przeskakujący tabulatorem musi w każdym momencie precyzyjnie wiedzieć, gdzie się znajduje.
F20: Zadbaj o natychmiastową aktualizację tekstów alternatywnych – unikaj zamrażania opisów tekstowych, gdy za pomocą skryptów zmieniasz treść nietekstową. Jeśli dynamicznie modyfikujesz wykres, ikonę lub grafikę, natychmiast zaktualizuj jej alternatywę tekstową. Brak synchronizacji wprowadza potężny chaos informacyjny i serwuje użytkownikom nieaktualne dane.
F79: Nie ukrywaj stanu fokusu i jego zmian – zadbaj o to, aby stan skupienia fokus każdego komponentu był zawsze programowo determinowalny. Unikaj blokowania powiadomień o zmianie stanu fokus. Jeśli system asystujący nie otrzyma informacji o ruchu kursora, użytkownik całkowicie straci orientację w przestrzeni interfejsu.

Najlepsze praktyki

Dbaj o absolutną spójność etykiet wizualnych z nazwą dostępną: Zadbaj o to, by tekst widoczny na ekranie był identyczny lub bardzo zbliżony do nazwy zaprogramowanej w aria-label. Zapobiegniesz w ten sposób dezorientacji osób z dysleksją oraz użytkowników sterujących interfejsem za pomocą komend głosowych.
Wdrażaj regularne testy z czytnikami ekranu: Poddawaj swoje projekty bezkompromisowej weryfikacji przy użyciu realnego oprogramowania asystującego (np. NVDA, VoiceOver czy JAWS). To jedyna droga do uzyskania pełnego obrazu doświadczeń użytkownika.
Płynnie i dynamicznie aktualizuj stan komponentów: Upewnij się, że każdy skrypt JavaScript modyfikujący stan elementu (np. otwieranie menu, zaznaczanie checkboxa) natychmiast aktualizuje adekwatne atrybuty, takie jak aria-expanded czy aria-checked.
Traktuj ARIA wyłącznie jako precyzyjne uzupełnienie: Wykorzystuj architekturę ARIA ze skrajną rozwagą i wyłącznie w sytuacjach, w których czysty, natywny HTML nie oferuje gotowych rozwiązań semantycznych.
Kultywuj pierwszeństwo dla HTML semantycznego: Wybieraj natywne tagi, dające najbardziej solidną, stabilną i przewidywalną podstawę dostępności cyfrowej.

Metody testowania

Narzędzie deweloperskie (ang.) Developer Tools: Zbadaj strukturę drzewa DOM oraz dedykowaną zakładkę dostępności ((ang.) Accessibility). Upewnij się, czy elementy identyfikowane wizualnie posiadają wyliczoną poprawną nazwę dostępną ((ang.) accessible name), rolę oraz stany dynamiczne, i czy nie są puste.
NVDA: Uruchom czytnik ekranu i przetestuj kompletną nawigację klawiaturową. Zweryfikuj, czy po przejściu do danej sekcji, pola formularza lub przycisku otrzymujesz bez patrzenia na monitor wszystkie niezbędne i zrozumiałe instrukcje oraz informacje o ich stanach.
(ang.) WAVE Evaluation Tool: Wykorzystaj to narzędzie do automatycznego wykrywania błędów w strukturze formularzy, braku powiązań między komunikatami a polami edycyjnymi oraz nieobecności tekstów alternatywnych.
(ang.) IBM Equal Access Toolkit: Przeprowadź audyt automatyczny, aby sprawdzić, czy dynamiczne zmiany w interfejsie (np. pojawienie się nowego komunikatu czy zmiana stanu suwaka) są poprawnie odnotowywane i przekazywane technologiom wspomagającym.
ANDI.JS: Wybierz moduł odpowiedzialny za elementy interaktywne lub graficzne, aby precyzyjnie podejrzeć, co dokładnie „widzi” technologia asystująca. Narzędzie podświetli komponenty i wyświetli tekst zastępczy oraz rolę, ułatwiając natychmiastową weryfikację kontekstu.

Sprawdź swoją wiedzę

W linku poniżej znajduje się 6 interaktywnych przykładów. Oceń, czy każdy komponent poprawnie komunikuje technologiom wspomagającym swoją nazwę (accessible name), rolę oraz stan/wartość.

Jak to sprawdzić?

Sprawdź w DevTools (zakładka Accessibility), czy element ma wyliczoną nazwę, rolę i stany.
Przejdź Tab – czy fokus dociera do kontrolki? Czy Enter/Spacja ją aktywują?
Po interakcji sprawdź, czy stan (np. rozwinięte/zwinięte, włączone/wyłączone) jest aktualizowany w DOM (np. aria-expanded, aria-checked).
Dla pól formularza zweryfikuj powiązanie etykiety (for/id lub aria-label).

Notatka: Zanim zajrzysz do rozwiązania, przetestuj i zapisz swoje wnioski na kartce.
Proponowane narzędzia: Klawiatura (Tab, Shift + Tab, Spacja, Enter ), Myszka, Narzędzie deweloperskie (ang.) Developer Tools, NVDA, ANDI.js

Link: https://pdc.ambiscale.com/training/wcag-4-1-2/

#1 BŁĄD

Problem: Przełącznik to zwykły <div> bez roli, nazwy i stanu – działa tylko wizualnie po kliknięciu myszą.
Dlaczego: Techniki F59 i F15 – skrypt czyni z div/span kontrolkę UI bez roli i bez pełnej komunikacji z (ang.) Accessibility API. Czytnik nie ogłasza „przełącznik” ani „włączone/wyłączone”; brak też natywnego fokusu klawiatury.
Naprawa: Preferuj <input type="checkbox" role="switch"> z <label>, albo custom z role="switch", tabindex="0", aria-checked oraz obsługą Spacji/Enter.

#2 BŁĄD

Problem: Widoczny tekst „E-mail:” to luźny <span> – pole nie ma programowo określonej nazwy dostępnej.
Dlaczego: Techniki F68 i F111 – kontrolka ma etykietę wizualną, ale brak powiązania w kodzie (for/id, aria-labelledby lub aria-label). Dla czytnika pole jest anonimowe.
Naprawa: Użyj <label for="tc2-email">E-mail:</label> (albo owiń input w <label>). Placeholder nie zastępuje nazwy dostępnej.

#3 BŁĄD

Problem: „Link” to <span> ze stylem podkreślenia i obsługą kliknięcia – nie jest odnośnikiem w drzewie dostępności.
Dlaczego: Technika F42 – emulowanie linków bez semantyki <a href>. Brak roli linku; nawigacja klawiaturowa i oczekiwane zachowanie odnośnika zawodzą.
Naprawa: Zastąp elementem <a href="...">regulaminu sklepu</a>. Nie udawaj linku skryptem na span/div.

#4 BŁĄD

Problem: Jedyną zawartością linku jest obraz z pustym alt="" – link nie ma dostępnej nazwy.
Dlaczego: Technika F89 – obraz będący jedyną treścią linku bez dostępnej nazwy. Czytnik może ogłosić tylko „link” lub surowy URL.
Naprawa: Nadaj sensowny alt (np. „Profil użytkownika”), tekst w linku, albo aria-label na <a>. Pusty alt jest dobry tylko dla dekoracji, nie dla jedynej treści interaktywnego elementu.

#5 BŁĄD

Problem: Jedna etykieta wizualna obejmuje trzy osobne pola, ale żadne z nich nie ma własnej nazwy programowej.
Dlaczego: Technika F86 – brak nazw dla poszczególnych części pola wieloczęściowego (np. numer telefonu). Przy Tab użytkownik nie wie, który segment edytuje.
Naprawa: Nadaj każdej części nazwę, np. aria-label="Numer telefonu – pierwsze 3 cyfry" (i analogicznie dla pozostałych), albo użyj jednego pola z jedną etykietą.

#6 DOBRZE

Dlaczego: Natywny <button> dostarcza rolę „przycisk” i nazwę z treści („Szczegóły oferty”). Stan jest dynamicznie aktualizowany przez aria-expanded, a panel powiązany przez aria-controls / aria-labelledby. Spełnia wymagania nazwy, roli i wartości/stanu z SC 4.1.2.

Źródła

Abou-Zahra S., Eggert E., Vanderheiden G. [i in.] (red.), „4.1.2 Name, Role, Value Level A”, [w:] Web Content Accessibility Guidelines (WCAG) 2.2 Quick Reference, 2025, https://www.w3.org/WAI/WCAG22/quickref/#name-role-value [dostęp: 02.06.2026].
Accessibility Guidelines Working Group Participants, „Understanding SC 4.1.2 Name, Role, Value (Level A)”, [w:] WCAG 2.2 Understanding Docs, 2026, https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html [dostęp: 02.06.2026].
Accessibility Guidelines Working Group Participants, „Technique F59: Failure of Success Criterion 4.1.2 due to using script to make div or span a user interface control in HTML without providing a role for the control”, [w:] Techniques for WCAG 2.2, 2026, https://www.w3.org/WAI/WCAG22/Techniques/failures/F59 [dostęp: 02.06.2026].
Accessibility Guidelines Working Group Participants, „Technique F15: Failure of Success Criterion 4.1.2 due to implementing custom controls that do not use an accessibility API for the technology, or do so incompletely”, [w:] Techniques for WCAG 2.2, 2025, https://www.w3.org/WAI/WCAG22/Techniques/failures/F15 [dostęp: 02.06.2026].
Accessibility Guidelines Working Group Participants, „Technique F68: Failure of Success Criterion 4.1.2 due to a user interface control not having a programmatically determined name”, [w:] Techniques for WCAG 2.2, 2026, https://www.w3.org/WAI/WCAG22/Techniques/failures/F68 [dostęp: 02.06.2026].
Accessibility Guidelines Working Group Participants, „Technique F111: Failure of Success Criteria 1.3.1, 2.5.3, and 4.1.2 due to a control with visible label text but no accessible name”, [w:] Techniques for WCAG 2.2, 2025, https://www.w3.org/WAI/WCAG22/Techniques/failures/F111 [dostęp: 02.06.2026].
Accessibility Guidelines Working Group Participants, „Technique F42: Failure of Success Criteria 1.3.1, 2.1.1, 2.1.3, or 4.1.2 when emulating links”, [w:] Techniques for WCAG 2.2, 2026, https://www.w3.org/WAI/WCAG22/Techniques/failures/F42 [dostęp: 02.06.2026].
Accessibility Guidelines Working Group Participants, „Technique F89: Failure of Success Criteria 2.4.4, 2.4.9 and 4.1.2 due to not providing an accessible name for an image which is the only content in a link”, [w:] Techniques for WCAG 2.2, 2026, https://www.w3.org/WAI/WCAG22/Techniques/failures/F89 [dostęp: 02.06.2026].
Accessibility Guidelines Working Group Participants, „Technique F86: Failure of Success Criterion 4.1.2 due to not providing names for each part of a multi-part form field, such as a US telephone number”, [w:] Techniques for WCAG 2.2, 2026, https://www.w3.org/WAI/WCAG22/Techniques/failures/F86 [dostęp: 02.06.2026].
Accessibility Guidelines Working Group Participants, „Technique F20: Failure of Success Criterion 1.1.1 and 4.1.2 due to not updating text alternatives when changes to non-text content occur”, [w:] Techniques for WCAG 2.2, 2025, https://www.w3.org/WAI/WCAG22/Techniques/failures/F20 [dostęp: 02.06.2026].
Accessibility Guidelines Working Group Participants, „Technique F79: Failure of Success Criterion 4.1.2 due to the focus state of a user interface component not being programmatically determinable or no notification of change of focus state available”, [w:] Techniques for WCAG 2.2, 2025, https://www.w3.org/WAI/WCAG22/Techniques/failures/F79 [dostęp: 02.06.2026].
World Wide Web Consortium (W3C), „Kryterium sukcesu 4.1.2 Nazwa, rola, wartość”, [w:] Web Content Accessibility Guidelines (WCAG) 2.1, tłum. Fundacja Instytut Rozwoju Regionalnego, 2021, https://www.w3.org/Translations/WCAG21-pl/#nazwa-rola-wartosc [dostęp: 02.06.2026].
DOCK sp. z o.o., WCAG 4.1.2: Nazwa, rola, wartość, https://wcag.dock.codes/pl/dokumentacja/wcag-412/ [dostęp: 02.06.2026].

Dodatkowe linki

W3C WCAG:
- Dokładna definicja: https://www.w3.org/WAI/WCAG22/quickref/#name-role-value
- Zrozumienie podpunktu: https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html

Wróć do wszystkich kryteriów