WCAG 4.1.2: Nazwa, rola, wartość

WCAG 4.1.2 wymaga, aby wszystkie komponenty interfejsu użytkownika miały programowo określaną nazwę i rolę oraz aby stany, właściwości i wartości mogły być zarówno odczytywane, jak i ustawiane przez technologie asystujące. Zapewnia to, że czytniki ekranu i inne narzędzia mogą dokładnie identyfikować, opisywać i wchodzić w interakcję z każdym elementem na stronie.

Co Oznacza Ta Zasada

WCAG 4.1.2 — Nazwa, Rola, Wartość to kryterium sukcesu na poziomie A w ramach zasady Solidność (Robust). Wymaga ono, aby dla każdego komponentu interfejsu użytkownika — w tym elementów formularzy, przycisków, linków, niestandardowych widżetów, ramek (frames) i kontrolek interaktywnych — spełnione były następujące trzy warunki:

Nazwa: Każdy komponent musi mieć dostępną nazwę, którą technologie asystujące mogą odczytać na głos lub wyświetlić na monitorze brajlowskim. Nazwa może pochodzić z treści elementu (np. tekst wewnątrz <button>), elementu label, atrybutu aria-label, odwołania aria-labelledby lub atrybutu title.
Rola: Każdy komponent musi mieć rolę, która komunikuje jego przeznaczenie technologiom asystującym. Natywne elementy HTML mają role domyślne (implicit) (element <button> ma rolę button, a <input type='checkbox'> ma rolę checkbox). Niestandardowe widżety zbudowane z ogólnych elementów, takich jak <div> lub <span>, muszą jawnie deklarować rolę za pomocą atrybutu ARIA role.
Wartość (stany i właściwości): Każdy aktualny stan lub wartość istotna dla użytkownika — czy pole wyboru (checkbox) jest zaznaczone, czy widżet rozwijania jest rozwinięty, czy pole jest wymagane — musi być programowo ujawniony, aby technologie asystujące mogły go zgłaszać oraz aby użytkownicy mogli go zmieniać, gdy ma to zastosowanie.

Komponent spełnia to kryterium, gdy jego dostępna nazwa nie jest pusta, jego rola jest prawidłowa i semantycznie odpowiednia, a wszystkie istotne stany (takie jak aria-checked, aria-expanded lub aria-required) są poprawnie zastosowane i utrzymywane w synchronizacji z wizualnym interfejsem. Komponent nie spełnia kryterium, gdy którykolwiek z tych trzech elementów jest nieobecny, niepoprawny lub niespójny — na przykład niestandardowy przycisk przełączający, który zmienia kolor wizualnie, ale nigdy nie aktualizuje swojego stanu aria-pressed.

Oficjalny wyjątek WCAG dotyczy komponentów, które celowo nie są ujawniane interfejsom API dostępności — na przykład elementów czysto dekoracyjnych lub treści ukrytej za pomocą aria-hidden='true'. Jednak ukrywanie aktywnej lub fokusowalnej treści za pomocą aria-hidden (na przykład zastosowanie go do elementu <body>) samo w sobie stanowi naruszenie, ponieważ usuwa całą treść strony z drzewa dostępności.

Dlaczego To Jest Ważne

Według Światowej Organizacji Zdrowia około 2,2 miliarda osób na świecie ma pewną formę zaburzeń widzenia. Dla osób niewidomych i słabowidzących, które polegają na czytnikach ekranu, takich jak JAWS, NVDA czy VoiceOver, dostępna nazwa i rola każdego komponentu interaktywnego są podstawowym — i często jedynym — sposobem zrozumienia, do czego służy kontrolka i jak jej używać. Jeśli przycisk nie ma dostępnej nazwy, użytkownik czytnika ekranu słyszy jedynie „button”, bez wskazania jego przeznaczenia. Jeśli niestandardowa lista rozwijana nie ma roli, użytkownik nie może odróżnić jej od statycznego tekstu.

