Lista ról ARIA: porównanie najlepszych referencji

Lista ról ARIA zawiera 82 wartości zdefiniowanych w specyfikacji WAI-ARIA 1.2 W3C, zorganizowanych w sześć kategorii funkcjonalnych: role dokumentu, punktów orientacyjnych, widżetów, struktury, okien i ról abstrakcyjnych. Wybór odpowiedniego źródła referencyjnego zależy od tego, czy potrzebujesz szybkiej tabeli, dokumentacji z przykładami kodu, czy przewodnika decyzyjnego dotyczącego zastosowania każdej roli.

Kluczowe wnioski

• Specyficzna wersja WAI-ARIA 1.2 definiuje 82 role, ale w codziennej praktyce tworzenia dostępnych stron XHTML/CSS używa się tylko niewielkiego podzbioru.
• Pierwsza zasada ARIA pozostaje w mocy: jeśli istnieje natywny element HTML o semantyce, której potrzebujesz, użyj go zamiast dodawać rolę.
• Role abstrakcyjne (takie jak role="widget" lub role="input") nigdy nie powinny być wpisywane w kodzie; służą one jedynie jako baza taksonomiczna.
• Przydatna referencja dla front-endu powinna zawierać rolę, jej obowiązkowe atrybuty ARIA, dozwolone stany oraz przykład rzeczywistego kodu.
• Role punktów orientacyjnych i widżetów koncentrują większość błędów wykrywanych przez automatyczne narzędzia audytowe, takie jak axe-core czy Lighthouse.

Czym jest rola ARIA i dlaczego potrzebujesz wiarygodnej listy

Rola ARIA to wartość przypisywana elementowi za pomocą atrybutu role, aby poinformować technologie wspomagające, jaki typ komponentu reprezentuje. Przeglądarka przekazuje tę rolę do drzewa dostępności, a czytnik ekranu, taki jak NVDA, JAWS lub VoiceOver, tłumaczy ją na konkretny komunikat: „przycisk”, „karta”, „region”, „okno dialogowe”.

La especificación WAI-ARIA, mantenida por el W3C dentro del grupo de trabajo ARIA, definiuje każdą rolę wraz z dozwolonymi atrybutami stanu i właściwości. La wersja 1.2 to obecną stabilną rekomendacją, a ARIA 1.3 se encuentra en desarrollo. Dla programisty pracującego z XHTML i CSS lista ról nie jest katalogiem dekoracyjnym: każda błędnie zastosowana wartość generuje konflikt między semantyką natywną elementu a zadeklarowaną, a czytniki ekranu rozwiązują ten konflikt w różny sposób w zależności od przeglądarki.

Oficjalna dokumentacja ról ARIA w MDN (Mozilla Developer Network) jest najczęściej konsultowaną referencją techniczną w języku hiszpańskim i angielskim, ale nie jest jedyną. Istnieją arkusze referencyjne, przewodniki po wzorcach i narzędzia walidacyjne, które zaspokajają różne potrzeby. Ich porównanie pomaga wybrać to, które najlepiej pasuje do Twojego przepływu pracy.

Sześć kategorii ról ARIA

Oficjalna taksonomia grupuje role według ich funkcji. Znajomość kategorii pozwala uniknąć szukania w niewłaściwej liście.

Role dokumentu. Opisano strukturę strony lub sekcji: article, dokument, feed, heading, img, list, listitem, math, none, note, presentation, row, separator, table, term, toolbar, tooltip. Wiele z nich duplikuje natywne elementy HTML, dlatego rzadko są wpisywane ręcznie.

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

Role punktów orientacyjnych (Landmark roles). Zdefiniuj obszary strony, po których można nawigować: banner, complementary, contentinfo, form, main, navigation, region, search. Jest to najczęściej używane w witrynach z niekompletną semantyką HTML.

