Jakie są role ARIA? Praktyczny przewodnik dla programistów

Jakie są role ARIA? Role ARIA to słownik składający się z 87 zdefiniowanych wartości (od wersji WAI-ARIA 1.2), które informują technologie wspomagające, czym jest element i jak powinien się zachowywać niezależnie od jego znacznika HTML. Role takie jak button, navigation lub dialog przypisują ogólny <div> lub <span> do znanego typu widżetu, dzięki czemu czytniki ekranu będą go poprawnie ogłaszać i wyświetlać prawidłowe interakcje z klawiaturą.

Dlaczego role ARIA w ogóle istnieją

Aby zrozumieć, czym są role arii, trzeba zobaczyć, że rozwiązują one problem strukturalny, którego sam HTML nie jest w stanie rozwiązać. Natywne elementy HTML mają ukrytą semantykę: <button> ogłasza się jako przycisk, można go zaznaczyć, reaguje na klawisz Enter i spację oraz, jeśli to konieczne, wyświetla stan naciśnięcia.

Kiedy programiści tworzą niestandardowe widżety (combobox, panel zakładek, widok drzewa), często używają <div> i <span>, które nie zawierają żadnej semantyki. Role ARIA wypełniają tę lukę, umożliwiając autorom wyraźne określenie brakującego znaczenia.

Specyfikacja WAI-ARIA jest prowadzona przez Grupę Roboczą ds. Dostępnych Bogatych Aplikacji Internetowych W3C. Pierwsza wersja, ARIA 1.0, została rekomendacją W3C w 2014 roku; ARIA 1.1 pojawiła się w 2017 r., a ARIA 1.2 osiągnęła status zalecenia w 2023 r. Role, stany i właściwości były dodawane w każdej wersji, a każda z nich była powiązana z dokumentem dotyczącym praktyk tworzenia, który opisuje oczekiwane zachowanie klawiatury.

Kluczowe rozróżnienie oddziela te role od pozostałych dwóch kategorii ARIA. Role odpowiadają: „Co to jest?” Stany i właściwości odpowiadają: „W jakim jest stanie?” i „Z czym to jest powiązane?” role="checkbox" deklaruje typ widżetu; aria-checked="true" wskazuje jego bieżący stan. Pomieszanie tych dwóch elementów jest jedną z najczęstszych przyczyn nieprawidłowego działania niestandardowych widżetów.

Sześć kategorii ról

Aby zrozumieć, czym są role ARIA, warto wiedzieć, że specyfikacja ARIA grupuje role w sześć rodzin. Zrozumienie rodziny pozwala przewidzieć, jakie stany i właściwości obsługuje dana rola oraz jakie wzorce klawiatury mają zastosowanie.

Powiązane: accessiBe — Superposición de IA que promete cumplimiento WCAG w 48 godzinach.

Kategoria	Cel	Role reprezentatywne
Abstrakcyjne	Definicje nadklas, nigdy nie używane w znacznikach	widget, input, section
Widżet	Interaktywne sterowanie	button, checkbox, slider, tab
Struktura dokumentu	Punkty orientacyjne strony i regiony	banner, main, navigation, region
Punkt orientacyjny	Regiony strony, po których można nawigować (podzbiór struktury)	banner, complementary, contentinfo, form
Region na żywo	Ogłoś dynamiczne zmiany zawartości	alert, status, log, timer
Okno	Okna przeglądarki lub aplikacji	dialog, alertdialog