Użytkownicy z niepełnosprawnością ruchową, którzy obsługują oprogramowanie za pomocą przełączników (switch access), narzędzi sterowania głosem, takich jak Dragon NaturallySpeaking, lub nawigacji klawiaturą, również polegają na tym kryterium. Oprogramowanie sterowane głosem mapuje komendy mówione („kliknij Wyślij”) na dostępne nazwy. Jeśli dostępna nazwa przycisku nie odpowiada jego widocznej etykiecie, komendy głosowe całkowicie zawodzą.

Równie istotna jest dostępność poznawcza. Spójne, przewidywalne etykietowanie zmniejsza obciążenie poznawcze u użytkowników z dysleksją, zaburzeniami pamięci lub trudnościami z koncentracją. Gdy zmiany stanu — takie jak otwarcie okna modalnego lub oznaczenie pola formularza jako wymaganego — nie są ogłaszane przez technologie asystujące, użytkownicy mogą się dezorientować i nie być w stanie ukończyć zadań.

Rozważmy konkretny scenariusz z życia wzięty: turecka platforma e-commerce wyświetla przycisk „Dodaj do koszyka” zbudowany jako <div> z obsługą zdarzenia kliknięcia i ikoną koszyka. Wizualnie wygląda jak przycisk. Jednak ponieważ brakuje mu role='button', dostępnej nazwy i tabindex='0', użytkownik czytnika ekranu nawigujący za pomocą klawiatury nie napotyka niczego — element jest całkowicie niewidoczny dla jego technologii asystującej. Nie może dodać produktów do koszyka, co w praktyce wyklucza go z całego procesu zakupowego.

Poza dostępnością, poprawnie nazwane i zbudowane komponenty poprawiają SEO, ponieważ roboty wyszukiwarek polegają na semantycznym znacznikowaniu, aby zrozumieć strukturę strony i intencję interakcji. Poprawiają także testowalność, ponieważ zautomatyzowane frameworki testowe mogą bardziej niezawodnie lokalizować i obsługiwać elementy, które mają znaczące role i etykiety.

Powiązane Reguły Axe-core

Następujące reguły axe-core są bezpośrednio powiązane z WCAG 4.1.2. Każda z nich dotyczy konkretnej kategorii błędów związanych z nazwą, rolą lub wartością:

aria-allowed-attr: Sprawdza, czy atrybuty ARIA zastosowane do elementu są dozwolone dla roli tego elementu. Na przykład zastosowanie aria-checked do elementu z role='link' jest nieprawidłowe i zostanie oznaczone, ponieważ rola link nie obsługuje aria-checked.
aria-command-name: Zapewnia, że elementy z rolami poleceń ARIA (link, button, menuitem) mają niepustą dostępną nazwę. Przycisk zawierający wyłącznie ikonę, bez tekstu etykiety i bez aria-label, zostałby tu oznaczony.
aria-hidden-body: Oznacza konkretny przypadek, w którym aria-hidden='true' zostało zastosowane do elementu <body>, co usuwa całą stronę z drzewa dostępności i sprawia, że cała treść jest niewidoczna dla czytników ekranu.
aria-input-field-name: Sprawdza, czy elementy z rolami pól wejściowych ARIA (textbox, searchbox, spinbutton, slider, combobox) mają dostępną nazwę. Niestandardowe pole wyszukiwania zbudowane z role='textbox', ale bez etykiety, zostałoby oznaczone.
aria-meter-name: Weryfikuje, czy elementy z role='meter' mają dostępną nazwę, aby użytkownicy czytników ekranu rozumieli, jaką wielkość mierzy wskaźnik (na przykład wykorzystanie przestrzeni dyskowej lub poziom naładowania baterii).
aria-progressbar-name: Zapewnia, że elementy z role='progressbar' mają dostępną nazwę, aby użytkownicy wiedzieli, jaki proces lub operacja jest w toku, zamiast słyszeć jedynie „progress bar”.
aria-required-attr: Sprawdza, czy elementy używające danej roli ARIA zawierają wszystkie atrybuty wymagane przez specyfikację ARIA dla tej roli. Na przykład role='slider' wymaga aria-valuenow, aria-valuemin i aria-valuemax; pominięcie któregokolwiek z nich jest oznaczane.
aria-roles: Weryfikuje, czy wszystkie wartości przypisane do atrybutu role są prawidłowymi, nieabstrakcyjnymi rolami ARIA. Literówki, wymyślone role lub role abstrakcyjne (takie jak role='widget') użyte bezpośrednio na elementach są oznaczane.
aria-tooltip-name: Sprawdza, czy elementy z role='tooltip' mają dostępną nazwę. Pusty element podpowiedzi (tooltip) nie zapewnia żadnej wartości użytkownikom czytników ekranu i stanowi błąd etykietowania.
button-name: Weryfikuje, czy elementy <button> oraz elementy z role='button' mają niepustą dostępną nazwę. Wychwytuje to przyciski-ikony bez aria-label oraz puste przyciski używane jako dekoracyjne wyzwalacze.
frame-title: Wymaga, aby elementy <iframe> i <frame> miały niepusty atrybut title opisujący zawartość ramki. Bez niego użytkownicy czytników ekranu nie mogą określić celu osadzonej treści i mogą nie wiedzieć, czy powinni wejść do ramki, czy ją pominąć.
input-button-name: Sprawdza, czy elementy <input> typu submit, reset, button i image mają dostępną nazwę — albo poprzez atrybut value, albo, w przypadku pól typu image, atrybut alt.

Warto zauważyć, że choć narzędzia automatyczne wychwytują wiele błędów związanych z nazwą, rolą i wartością, niektóre naruszenia wymagają testów manualnych. Skanery automatyczne nie są w stanie zweryfikować, czy dostępna nazwa jest znacząca — przycisk oznaczony „kliknij tutaj” technicznie przechodzi automatyczną kontrolę posiadania nazwy, ale nie komunikuje faktycznego celu. Podobnie, to, czy zmiany stanu (takie jak przełączanie aria-expanded przy otwieraniu menu) są poprawnie ogłaszane podczas interakcji na żywo, można potwierdzić wyłącznie poprzez praktyczne testy z użyciem czytnika ekranu.

Jak Testować