Role widżetów (Widget roles). Reprezentuje interaktywne elementy sterujące: button, “button, checkbox, gridcell, link, menuitem, menuitemcheckbox, menuitemradio, option, progressbar, radio, scrollbar, searchbox, slider, spinbutton, switch, tab, tabpanel, textbox, treeitem`. Wymaga skupienia i zarządzania klawiaturą.

Role struktury (Structure roles). Widżety organizacji obejmują: aplikacja, grid, grupa, listbox, menu, menubar, radiogroup, tablista, drzewo, treegrid, rowgroup, columnheader, rowheader.

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

Role okien (Window roles). Nałożone lub modalne zarządzanie treścią: alertdialog, dialog.

Role abstrakcyjne. W znacznikach nie są zapisane żadne elementy: polecenie, composite, input, landmark, range, roletype, section, sectionhead, select, structure, widget, window. Służą one do dziedziczenia właściwości między rolami w specyfikacji.

Porównanie: najlepsze referencje ról ARIA

Poniższa tabela porównuje referencje najczęściej używane przez programistów według kryteriów praktycznych.

Referencje	Typ	Języki	Przykłady kodu	Idealne dla
Dokumenty internetowe MDN (Role ARIA)	Oficjalna dokumentacja	Wielojęzyczność (w tym hiszpański)	Tak, dla każdej roli	Głęboka analiza techniczna
WAI-ARIA 1.2 (W3C)	Specyfikacja normatywna	Angielski	Nie	Weryfikacja dokładnego zachowania
Przewodnik po praktykach autorskich WAI-ARIA	Przewodnik po wzorcach	Angielski	Tak, pełne wzorce	Implementacja widżetów z obsługą klawiatury
Ściągawka z referencjami	Tabela podsumowująca	Angielski	Minimalne	Szybka powtórka w edytorze
accessibility.build (odniesienia ARIA)	Referencje praktyczne	Angielski	Si	Nauka na przykładach z komentarzami
Audytory (axe-core, Lighthouse)	Herramienta	Wielojęzyczny	Nie	Wykrywanie nieprawidłowych ról

Wybór zależy od momentu. Podczas pisania kodu kompaktowa ściągawka wygrywa szybkością. Podczas debugowania widżetu, który nie ogłasza poprawnie swojego stanu, specyfikacja W3C i przewodnik wzorców WAI są źródłami, które rozwiązują problem.

Jak zdecydować, którą rolę zastosować: kryteria praktyczne

Właściwa decyzja prawie zawsze zaczyna się od odrzucenia ARIA. Poniższe kryteria, ułożone w kolejności, pozwalają uniknąć większości błędów.

1. Czy istnieje natywny element HTML? <button> posiada już domyślną rolę button. Dodanie role="button" jest zbędne i może powodować konflikty.
2. Czy rola wymaga obowiązkowych atrybutów? role="checkbox" wymaga aria-checked. role="slider" wymaga aria-valuenow, aria-valuemin i aria-valuemax. Jeśli nie potrafisz utrzymać tych stanów, rola bardziej szkodzi niż pomaga.
3. Czy rola wiąże się z zarządzaniem klawiaturą? Role widżetów wymagają nawigacji za pomocą strzałek, Home, End i Esc, w zależności od wzorca. role="tablist" bez obsługi strzałek jest gorsza niż jej brak.
4. Czy rola jest abstrakcyjna? Jeżeli znajduje się na liście ról abstrakcyjnych, nie należy go wpisywać.
5. Czy ta rola jest przestarzała lub nieużywana? Niektóre wartości zostały zmienione pomiędzy ARIA 1.0 i 1.2. Zawsze sprawdzaj aktualną wersję.

Pierwszą zasadą korzystania z ARIA, uznaną w przewodniku po technikach W3C, jest zasada: używaj natywnego HTML, kiedy tylko jest to możliwe. ARIA to łatka, gdy HTML nie wystarczy, a nie substytut.

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

Częste błędy przy sprawdzaniu i stosowaniu listy ról

Typowym błędem jest kopiowanie roli ze ściągawki bez sprawdzenia wymaganych atrybutów. role="combobox" w wersji ARIA 1.2 zmienił się względem 1.0 i teraz oczekuje aria-expanded oraz relacji z listbox za pomocą aria-controls. Zastosowanie starej wersji psuje ogłoszenia w aktualnych czytnikach.

Powszechnie używa się również role="presentation" lub role="none" do „oczyszczenia” semantyki bez zrozumienia, że ​​usuwa to element z drzewa dostępności, a w niektórych przypadkach także jego dzieci. Pojawia się to również przy częstym nadużywaniu role="application", która przenosi całą kontrolę klawiatury do widżetu i wyłącza skróty czytnika ekranu; jest zarezerwowany dla złożonych aplikacji internetowych, a nie dla formularzy.

Zduplikowane role punktów orientacyjnych powodują zamieszanie: dwie role role="main" na jednej stronie lub role="banner" wewnątrz <article> sprawiają, że nawigacja po regionach staje się niespójna. Walidacja za pomocą axe-core lub narzędzi dostępności w przeglądarce wykrywa wiele z tych przypadków, choć żadne automatyczne narzędzie nie zastąpi testu z prawdziwym czytnikiem ekranu.

Warto zobaczyć: Deque axe DevTools Pro — El estándar de la industria para testear accesibilidad durante el desarrollo.

Narzędzia do walidacji ról w kodzie

Weryfikacja ról łączy inspekcję ręczną z automatyzacją. DevTools w Chrome i Firefox zawierają panel dostępności, który pokazuje drzewo w taki sposób, w jaki otrzymuje je system operacyjny, wraz z obliczoną rolą każdego węzła. To najprostszy sposób, aby sprawdzić, czy zadeklarowana rola zostaje zachowana, czy zostaje nadpisana przez semantykę natywną.

axe-core, zintegrowany z Lighthouse i dostępny jako rozszerzenie, oznacza nieprawidłowe role, brakujące atrybuty obowiązkowe oraz sprzeczne kombinacje. Rozszerzenie Accessibility Insights for Web, oparte na regułach axe, dodaje prowadzone sprawdzanie. W przypadku testów z rzeczywistymi użytkownikami, NVDA na Windows i VoiceOver na macOS oferują ostateczną weryfikację: żaden walidator nie wykryje, czy ogłoszenie jest zrozumiałe w danym kontekście.

Dokumentacja dostępności MDN oraz przewodnik wzorców WAI-ARIA W3C to dwa źródła, które warto mieć otwarte podczas programowania. Pierwsze wyjaśnia każdą rolę, drugie pokazuje, jak łączą się one w kompletne komponenty.

Ź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

Ile istnieje ról ARIA?

Specyfikacja W3C WAI-ARIA 1.2 definiuje w sumie 82 role, podzielone na role dokumentu, punktu orientacyjnego, widżetu, struktury, okna i abstrakcyjnego. W tym kontekście w zwykłym programowaniu używana jest tylko część: role abstrakcyjne nigdy nie są zapisywane, a wiele ról dokumentów powiela natywne elementy HTML.

Jaka jest różnica między rolą ARIA a atrybutem ARIA?

Rola ARIA opisuje, czym jest element, podczas gdy atrybuty ARIA opisują jego stan lub właściwości. Na przykład role="checkbox" identyfikuje komponent, a aria-checked="true" informuje, czy jest on zaznaczony. Role przypisuje się za pomocą atrybutu role; stany i właściwości używają prefiksu aria-.

Czy powinienem używać ARIA, jeśli używam semantycznego HTML-a?

W większości przypadków nie. Semantyczny HTML już udostępnia ukryte role: <nav> jest równoważne role="navigation", a <main> jest równoważne role="main". Dodanie roli jawnie jest zbędne i może powodować konflikty. ARIA jest zarezerwowana dla komponentów, których HTML nie obejmuje, takich jak karty, drzewa lub złożone menu.

Których ról ARIA nigdy nie należy wpisywać w kodzie?

Abstrakcyjne role nie powinny nigdy pojawiać się: command, composite, input, landmark, range, roletype, section, sectionhead, select, structure, widget i window. Istnieją tylko dla specyfikacji definiującej dziedziczenie właściwości pomiędzy rolami. Zapisanie ich powoduje nieprawidłową rolę, która jest oznaczana przez walidatory.

Jak sprawdzić, czy rola ARIA działa poprawnie?

Weryfikacja składa się z trzech etapów: sprawdzenia drzewa dostępności w DevTools przeglądarki w celu potwierdzenia obliczonej roli, przekazania walidatora, takiego jak axe-core, w celu wykrycia brakujących obowiązkowych atrybutów oraz przetestowania z prawdziwym czytnikiem ekranu, takim jak NVDA lub VoiceOver. Dopiero ostatni krok potwierdza, że ​​ogłoszenie jest dla danej osoby zrozumiałe.

Czy role ARIA zmieniają się między wersjami specyfikacji?

Tak. ARIA 1.1 dodała role takie jak feed i switch, a ARIA 1.2 zmodyfikowała zachowanie combobox i skonsolidowała inne wartości. ARIA 1.3 jest w fazie rozwoju. Zawsze sprawdzaj aktualną wersję specyfikacji, aby uniknąć stosowania przestarzałych wzorców, które nowoczesne czytniki ekranu interpretują inaczej.