Czym są atrybuty ARIA? WAI-ARIA prosto wyjaśnione

ARIA to skrót od Accessible Rich Internet Applications. To zestaw atrybutów HTML, standaryzowany przez W3C jako WAI-ARIA (aktualna wersja 1.2, opublikowana w czerwcu 2023 roku), który przekazuje technologiom asystującym, takim jak czytniki ekranu, dodatkowe informacje o elementach interfejsu. ARIA staje się potrzebna tam, gdzie kończy się semantyka natywnego HTML: przy zakładkach, akordeonie, własnej liście rozwijanej czy komunikacie o statusie pojawiającym się dynamicznie. Słownik składa się z trzech cegiełek: role opisują, czym element jest, stany opisują jego bieżącą sytuację, a właściwości opisują cechy i powiązania. ARIA jest jednocześnie potężna i niebezpieczna. Użyta poprawnie sprawia, że złożone widżety stają się użyteczne dla osób korzystających z czytnika ekranu, użyta błędnie aktywnie psuje dostępność, i właśnie dlatego najważniejsza zasada ARIA mówi, by wybierać natywne elementy HTML zawsze wtedy, gdy potrafią wykonać zadanie.

Co oznacza skrót ARIA i po co powstał?

HTML ma bogatą wbudowaną semantykę: button jest odczytywany jako przycisk, nav jako nawigacja, a zaznaczone pole wyboru samo zgłasza swój stan. Czytniki ekranu odczytują to wszystko z drzewa dostępności, które przeglądarka buduje na podstawie Twojego kodu. Problem zaczyna się przy wszystkim, dla czego HTML nie ma elementu. Nie ma natywnego panelu zakładek, akordeonu ani powiadomienia typu toast. Deweloperzy budują je z divów i spanów, a dla osoby korzystającej z czytnika ekranu akordeon oparty na divach jest po prostu ciszą: bez nazwy, bez roli, bez stanu.

WAI-ARIA wypełnia dokładnie tę lukę. Pozwala powiedzieć technologii asystującej, czym jest Twój własny widżet i co właśnie robi, bez zmiany tego, jak strona wygląda i zachowuje się dla pozostałych użytkowników.

Role, stany i właściwości: trzy cegiełki ARIA

• Role definiują, czym element jest. role="dialog", role="tablist", role="alert". Rola to obietnica złożona użytkownikowi: ta rzecz będzie zachowywać się jak okno dialogowe.
• Stany opisują bieżącą, zmienną sytuację elementu. aria-expanded="true", aria-checked="false", aria-disabled="true". Stany zmieniają się podczas interakcji, a Twój JavaScript musi je utrzymywać w zgodzie z rzeczywistością.
• Właściwości opisują cechy i powiązania, które rzadko się zmieniają. aria-labelledby wskazuje element nadający nazwę, aria-controls wskazuje element sterowany, a aria-required oznacza pole obowiązkowe.

Rozróżnienie między stanami a właściwościami jest w codziennej pracy akademickie, bo jedne i drugie to po prostu atrybuty. Liczy się model myślowy: rola mówi, czym to jest, a cała reszta mówi, jak się nazywa, co robi i do czego należy.

Pierwsza zasada ARIA: nie używaj ARIA

Dokument W3C Using ARIA otwiera zasada, która brzmi jak żart, a jest całkiem poważna: jeśli istnieje już natywny element HTML o potrzebnej semantyce i zachowaniu, użyj go zamiast przerabiać inny element i doklejać ARIA. Porównaj dwa sposoby zbudowania przycisku:

<!-- Dla osób widzących wygląda jak przycisk, dla reszty to martwy div -->
<div class="btn" onclick="save()">Zapisz</div>

<!-- Wszystko w komplecie: rola, obsługa klawiatury, fokus -->
<button type="button" onclick="save()">Zapisz</button>

