Czym jest ARIA? Role, punkty orientacyjne i obszary live

Czym ARIA jest — a czym nie jest

ARIA to skrót od Accessible Rich Internet Applications. Jest to zestaw atrybutów zdefiniowanych przez Web Accessibility Initiative (WAI) konsorcjum W3C, który pozwala programistom przekazywać znaczenie i stan elementów interfejsu użytkownika technologiom wspomagającym, takim jak czytniki ekranu.

Najważniejsza zasada dotycząca ARIA jest zarazem tą najczęściej ignorowaną: nie używaj ARIA tam, gdzie natywny HTML wykona zadanie. Element <button> już ogłasza się jako przycisk i reaguje na zdarzenia klawiatury. Element <nav> już przekazuje czytnikom ekranu informację o punkcie orientacyjnym nawigacji. Dodanie role="button" do elementu <div>, a następnie oskryptowanie jego zachowania, jest trudniejsze w utrzymaniu, łatwiejsze do zepsucia i zwykle gorsze dla dostępności niż użycie od razu właściwego elementu.

ARIA nie:

Sprawia, że treść staje się widoczna lub interaktywna — zmienia jedynie to, co ogłasza technologia wspomagająca
Naprawia zepsutej obsługi z klawiatury — wciąż potrzebujesz tabindex i nasłuchiwania zdarzeń
Zastępuje dobrze zbudowanego, semantycznego kodu HTML

ARIA naprawdę pomaga tam, gdzie natywny HTML nie ma elementu odpowiadającego temu, co budujesz: przy wyborze daty, banerze powiadomień na żywo, niestandardowym polu z listą czy widoku drzewa. W takich przypadkach ARIA pozwala przekazać semantykę, której HTML nie potrafi wyrazić.

Role ARIA

Rola mówi technologii wspomagającej, z jakim rodzajem elementu ma do czynienia. Każdy element interaktywny ma niejawną rolę wynikającą ze swojego znacznika HTML. Element <a> ma rolę link. Element <input type="checkbox"> ma rolę checkbox. Element <h2> ma rolę heading.

Gdy budujesz element niestandardowy, który nie ma odpowiednika w HTML, przypisujesz mu rolę jawnie:

<!-- Niestandardowy przełącznik zbudowany z elementu div -->
<div
  role="switch"
  aria-checked="false"
  tabindex="0"
>
  Tryb ciemny
</div>

Czytnik ekranu ogłosi to teraz jako przełącznik i poda jego stan zaznaczenia. Bez roli element zostałby ogłoszony jako zwykły tekst, a użytkownik nie miałby pojęcia, że jest interaktywny.

Częste role i kiedy je stosować

Role widżetów opisują interaktywne kontrolki:

Rola	Kiedy stosować
`button`	Niestandardowy element klikalny, dla którego nie ma lepszego znacznika HTML
`checkbox`	Niestandardowy przełącznik wielokrotnego wyboru
`combobox`	Pole tekstowe połączone z rozwijaną listą
`dialog`	Nakładka modalna (tylko gdy nie używasz natywnego elementu `<dialog>`)
`listbox`	Niestandardowa lista rozwijana
`slider`	Niestandardowa kontrolka zakresu
`switch`	Przełącznik włącz/wyłącz
`tab`, `tablist`, `tabpanel`	Interfejs z zakładkami
`tooltip`	Krótki opis wyświetlany po najechaniu lub uzyskaniu fokusu

Role struktury dokumentu opisują treść nieinteraktywną:

article — samodzielny fragment treści
figure — obraz z podpisem
list, listitem — gdy semantyka listy jest potrzebna na elementach niebędących listą
presentation / none — usuwa niejawną rolę elementu (stosuj rzadko i ostrożnie)

Krytyczny błąd: dodawanie ról bez zachowania

Każda rola niesie ze sobą kontrakt, którego dotrzymania oczekują czytniki ekranu i użytkownicy klawiatury. Element z role="button" musi reagować zarówno na Enter, jak i na spację. Element z role="checkbox" musi przełączać się spacją. Element z role="link" musi przechodzić dalej po naciśnięciu Enter.

Jeśli dodasz rolę, ale nie odpowiadające jej zachowanie, aktywnie wprowadzasz w błąd użytkowników technologii wspomagających. Słyszą ogłoszoną kontrolkę, próbują wejść z nią w interakcję oczekiwanym skrótem klawiaturowym — i nic się nie dzieje. To gorsze niż całkowity brak ARIA.

Punkty orientacyjne ARIA

Punkty orientacyjne (landmarks) to nawigacyjny szkielet strony. Pozwalają użytkownikom czytników ekranu przeskakiwać między głównymi obszarami bez czytania wszystkiego pomiędzy — to odpowiednik rzutu oka, którym widzący użytkownik ogarnia układ strony.

HTML5 wprowadził elementy semantyczne, które odwzorowują się bezpośrednio na role punktów orientacyjnych. Używaj ich, a punkty orientacyjne dostaniesz za darmo:

Element HTML	Rola punktu orientacyjnego	Przeznaczenie
`<header>`	`banner`	Nagłówek witryny (tylko gdy jest to nagłówek najwyższego poziomu, a nie wewnątrz `<article>`)
`<nav>`	`navigation`	Menu nawigacyjne
`<main>`	`main`	Główna treść strony
`<aside>`	`complementary`	Treść uzupełniająca powiązana z treścią główną
`<footer>`	`contentinfo`	Stopka witryny
`<form>`	`form`	Formularz (tylko gdy ma nazwę dostępną)
`<section>`	`region`	Nazwana sekcja (tylko gdy ma nazwę dostępną przez `aria-label` lub `aria-labelledby`)

Nie musisz dodawać role="main" do elementu <main> — jest to nadmiarowe. Role punktów orientacyjnych ARIA są potrzebne tylko wtedy, gdy nie możesz użyć semantycznego elementu HTML, na przykład w starszym kodzie generującym <div class="sidebar">:

<div class="sidebar" role="complementary" aria-label="Powiązane artykuły">
  <!-- treść paska bocznego -->
</div>

Etykietowanie punktów orientacyjnych, gdy jest ich więcej niż jeden

Gdy strona zawiera wiele wystąpień tego samego punktu orientacyjnego — dwa elementy <nav>, dwa elementy <section> z role="region" — każdy z nich musi mieć unikatową nazwę dostępną, aby użytkownicy mogli je rozróżnić:

<nav aria-label="Nawigacja główna">...</nav>
<nav aria-label="Nawigacja w stopce">...</nav>

Bez etykiet czytnik ekranu ogłosi oba po prostu jako „nawigacja”. Z etykietami użytkownicy usłyszą „Nawigacja główna, punkt orientacyjny nawigacji” oraz „Nawigacja w stopce, punkt orientacyjny nawigacji” i będą mogli wybrać właściwy z listy punktów orientacyjnych.

Obszary live ARIA

Obszar live to fragment strony, którego treść aktualizuje się dynamicznie i którego aktualizacje powinny być automatycznie ogłaszane użytkownikom czytników ekranu, bez konieczności przenoszenia przez nich fokusu.

Podstawowym atrybutem jest aria-live. Przyjmuje trzy wartości:

off — aktualizacje nie są ogłaszane (wartość domyślna dla wszystkich elementów)
polite — aktualizacje są ogłaszane po tym, jak użytkownik skończy bieżące zadanie
assertive — aktualizacje natychmiast przerywają to, co czytnik ekranu właśnie mówi

<!-- Obszar komunikatu o stanie wypełniany po wysłaniu formularza -->
<div aria-live="polite" id="status-message"></div>

<script>
  document.getElementById('status-message').textContent =
    'Twoja wiadomość została wysłana.';
</script>

Gdy treść tekstowa się zmieni, czytnik ekranu z aria-live="polite" poczeka na przerwę w wypowiedzi, a następnie ogłosi nową treść. Używaj polite dla zdecydowanej większości aktualizacji dynamicznych. Zarezerwuj assertive wyłącznie dla krytycznych awarii — błędu płatności, ostrzeżenia o wygaśnięciu sesji — gdzie informacja jest na tyle pilna, że usprawiedliwia przerwanie użytkownikowi.

Skróty rolowe dla obszarów live

Dwie role pakują semantykę aria-live w jeden atrybut:

role="status" — odpowiednik aria-live="polite". Stosuj dla komunikatów o powodzeniu, stanów ładowania i aktualizacji, które nie są pilne.
role="alert" — odpowiednik aria-live="assertive", dodatkowo implikujący aria-atomic="true". Stosuj dla komunikatów o błędach i krytycznych awarii.

<!-- Błąd ogłaszany natychmiast, przerywający bieżącą wypowiedź -->
<div role="alert" id="payment-error"></div>

<!-- Aktualizacja stanu ogłaszana grzecznie po bieżącej wypowiedzi -->
<div role="status" id="cart-count">3 produkty w koszyku</div>

Częste błędy przy obszarach live

Dodawanie treści, zanim element trafi do DOM. Przeglądarka rejestruje obszar live w chwili pierwszego przetworzenia elementu. Jeśli wstrzykniesz element i jednocześnie ustawisz jego treść tekstową, część czytników ekranu całkowicie przeoczy ogłoszenie. Zawsze umieszczaj kontener obszaru live w początkowym kodzie HTML, a jego treść aktualizuj później za pomocą JavaScriptu.

Używanie assertive do wszystkiego. Asertywne obszary live przerywają to, co użytkownik właśnie robi, w tym inne ogłoszenia. Licznik wyników wyszukiwania aktualizujący się w trakcie pisania nie zasługuje na role="alert". Nadużywanie assertive tworzy wrogie doświadczenie dla użytkowników czytników ekranu.

Zbyt częste aktualizowanie obszaru live. Jeśli wskaźnik postępu aktualizuje swój obszar live co 100 milisekund, kolejka mowy się przepełnia i użytkownicy nie słyszą nic użytecznego. Aktualizuj tekst w obszarze live tylko w sensownych punktach — 25%, 50%, 75%, zakończono — albo zastosuj opóźnienie zbiorcze (debounce) sterowane czasomierzem.