Automatyczny skan za pomocą axe DevTools lub Lighthouse: Zainstaluj rozszerzenie przeglądarki axe DevTools (Chrome lub Firefox) lub uruchom audyt Lighthouse w Chrome DevTools w zakładce Accessibility. Uruchom skan całej strony i przefiltruj wyniki według tagu WCAG 4.1.2. Szukaj w szczególności naruszeń button-name, frame-title, aria-required-attr, aria-roles i aria-input-field-name. Każde znalezisko będzie zawierało problematyczny element, opis błędu i sugerowane rozwiązanie. Wyeksportuj wyniki i w pierwszej kolejności priorytetyzuj elementy o poziomie ważności Critical i Serious.
Test nawigacji klawiaturą: Odłącz mysz i nawiguj po całej stronie za pomocą klawisza Tab. Upewnij się, że każdy element fokusowalny otrzymuje widoczny fokus, że natywny wskaźnik fokusu przeglądarki (lub niestandardowy) jest wyraźnie widoczny oraz że możesz aktywować wszystkie kontrolki za pomocą Enter lub Spacji. Każdy element, do którego dotrzesz i którego nie możesz zidentyfikować wyłącznie na podstawie kontekstu — bez patrzenia na ekran — wskazuje prawdopodobny błąd dostępnej nazwy.
Testowanie z czytnikiem ekranu NVDA i Firefox: Uruchom NVDA (Windows, darmowy), otwórz Firefox i nawiguj po stronie za pomocą Tab, aby przechodzić między elementami interaktywnymi, oraz listy elementów NVDA (Insert+F7), aby przeglądać wszystkie przyciski, linki i pola formularzy. Dla każdego elementu interaktywnego słuchaj, co ogłasza NVDA. Powinien odczytać nazwę elementu, jego rolę i każdy istotny stan (np. „Subskrybuj, button” lub „Adres e-mail, wymagane, edit text”). Oznacz każdy element ogłaszany bez nazwy lub z nieprawidłową rolą.
Testowanie z czytnikiem ekranu VoiceOver i Safari (macOS/iOS): Włącz VoiceOver (Command+F5 na macOS), otwórz Safari i używaj VO+Strzałka w prawo, aby nawigować po elementach. Użyj Rotor VoiceOver (VO+U), aby wyświetlić listę wszystkich kontrolek formularzy i przycisków. Zweryfikuj, że nazwy są opisowe, role są odpowiednie, a stany są dynamicznie aktualizowane podczas interakcji (na przykład przełączanie niestandardowego akordeonu powinno powodować ogłoszenie „expanded” lub „collapsed”).
Testowanie z czytnikiem ekranu JAWS i Chrome: Uruchom JAWS i otwórz Chrome. Używaj klawisza Tab, aby nawigować po elementach interaktywnych, oraz wirtualnego kursora JAWS (Insert+F3, aby wyświetlić listę pól formularzy), aby przeglądać etykiety. Zwróć szczególną uwagę na niestandardowe widżety zbudowane z użyciem ARIA — potwierdź, że zmiany stanu wywoływane interakcją klawiaturą są odzwierciedlane w tym, co JAWS ogłasza w czasie rzeczywistym.
Weryfikacja stanów niestandardowych widżetów: Dla każdego niestandardowego widżetu (akordeon, panel kart, combobox, modal) w pełni z nim interaguj, używając wyłącznie klawiatury. Na każdym etapie weryfikuj, że czytnik ekranu ogłasza poprawną aktualizację stanu — na przykład otwarcie widżetu rozwijania powinno wywołać ogłoszenie „expanded”, a jego zamknięcie — „collapsed”. Jeśli stan wizualny się zmienia, ale czytnik ekranu milczy, oznacza to, że aria-expanded jest albo nieobecne, albo nie jest przełączane programowo.

Jak Naprawić

Przycisk zawierający wyłącznie ikonę, bez dostępnej nazwy — Niepoprawne

<!-- Icon button with no accessible name: screen readers announce only "button" -->
<button>
  <svg aria-hidden='true' focusable='false'>
    <use href='#icon-search'></use>
  </svg>
</button>

Przycisk zawierający wyłącznie ikonę, bez dostępnej nazwy — Poprawne

<!-- aria-label provides the accessible name when no visible text is present -->
<button aria-label='Search'>
  <svg aria-hidden='true' focusable='false'>
    <use href='#icon-search'></use>
  </svg>
</button>

Niestandardowy widżet przełącznika bez roli i stanu — Niepoprawne

<!-- A div used as a toggle: no role, no state, not keyboard accessible -->
<div class='toggle' onclick='toggleDarkMode()'>
  Dark Mode
</div>

Niestandardowy widżet przełącznika bez roli i stanu — Poprawne

<!-- role='switch' communicates purpose; aria-checked reflects current state;
     tabindex='0' makes it keyboard reachable; keydown handler enables Space/Enter -->
<div
  role='switch'
  aria-checked='false'
  tabindex='0'
  onclick='toggleDarkMode(this)'
  onkeydown='if(event.key==="Enter"||event.key===" "){toggleDarkMode(this);event.preventDefault();}'
>
  Dark Mode
</div>

<script>
function toggleDarkMode(el) {
  const isOn = el.getAttribute('aria-checked') === 'true';
  el.setAttribute('aria-checked', String(!isOn));
  document.body.classList.toggle('dark-mode', !isOn);
}
</script>