Żeby naprawić wersję z divem, potrzebowałbyś role="button", tabindex="0" i dodatkowego JavaScriptu obsługującego Enter i spację. Natywny element robi to wszystko za darmo i będzie to robił także w przeglądarkach, których nigdy nie testowałeś. Ta sama logika dotyczy linków, pól wyboru, pól formularzy i nagłówków.

Za tą zasadą stoi otrzeźwiająca dana. WebAIM co roku analizuje milion najpopularniejszych stron głównych, a jego raporty konsekwentnie pokazują, że strony używające ARIA mają średnio więcej wykrytych błędów dostępności niż strony bez niej. Nie dlatego, że ARIA jest zła, ale dlatego, że tak często stosuje się ją niepoprawnie. Brak ARIA jest lepszy niż zepsuta ARIA.

Najważniejsze atrybuty ARIA

• aria-label: nadaje elementowi dostępną nazwę wprost. Klasyczny przypadek to przycisk z samą ikoną: aria-label="Zamknij" na krzyżyku okna modalnego.
• aria-labelledby: wskazuje identyfikator innego elementu, którego widoczny tekst staje się nazwą. Lepszy od aria-label, gdy widoczna etykieta istnieje, bo obie wartości nie mogą się rozjechać.
• aria-describedby: wskazuje dodatkowy tekst opisowy, zwykle podpowiedź albo komunikat o błędzie pod polem formularza.
• aria-hidden="true": usuwa element wraz z jego dziećmi z drzewa dostępności. Właściwy przy ikonach dekoracyjnych, niebezpieczny przy czymkolwiek, co można sfokusować.
• aria-expanded: sygnalizuje na elemencie sterującym, czy powiązany obszar jest otwarty, czy zamknięty. Fundament akordeonów, menu rozwijanych i nawigacji mobilnej.
• aria-controls: łączy element sterujący z elementem, którym on steruje.
• aria-live: zamienia element w obszar aktywny, którego zmiany treści są odczytywane automatycznie. polite czeka na przerwę, assertive przerywa natychmiast i powinien być zarezerwowany dla naprawdę pilnych komunikatów.
• aria-current: oznacza bieżący element w zbiorze, na przykład aria-current="page" na aktywnym linku nawigacji.
• aria-required i aria-invalid: komunikują pola obowiązkowe i błędy walidacji w formularzach. Przy natywnej walidacji HTML samo required pokrywa już pierwszą część.

Czym są role punktów orientacyjnych ARIA?

Punkty orientacyjne dzielą stronę na nazwane obszary, między którymi osoby korzystające z czytnika ekranu mogą przeskakiwać bezpośrednio, tak jak osoby widzące omiatają wzrokiem układ strony. Dobra wiadomość: nowoczesne elementy HTML tworzą większość punktów orientacyjnych niejawnie, więc w dobrze zbudowanym dokumencie rzadko wpisujesz te role ręcznie.

• header odpowiada punktowi orientacyjnemu banner
• nav odpowiada navigation
• main odpowiada main i powinien występować dokładnie raz na stronę
• aside odpowiada complementary
• footer odpowiada contentinfo
• form i section stają się punktami orientacyjnymi form i region, gdy mają dostępną nazwę

Jeden nawyk wart wyrobienia: jeśli strona ma dwie nawigacje, rozróżnij je nazwami aria-label="Menu główne" i aria-label="Menu w stopce". Usłyszenie dwa razy słowa nawigacja bez żadnego rozróżnienia nikomu nie pomaga.

Praktyczne przykłady ARIA: akordeon i obszar aktywny

Minimalny dostępny nagłówek akordeonu pokazuje, jak elementy współgrają. Przycisk niesie stan, panel jest wskazywany przez identyfikator, a JavaScript przełącza oba przy kliknięciu:

<h3>
  <button aria-expanded="false" aria-controls="panel-shipping">
    Wysyłka i zwroty
  </button>
</h3>
<div id="panel-shipping" hidden>
  <p>Wysyłamy w ciągu 2 do 4 dni roboczych...</p>