Role abstrakcyjne służą jedynie do organizowania taksonomii. Autorom nigdy nie wolno wpisywać w znacznikach „role=“widget”lubrole=“input”`; powoduje to niezdefiniowane zachowanie i sprawdzanie poprawności kończy się niepowodzeniem. Pozostałe pięć kategorii to te, które faktycznie stosujesz.

Ukryte role i pierwsza zasada ARIA

Każdy element HTML ma niejawną funkcję ARIA (która wyjaśnia, czym są role arii) zdefiniowaną w specyfikacji HTML Accessibility API Mapping (AAM). Element <nav> ma ukryte role="navigation". <ul> ma ukrytą role="list". <h1> do <h6> ma role="heading". <table> zawiera role="table".

Pierwsza zasada W3C dotycząca używania ARIA jasno stwierdza: Jeśli natywny element lub atrybut HTML już przekazuje wymaganą semantykę i zachowanie, użyj go zamiast ponownie używać elementu w ARIA. Dodawanie role="button" do <button> nie jest konieczne. Co gorsza, jeśli dodasz role="button" do <div>, otrzymasz ogłoszenie, ale bez zachowania: brak fokusu, brak aktywacji klawiatury, brak przesyłania formularza.

Warto zobaczyć: AudioEye — Accesibilidad gestionada: automatización cobinada con revisión humana.

Redundancja nie zawsze jest nieszkodliwa. Zastąpienie ukrytej roli może spowodować utratę semantyki, od której zależy technologia wspomagająca. Zapisanie role="presentation" w <table> całkowicie eliminuje semantykę tabeli, która czasami jest zamierzona w przypadku tabel układu, ale jest katastrofalna w przypadku tabel danych.

Jak role współdziałają ze stanami i właściwościami

Role pełnią rolę kontenerów dla obsługiwanych przez nie stanów i właściwości. Specyfikacja określa, które atrybuty są ważne dla jakich ról, a przeglądarki wyświetlają w drzewie dostępności tylko obsługiwane kombinacje.

Zrozumienie, czym są role arii, pomaga wiedzieć, że role="checkbox" obsługuje aria-checked z wartościami true, false lub mixed. role="slider" obsługuje aria-valuenow, aria-valuemin, aria-valuemax i opcjonalnie aria-valuetext. role="combobox" obsługuje aria-expanded, aria-controls i aria-activedescendant. Stosowanie aria-checked do role="button" jest bez znaczenia i zostanie zignorowane lub spowoduje mylące wyniki w niektórych czytnikach ekranu.

Ważne są także wymagane właściwości. role="checkbox" bez aria-checked jest nieprawidłowe; stan jest obowiązkowy, a nie opcjonalny. role="slider" bez aria-valuenow powoduje, że użytkownik nie jest w stanie określić bieżącej wartości. Specyfikacja ARIA określa je jako „wymagane stany i właściwości”, a narzędzia sprawdzające zgodność, takie jak axe-core i IBM Equal Access Accessibility Checker, wskazują na ich brak.

Role, drzewo dostępności i obsługa przeglądarek

Przeglądarki tłumaczą funkcje ARIA na interfejsy API dostępności platformy (UIA w systemie Windows, AXAPI w systemie macOS, ATK/AT-SPI w systemie Linux), a czytniki ekranu korzystają z tych interfejsów API. Rola, której nie przypisuje poprawnie żadna przeglądarka, jest praktycznie niewidoczna dla użytkowników.

Obsługa różni się w zależności od funkcji i przeglądarki. Podstawowe funkcje, takie jak „Przycisk”, „Link”, „Nagłówek”, „Lista” i „Nawigacja” są obsługiwane uniwersalnie. Nowsze lub bardziej wyspecjalizowane role („feed”, „math”, „doc-footnote” z modułu WAI-ARIA firmy Digital Publishing) mają bardziej niejednolitą obsługę. Funkcja role=“switch” jest obsługiwana w nowoczesnych przeglądarkach, ale została niekonsekwentnie ogłoszona dziesięć lat temu.

Powiązane: IAAP CPACC / WAS Certification — La certificación profesional que acredita tu experiencia en accesibilidad.

Testowanie rzeczywistych kombinacji używanych przez odbiorców pozostaje niezbędne. Widżet działający w NVDA w przeglądarce Firefox może zachowywać się inaczej w VoiceOver w przeglądarce Safari, ponieważ oba czytniki ekranu korzystają z różnych interfejsów API platformy i stosują inną heurystykę.

Role charakterystyczne i struktura strony

Role charakterystyczne umożliwiają użytkownikom czytników ekranu przechodzenie bezpośrednio do obszarów strony. Osiem charakterystycznych ról to banner, complementary, contentinfo, form, main, navigation, region i search. Współczesny HTML ma dla większości natywne odpowiedniki: <header> staje się banerem, <footer> staje się contentinfo, <main> staje się głównym, <nav> staje się nawigacją, <aside> staje się uzupełniającym, <form> z dostępną nazwą staje się formą, a <sekcja> z dostępną nazwą staje się regionem.

Preferowane jest używanie elementów natywnych, ponieważ działają one nawet w przypadku niepowodzenia CSS lub JavaScript i ponieważ zmniejszają ryzyko konfliktów ról/atrybutów. Punkt orientacyjny „wyszukiwanie” nie ma natywnego odpowiednika w formacie HTML, więc „role=“search” jest nadal właściwym wyborem dla regionu wyszukiwania.

Warto zobaczyć: UserWay — Widżet umożliwiający dostęp do planu za darmo dla każdego użytkownika.

Częstym błędem jest zastosowanie role="banner" do <div> znajdującego się wewnątrz <main> lub <article>. Role punktów orientacyjnych tworzą punkty orientacyjne tylko wtedy, gdy nie są zagnieżdżone w niektórych innych rolach; „baner” wewnątrz „głównego” nie będzie w ogóle wyświetlany jako punkt orientacyjny. Lokalizacja w DOM jest równie ważna jak wartość roli. Dla tych, którzy zastanawiają się, jakie są role arii, te punkty orientacyjne stanowią kluczową część specyfikacji.

Role regionu na żywo

Rozważając role arii, role regionalne na żywo ogłaszają zmiany w treści bez zmiany punktu skupienia. Cztery funkcje obszaru aktywnego to „alert”, „status”, „log” i „timer”, a także bardziej ogólna „marquee”. Każdy z nich domyślnie ma wartość „aria-live”: „alert” i „log” w praktyce oznaczają odpowiednio „asertywny” i „uprzejmy”, podczas gdy „status” oznacza „uprzejmy”.

Wybór pomiędzy „alarmem” a „stanem” jest decyzją projektową mającą realne konsekwencje. „Alert” zatrzymuje wszystko, co czyta czytnik ekranu, co jest odpowiednie w przypadku błędów i pilnych powiadomień, ale szkodliwe w przypadku nadmiernego użycia. „Status” oczekuje na pauzę, która zbiega się z komunikatami o postępie i tekstami potwierdzającymi.

Aktywne regiony muszą istnieć w DOM, zanim zawartość ulegnie zmianie. Jednoczesne wstawienie elementu role="alert" i jego tekstu często skutkuje brakiem ogłoszenia, ponieważ region nie istniał w momencie zmiany. Niezawodny wzorzec polega na renderowaniu pustego aktywnego obszaru podczas ładowania strony i późniejszej aktualizacji jego zawartości tekstowej.

Kiedy NIE używać ról ARIA

Druga zasada korzystania z ARIA jest taka, że autorzy nie powinni zmieniać natywnej semantyki, chyba że naprawdę tego potrzebują. Piąta zasada mówi, że każdy element interaktywny, niezależnie od jego funkcji, musi być dostępny i możliwy do skupienia za pomocą klawiatury.

Dodanie roli nie dodaje zachowania. role="button" na <div> powoduje, że nie skupia się, nie reaguje na wprowadzanie znaków lub spację i nie wysyła formularza. Musisz dodać tabindex="0", procedurę obsługi naciśnięć klawiszy dla wprowadzania danych i spacji oraz często „odpowiednie do roli” zarządzanie stanem. W tym momencie użycie prawdziwego <button> wymaga mniej kodu i mniej błędów.

Niektóre role są aktywnie szkodliwe, jeśli są źle stosowane. role="presentation" i role="none" usuwają semantykę z elementu i, w niektórych implementacjach, z jego wymaganych potomków. Zastosowanie role="application" przełącza czytniki ekranu w tryb, w którym przestają przechwytywać naciśnięcia klawiszy, co może uwięzić użytkowników, jeśli obsługa niestandardowej klawiatury nie jest kompletna.

Ramy decyzyjne dotyczące wyboru ról

Przepracowanie krótkiej sekwencji zapobiega większości błędów roli ARIA. Aby zrozumieć, czym są role ARIA i jak z nich korzystać, wykonaj następujące kroki:

1. Określ widżet lub region. Nazwij prostym językiem, czym właściwie jest element.
2. Sprawdź, czy istnieje natywny odpowiednik HTML. Sprawdź mapowanie HTML-AAM. Jeśli <przycisk>, <wybierz>, <szczegóły> lub <dialog> pasuje, użyj go.
3. Jeśli żaden element natywny nie pasuje, wybierz najbliższą rolę ARIA. Sprawdź, czy istnieje w bieżącej specyfikacji i czy nie jest abstrakcyjny.
4. Dodaj wymagane stany i właściwości. Sprawdź definicję roli pod kątem obowiązkowych atrybutów.
5. Zaimplementuj wzorzec interakcji z klawiaturą. Postępuj zgodnie z Przewodnikiem po praktykach autorskich WAI-ARIA dla typu widżetu.
6. Przetestuj z co najmniej dwoma kombinacjami czytnika ekranu i przeglądarki. Sprawdź ogłoszenia, stany i przepływ klawiatury.

W krokach od trzeciego do szóstego pojawia się większość błędów niestandardowych widgetów. Pominięcie wzorca klawiatury w kroku piątym tworzy widżet, który reklamuje się poprawnie, ale nie działa, co jest prawdopodobnie gorsze niż brak ARIA.

Narzędzia do testowania i walidacji

Zautomatyzowane narzędzia wykrywają błędy strukturalne: nieprawidłowe wartości ról, brakujące wymagane właściwości i role przypisane do elementów, które ich nie obsługują. axe-core, silnik wielu rozszerzeń przeglądarki, sprawdza zdefiniowany podzbiór reguł ARIA. Narzędzie IBM Equal Access Accessibility Checker i narzędzie Nu HTML Checker W3C również pokazują nadużycia ról.

Zautomatyzowane narzędzia nie mogą sprawdzić, czy rola generuje prawidłowe ogłoszenie lub czy działa interakcja za pomocą klawiatury. Nadal wymagane jest ręczne testowanie za pomocą NVDA i Firefoksa, JAWS i Chrome lub VoiceOver i Safari. Rozszerzenie Accessibility Insights for Web łączy automatyczne kontrole z ręczną oceną z przewodnikiem, która obejmuje weryfikację za pomocą klawiatury i czytnika ekranu.

Sama specyfikacja ARIA, Przewodnik po praktykach autorskich WAI-ARIA i dokument mapujący HTML-AAM stanowią wiarygodne odniesienia do ról arii. Dokument MDN Web Docs ARIA Reference to wygodne i dobrze wybrane źródło dodatkowe, które zawiera odniesienia do specyfikacji każdej roli.

Kluczowe wnioski

• Role ARIA deklarują, czym jest element; WAI-ARIA 1.2 definiuje 87 ról w sześciu kategoriach, a abstrakcyjne role mogą nigdy nie pojawić się w znacznikach.
• Natywne elementy HTML mają ukryte role i wbudowane zachowania, więc pierwszą zasadą podczas korzystania z ARIA jest preferowanie ich zamiast div plus role.
• Role wymagają obsługiwanych stanów i właściwości: role="checkbox" bez aria-checked jest nieprawidłowe i nie można ich użyć.
• Dodanie roli nigdy nie dodaje zachowania klawiatury ani możliwości skupienia; należy je wdrożyć i przetestować oddzielnie.
• Role Punkt orientacyjny i Aktywny region mają reguły dotyczące lokalizacji i czasu, które określają, czy działają, czy nie.
• Zautomatyzowani inspektorzy wykrywają jedynie błędy strukturalne; nadal wymagane jest testowanie czytników ekranu dla różnych kombinacji przeglądarek.

Aby zrozumieć, jakie są role ARIA, pamiętaj, że definiują one cel elementu technologii wspomagającej.

Źródła i dalsze lektury

• WAI-ARIA — Wikipedia: Inicjatywa na rzecz dostępności sieci – dostępne bogate aplikacje internetowe (WAI-ARIA) to specyfikacja techniczna opublikowana przez konsorcjum World Wide Web Consortium (W3C), która…

Często zadawane pytania

Czym w skrócie są role ARIA?

Role ARIA to etykiety dołączane do elementów HTML w celu poinformowania technologii wspomagającej, co reprezentuje dany element. <div role="button"> jest ogłaszane jako przycisk, a nie jako ogólny tekst. Role dostarczają znaczenia, którego nie zapewnia podstawowy tag, ale same nie dodają żadnego zachowania, obsługi fokusu ani obsługi klawiatury.

Jaka jest różnica między rolami ARIA a atrybutami ARIA?

Role opisują typ elementu, natomiast atrybuty opisują jego stan, wartość lub relacje. role="slider" identyfikuje suwak; aria-valuenow="50" podaje jego aktualną pozycję, a aria-labelledby wskazuje na jego etykietę. Role i atrybuty są używane razem, a każda rola definiuje, które atrybuty obsługuje.

Ile jest ról ARIA?

WAI-ARIA 1.2 definiuje 87 ról pogrupowanych w sześć kategorii: abstrakcyjne, widżety, struktura dokumentu, punkty orientacyjne, regiony na żywo i okna. Abstrakcyjne role, takie jak „widget” i „input”, istnieją tylko dla wewnętrznej taksonomii specyfikacji i nigdy nie powinny być zapisywane w HTML. Liczba ta rośnie wraz z każdą zmianą specyfikacji.

Czy powinienem używać ról ARIA zamiast semantycznego HTML?

Nie. Pierwsza zasada użycia ARIA mówi, że należy preferować natywny element HTML, jeśli taki istnieje, z wymaganą semantyką i zachowaniem. Użyj <button> zamiast <div role="button"> i <nav> zamiast <div role="navigation">. Role ARIA stanowią rozwiązanie awaryjne w przypadkach, gdy nie istnieje odpowiedni element natywny.

Czy role ARIA działają we wszystkich przeglądarkach i czytnikach ekranu?

Podstawowe role, takie jak button, link, heading i navigation są niezawodnie obsługiwane przez nowoczesne przeglądarki i czytniki ekranu. Nowsze lub bardziej wyspecjalizowane role, w tym te w module Digital Publishing, zapewniają bardziej zmienne wsparcie. Tylko testując konkretną kombinację przeglądarki i czytnika ekranu, z których korzystają Twoi odbiorcy, możesz mieć pewność.

Czy dodanie roli ARIA może popsuć dostępność?

Tak. Nadpisanie roli domyślnej może spowodować utratę użytecznej semantyki, na przykład w przypadku zastosowania role="presentation" do tabeli danych. Zastosowanie role="application" może zablokować użytkowników, jeśli obsługa klawiatury jest niekompletna. Zbędne role w elementach natywnych powodują niepotrzebny hałas i czasami prowadzą do sprzecznych komunikatów.