Przykłady ról ARIA: kompletny przewodnik

Przykłady ról ARIA pokazują, w jaki sposób atrybuty ról odwzorowują elementy interfejsu na drzewo dostępności, a specyfikacja WAI-ARIA 1.2 definiuje 6 kategorii ról — widżet, struktura dokumentu, punkt orientacyjny, region na żywo, okno i abstrakcyjne — obejmujących ponad 80 konkretnych ról. W tym przewodniku przedstawiono gotowe do skopiowania praktyczne przykłady dla każdej kategorii, a także zasady określające, kiedy rola pomaga, a kiedy aktywnie szkodzi.

Kluczowe wnioski

• Role ARIA informują technologię wspomagającą, czym jest przedmiot; nigdy nie dodają samodzielnie zachowania, skupienia ani obsługi klawiatury.
• Pierwszą zasadą korzystania z ARIA jest preferowanie natywnych elementów HTML, które już zawierają ukryte role, stany i zarządzanie klawiaturą.
• Sześć kategorii ról WAI-ARIA 1.2 to widżet, struktura dokumentu, punkt orientacyjny, region na żywo, okno i abstrakcyjne — role abstrakcyjne nigdy nie powinny pojawiać się w znacznikach.
• Role charakterystyczne to najbardziej opłacalne i charakteryzujące się najniższym ryzykiem ARIA, jakie można dodać do istniejącej witryny XHTML/CSS.
• Role widżetów prawie zawsze wymagają mapowania JavaScript do interakcji z klawiaturą i obsługi stanu, w przeciwnym razie powodują gorsze wrażenia niż zwykły HTML.
• Zweryfikuj każdą rolę za pomocą czytnika ekranu i automatycznego modułu sprawdzającego; prawidłowa rola w specyfikacji może nadal być niewłaściwa dla Twojej treści.

Czym właściwie są role ARIA

Role ARIA to tokeny umieszczane w atrybucie „role” w celu zastąpienia lub zapewnienia tożsamości semantycznej elementu w drzewie dostępności. <div role="button"> informuje czytnik ekranu, aby ogłosił „przycisk”, ale przeglądarka nadal traktuje go jako ogólny kontener: nie można go skupić, nie reaguje na Enter ani spację i nie ma stanu wyłączonego. Ta luka pomiędzy reklamowaną semantyką a rzeczywistym zachowaniem jest najczęstszą przyczyną niepowodzeń ARIA. Oto typowe przykłady ról ARIA pokazujące, jak semantyka może odbiegać od zachowania.

Specyfikacja WAI-ARIA, prowadzona przez Grupę Roboczą ds. Dostępnych Bogatych Aplikacji Internetowych W3C, definiuje role, a także stany i właściwości. Role to warstwa „co to jest”; stany i właściwości, takie jak „aria-rozwinięta”, „aria-sprawdzona” i „aria-label” to warstwa „w jakim stanie się ona znajduje”. Rola bez wymaganych stanów jest niekompletna — role="checkbox" wymaga aria-checked, a role="combobox" wymaga aria-expanded i kontrolowanego pola listy.

Natywne elementy HTML pełnią ukryte role. <button> odpowiada roli przycisku, <nav> nawigacji, <h1> do <h6> nagłówkowi, a <input type="checkbox"> roli pola wyboru. Ponieważ przeglądarka automatycznie udostępnia rolę, zachowanie klawiatury i stan, pierwszą zasadą używania ARIA – udokumentowaną w Przewodniku po praktykach tworzenia ARIA W3C – jest używanie natywnej semantyki, gdy istnieje równoważny element. Szukaj wyraźnych ról tylko wtedy, gdy żaden element natywny nie jest odpowiedni, na przykład niestandardowy widok drzewa lub panel z kartami zbudowany z <div>.

Sześć kategorii ról WAI-ARIA

WAI-ARIA 1.2 dzieli role na sześć kategorii, a wiedza, do której kategorii należy dana rola, informuje Cię, ile zawdzięczasz JavaScriptowi. Oto kilka typowych przykładów ról arii:

Kategoria	Cel	Przykładowe role	Wymagany JavaScript?
Widżet	Interaktywne sterowanie	przycisk, pole wyboru, tab, suwak, combobox	Tak — klawiatura + stan
Struktura dokumentu	Organizacja treści	nagłówek, lista, listitem, tabela, artykuł	Nie
Punkt orientacyjny	Regiony strony do nawigacji	baner, główny, nawigacja, uzupełniający	Nie
Region na żywo	Ogłoś aktualizacje dynamiczne	alert, status, log, timer	Zwykle — aby wywołać aktualizacje
Okno	Podokna i okna dialogowe	dialog, alertdialog	Tak — zarządzanie fokusem
Abstrakcyjne	Role superklasowe, nigdy nieautorskie	widżet, wejście, sekcja, punkt orientacyjny	Nie dotyczy — nie używać

Role abstrakcyjne istnieją jedynie w celu uporządkowania taksonomii. Zapisanie role="input" lub role="section" w kodzie HTML powoduje błąd sprawdzania poprawności i powoduje nieprzewidywalne powiadomienia, ponieważ te role nie mają zdefiniowanego zachowania dla technologii wspomagającej.

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

Przykłady ról charakterystycznych

Role charakterystyczne to najbezpieczniejsze i najbardziej wpływowe przykłady ról ARIA, które możesz dodać do starszej witryny XHTML/CSS, ponieważ nie wymagają JavaScript i są mapowane bezpośrednio do regionów, które już masz. Typowy szkielet strony:

<header role="banner">
  <nav role="navigation" aria-label="Principal">
    <ul>...</ul>
  </nav>
</nav>
<main role="main">
  <article>...</article>
  <aside role="complementary" aria-label="Artículos relacionados">...</aside>
</main>
<footer role="contentinfo">...</footer>

Każda rola znacznika odpowiada elementowi natywnemu — baner do <header> na najwyższym poziomie, main do <main>, navigation do <nav>, uzupełniający do <boczny>, contentinfo do <stopka>. Kiedy używasz elementu natywnego, rola jest implikowana i nie powinieneś jej powtarzać. Wyraźny atrybut role zyskuje swoje miejsce tylko wtedy, gdy utkniesz w znacznikach <div>, których nie możesz modyfikować, co jest powszechne w starszych szablonach i wynikach CMS.

Należą się tutaj dwa zastrzeżenia. Po pierwsze, baner, main i contentinfo muszą pojawić się raz na stronę; kilka „głównych” punktów orientacyjnych zakłóca nawigację. Po drugie, jeśli istnieje wiele punktów orientacyjnych tego samego typu – powiedzmy trzy elementy „

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