</div>

A tak wygląda obszar aktywny dla informacji zwrotnej pojawiającej się bez przeładowania strony, na przykład po dodaniu produktu do koszyka albo po przefiltrowaniu wyników:

<div aria-live="polite" class="visually-hidden" id="status"></div>

<script>
  document.getElementById('status').textContent = 'Znaleziono 12 produktów'
</script>

Bez obszaru aktywnego osoba korzystająca z czytnika ekranu filtruje listę produktów i nie słyszy zupełnie nic. Z nim liczba wyników jest odczytywana w chwili, gdy się zmienia. Mały atrybut, duża różnica.

Częste błędy w ARIA, których warto unikać

• aria-hidden="true" na elementach, które można sfokusować: element znika z drzewa dostępności, ale zostaje w kolejności tabulacji. Osoba korzystająca z klawiatury ląduje na duchu. To jeden z najczęstszych błędów ARIA w praktyce.
• Zbędne role: role="button" na elemencie button albo role="navigation" na nav dokłada szumu i pokazuje, że kod nie został zrozumiany.
• Role bez zachowania: role="tab" obiecuje nawigację strzałkami. Jeśli Twój JavaScript jej nie zapewnia, taka rola szkodzi bardziej niż jej brak, bo budzi oczekiwania, których widżet nie spełnia.
• Nieaktualne stany: aria-expanded, które na zawsze zostaje na false, bo nikt nie aktualizuje go w obsłudze kliknięcia. Osoba korzystająca z czytnika ekranu słyszy zwinięty, patrząc na otwarty panel.
• aria-label na zwykłych elementach tekstowych: na divie albo spanie bez roli aria-label jest ignorowany przez większość technologii asystujących. To nie jest uniwersalny dymek podpowiedzi.
• Nadużywanie obszarów aktywnych typu assertive: jeśli każda zmiana koszyka, informacja o cookies i okienko newslettera przerywa użytkownikowi, naprawdę ważne komunikaty toną w szumie.

ARIA w motywach i wtyczkach WordPress

Rdzeń WordPressa wypada przyzwoicie: blok nawigacji zarządza atrybutem aria-expanded przy przełącznikach podmenu, klasa CSS screen-reader-text dla etykiet ukrytych wizualnie jest od lat utrwaloną konwencją, a rdzeniowe komponenty formularzy mają sensowne atrybuty. Kłopoty przychodzą zwykle z tym, co instalujesz na wierzchu. To page buildery, wtyczki ze sliderami, mega menu i narzędzia do popupów są miejscem, gdzie piętrzy się zupa divów z brakującą lub zepsutą ARIA. Przy ocenie motywu tag accessibility-ready w katalogu motywów WordPress jest realnym sygnałem, bo takie motywy przechodzą przegląd według zdefiniowanych kryteriów. W pozostałych przypadkach ARIA Authoring Practices Guide dokumentuje sprawdzone wzorce dla niemal każdego widżetu, jaki kiedykolwiek zbudujesz, wraz z działającą obsługą klawiatury.

Jak InspectWP sprawdza użycie ARIA?

InspectWP bada wyrenderowane strony w ramach analizy dostępności i oznacza problemy związane z ARIA, które narzędzia automatyczne potrafią wykryć w sposób pewny: nieprawidłowe nazwy ról, atrybuty ARIA niedozwolone na elemencie, na którym się znalazły, odwołania do nieistniejących identyfikatorów, elementy możliwe do sfokusowania ukryte przez aria-hidden oraz elementy interaktywne bez dostępnej nazwy. Znaleziska są pogrupowane według wagi, więc zepsuta nazwa w nawigacji głównej stoi wyżej niż zbędna rola w stopce. Ponieważ o skuteczności ostatecznie decyduje zachowanie czytnika ekranu, potraktuj raport jako szybkie i powtarzalne pierwsze przejście, a najważniejsze ścieżki sprawdź potem prawdziwym czytnikiem ekranu.