Zapominanie o aria-atomic. Domyślnie ogłaszany jest tylko zmieniony węzeł tekstowy wewnątrz obszaru live. Jeśli chcesz, aby cały obszar został odczytany ponownie (a nie tylko zmieniony fragment), dodaj aria-atomic="true":

<div aria-live="polite" aria-atomic="true">
  Pozostałe pozycje: <span id="count">2</span>
</div>

Bez aria-atomic czytnik ekranu może ogłosić tylko „2”, gdy licznik zmieni się z 3 na 2. Z tym atrybutem wypowiadana jest pełna fraza „Pozostałe pozycje: 2”, co niemal zawsze jest tym, o co Ci chodzi.

Inne kluczowe atrybuty ARIA

aria-label — nadaje nazwę dostępną, gdy widoczny tekst nie jest właściwym rozwiązaniem:

<button aria-label="Zamknij okno dialogowe">✕</button>

aria-labelledby — wskazuje inny element, którego tekst pełni funkcję nazwy dostępnej. Preferowany zamiast aria-label, gdy tekst etykiety jest już widoczny na stronie:

<h2 id="billing-heading">Adres rozliczeniowy</h2>
<form aria-labelledby="billing-heading">...</form>

aria-describedby — wskazuje uzupełniający tekst opisujący element ponad jego nazwę:

<input type="password" aria-describedby="pwd-hint">
<p id="pwd-hint">Musi mieć co najmniej 12 znaków i zawierać jeden symbol.</p>

aria-expanded — wskazuje, czy element zwijany (lista rozwijana, akordeon, menu) jest otwarty czy zamknięty. Aktualizuj go w JavaScripcie za każdym razem, gdy stan się zmienia:

<button aria-expanded="false" aria-controls="nav-menu">Menu</button>
<ul id="nav-menu" hidden>...</ul>

aria-hidden="true" — usuwa element z drzewa dostępności. Stosuj dla ikon dekoracyjnych, zduplikowanego tekstu lub elementów wizualnych, które byłyby szumem dla użytkowników czytników ekranu:

<span aria-hidden="true">★★★★☆</span>
<span class="sr-only">4 gwiazdki na 5</span>

aria-disabled="true" — oznacza kontrolkę jako wyłączoną, nie usuwając jej z kolejności fokusu. Przydatne, gdy chcesz, by użytkownicy odkryli, że kontrolka istnieje, i zrozumieli, dlaczego jest niedostępna, zamiast po cichu ją pomijać:

<button aria-disabled="true">Wyślij (najpierw wypełnij wszystkie pola)</button>

Testowanie ARIA w praktyce

Pisanie atrybutów ARIA jest proste. Poprawne ich zastosowanie wymaga testowania. Skanery automatyczne wychwytują wzorce wyraźnie zepsute — role="button" bez nazwy dostępnej, aria-labelledby wskazujący na nieistniejący identyfikator, obszar live z nieprawidłową wartością aria-live. Nie powiedzą Ci jednak, czy ogłaszany tekst ma sens w kontekście ani czy złożony widżet niestandardowy zachowuje się poprawnie przy nawigacji samą klawiaturą.

Do testowania w realnych warunkach łącz co najmniej dwie pary czytnika ekranu i przeglądarki:

NVDA + Chrome w systemie Windows — bezpłatny, szeroko używany, bliski rzeczywistej populacji użytkowników czytników ekranu
VoiceOver + Safari w macOS lub iOS — wbudowany, niezbędny do testowania dostępności mobilnej
JAWS + Chrome lub Edge w systemie Windows — płatny, ale najczęściej używany czytnik ekranu w środowiskach korporacyjnych

Nawiguj po swoich komponentach interaktywnych, używając wyłącznie klawiatury. Wsłuchaj się uważnie w to, co jest ogłaszane, gdy otwierasz menu, wysyłasz formularz z błędem walidacji lub wyzwalasz aktualizację obszaru live. Jeśli ogłoszenie jest niejednoznaczne lub mylące, implementacja ARIA jest błędna — niezależnie od tego, co raportuje jakiekolwiek narzędzie automatyczne.

Zasada, która obejmuje wszystko

Specyfikacja ARIA zawiera pięć reguł tworzenia kodu. Pierwsza z nich jest najważniejsza:

Jeśli możesz użyć natywnego elementu lub atrybutu HTML z wbudowaną już semantyką i zachowaniem, których potrzebujesz, zamiast przeznaczać element do innego celu i dodawać rolę, stan lub właściwość ARIA, aby uczynić go dostępnym — zrób to.

Buduj z semantycznego HTML. Sięgaj po ARIA dopiero wtedy, gdy HTML się kończy. Testuj z prawdziwym czytnikiem ekranu. To pokrywa niemal każdą sytuację, jaką napotkasz.

Aby praktycznie sprawdzić, jak atrybuty ARIA są zaimplementowane w całej Twojej witrynie, nasze ręczne audyty dostępności obejmują testy z czytnikami ekranu prowadzone przez osoby, które na co dzień korzystają z technologii wspomagających i potrafią wychwycić subtelne problemy z ARIA, umykające narzędziom automatycznym.