Nienazwany iframe — Niepoprawne

<!-- iframe with no title: screen reader users cannot determine what is inside -->
<iframe src='https://maps.example.com/embed?q=istanbul'></iframe>

Nienazwany iframe — Poprawne

<!-- title describes the frame's content so users can decide whether to enter it -->
<iframe
  src='https://maps.example.com/embed?q=istanbul'
  title='Interactive map showing our Istanbul office location'
></iframe>

Niestandardowy pasek postępu bez wymaganych atrybutów ARIA — Niepoprawne

<!-- role='progressbar' without aria-valuenow, aria-valuemin, aria-valuemax:
     screen readers cannot determine the current progress -->
<div role='progressbar' style='width:60%'></div>

Niestandardowy pasek postępu bez wymaganych atrybutów ARIA — Poprawne

<!-- All required attributes present; aria-label provides the accessible name -->
<div
  role='progressbar'
  aria-valuenow='60'
  aria-valuemin='0'
  aria-valuemax='100'
  aria-label='File upload progress'
>
  60%
</div>

Typowe Błędy

Używanie role='button' na elemencie <div> bez dodania tabindex='0' — element jest ogłaszany jako przycisk przez czytniki ekranu, ale pozostaje nieosiągalny za pomocą nawigacji klawiszem Tab, co czyni go bezużytecznym dla użytkowników korzystających wyłącznie z klawiatury.
Stosowanie aria-label do elementu nieinteraktywnego — dodanie aria-label do elementu <div> lub <span> bez roli nie ma efektu; etykieta jest ignorowana przez większość przeglądarek, ponieważ element nie ma roli, którą mogłaby nazywać.
Pozostawienie statycznego aria-expanded po zaimplementowaniu widżetu rozwijania — ustawienie aria-expanded='false' w HTML i nigdy nieprzełączanie go w JavaScript oznacza, że atrybut jest zawsze nieprawidłowy po pierwszym kliknięciu, ogłaszając użytkownikom czytników ekranu stan przeciwny do rzeczywistego.
Używanie aria-hidden='true' na kontenerze zawierającym elementy fokusowalne — ukrywa to kontener w drzewie dostępności, ale nie przed fokusem klawiatury, więc użytkownicy czytników ekranu mogą przechodzić klawiszem Tab do elementów, których nie słyszą, co powoduje skrajną dezorientację.
Używanie placeholder jako jedynej etykiety dla elementu <input> — tekst zastępczy znika po wprowadzeniu danych, nie jest niezawodnie ogłaszany jako etykieta przez wszystkie czytniki ekranu i nie spełnia wymogu dostępnej nazwy dla pól formularzy.
Używanie nieprawidłowej lub abstrakcyjnej roli ARIA, takiej jak role='widget' lub role='structure' — są to role bazowe w specyfikacji ARIA i nie są przeznaczone do bezpośredniego użycia; nie dostarczają znaczącej informacji semantycznej i mogą być ignorowane lub powodować błędy w technologiach asystujących.
Odwoływanie się do nieistniejącego identyfikatora elementu w aria-labelledby — jeśli identyfikator wskazany przez aria-labelledby nie istnieje w DOM, obliczanie dostępnej nazwy kończy się niepowodzeniem i element pozostaje bez nazwy.
Używanie value zamiast aria-label dla <input type='image'> — przyciski typu image wymagają atrybutu alt dla swojej dostępnej nazwy; atrybut value jest ignorowany przy obliczaniu nazwy dla pól typu image.
Pominięcie atrybutu title w elementach <iframe> ładujących treści zewnętrzne — deweloperzy często zakładają, że dobrze znane osadzenia (mapy, widżety płatności, odtwarzacze wideo) są samoopisujące, ale użytkownicy czytników ekranu muszą zostać poinformowani o celu ramki, zanim zdecydują, czy do niej wejść.
Zapominanie o dynamicznej aktualizacji dostępnych nazw, gdy treść się zmienia — jeśli etykieta przycisku wizualnie zmienia się z „Odtwórz” na „Pauza”, ale aria-label pozostaje „Odtwórz”, użytkownicy czytników ekranu otrzymują nieprawidłową informację o aktualnym stanie i działaniu.

Związek z Tureckimi Regulacjami Dotyczącymi Dostępności

Turecka Okrężnica Prezydencka 2025/10, opublikowana w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia obowiązkowe wymagania dotyczące dostępności cyfrowej, zgodne z WCAG 2.2. WCAG 4.1.2 — Nazwa, Rola, Wartość to kryterium poziomu A, co oznacza, że znajduje się na najbardziej fundamentalnym poziomie zgodności. Zgodnie z okrężnicą, zgodność na poziomie A nie jest opcjonalna — stanowi minimalny próg, który wszystkie objęte podmioty muszą osiągnąć.

Okrężnica ma zastosowanie do szerokiego zakresu typów podmiotów działających w Turcji. Instytucje publiczne — w tym ministerstwa, gminy i agencje państwowe — muszą osiągnąć zgodność w ciągu jednego roku od daty publikacji okrężnicy. Podmioty sektora prywatnego — w tym platformy e-commerce, banki i instytucje finansowe, szpitale i prywatni świadczeniodawcy usług zdrowotnych, firmy telekomunikacyjne z 200,000 lub większą liczbą abonentów, biura podróży, prywatne firmy transportowe oraz szkoły prywatne upoważnione przez Ministerstwo Edukacji Narodowej (MoNE) — muszą osiągnąć zgodność w ciągu dwóch lat.

WCAG 4.1.2 ma szczególnie duże znaczenie dla tureckich organizacji, ponieważ tak wiele nowoczesnych tureckich stron internetowych opiera się na niestandardowych komponentach interaktywnych — karuzelach produktów, akordeonowych sekcjach FAQ, wieloetapowych procesach zakupowych i panelach bankowości — które często są implementowane bez prawidłowych ról ARIA, nazw lub zarządzania stanem. Niestandardowy przycisk finalizacji zakupu bez dostępnej nazwy lub suwak kalkulatora kredytowego bez aria-valuenow to nie tylko słabe doświadczenie użytkownika: zgodnie z okrężnicą stanowi to naruszenie wymogów prawnych.

Dla banków i platform e-commerce objętych okrężnicą naruszenia WCAG 4.1.2 w krytycznych dla transakcji przepływach — formularzach płatności, modalach uwierzytelniania, panelach kont — są szczególnie ryzykowne. Wizualnie wystylizowany niestandardowy combobox do wyboru oddziału banku, który nie ma prawidłowego znacznikowania ARIA, może całkowicie uniemożliwić użytkownikowi czytnika ekranu dokończenie transakcji, narażając instytucję zarówno na działania regulacyjne, jak i roszczenia z tytułu dyskryminacji.

Organizacje korzystające z nakładki Accsible overlay SDK mogą skorzystać z automatycznego wykrywania i naprawy w czasie rzeczywistym wielu naruszeń związanych z Nazwą, Rolą i Wartością — w tym wstrzykiwania brakujących dostępnych nazw, korygowania nieprawidłowych ról ARIA w znanych wzorcach widżetów oraz synchronizowania atrybutów stanu w komponentach interaktywnych. Organizacje powinny jednak traktować wsparcie w postaci automatycznej nakładki jako uzupełnienie, a nie zamiennik prawidłowego, semantycznego HTML, szczególnie w przypadku złożonych niestandardowych widżetów, w których programowe zarządzanie stanem musi być wbudowane w logikę aplikacji od samego początku.

Źródła i odniesienia

Powiązane artykuły

AWCAG 1.1.1: Treści nietekstowe AWCAG 1.2.1: Tylko audio i tylko wideo (nagranie)AWCAG 1.2.2: Napisy (nagrania wcześniej przygotowane)