Role i atrybuty ARIA: porównanie najlepszych wyborów
Role i atrybuty ARIA specyfikacji WAI-ARIA 1.2 W3C przekraczają setkę, choć garstka z nich rozwiązuje większość problemów z dostępnością w widżetach XHTML i CSS. Rola definiuje, czym jest element, a atrybut jego stan lub relacje, ale ARIA nie modyfikuje zachowania przeglądarki: każda dodana rola wymaga zaimplementowania interakcji za pomocą JavaScript.
Accessible Rich Internet Applications (ARIA) to specyfikacja W3C, która dodaje semantykę do elementów HTML, które nie mają ich w natywnej formie. Rola opisuje, czym jest element („przycisk”, „zakładka”, „okno dialogowe”), podczas gdy atrybut opisuje jego stan lub jego relacje („aria-expanded”, „aria-controls”, „aria-labelledby”). Pierwsza zasada ARIA, opublikowana przez W3C w Using ARIA, jest brutalna: jeśli istnieje natywny element HTML, który już wykonuje to zadanie, użyj go i nie dodawaj ARIA.
Powodem jest to, że ARIA nie modyfikuje zachowania przeglądarki. <div role="button"> nie jest aktywowany klawiszem Tab, nie reaguje na klawisz Enter lub spację i nie jest przesyłany z formularzem. Zmienia tylko to, co zapowiada technologia wspomagająca.
Cała interakcja musi być implementowana za pomocą JavaScript i ostrożnie zarządzana. W projektach XHTML/CSS, w których kod HTML jest statyczny, a kod JS jest minimalny, oznacza to, że każda dodana rola i atrybut arii stanowi obietnicę, którą Twój kod musi spełnić.
Druga zasada ARIA mówi, aby nie zmieniać natywnej semantyki, chyba że jest to niezbędne. <h2 role="tab"> łamie strukturę nagłówków i dezorientuje czytniki ekranu, które nawigują według regionów. Trzecia zasada wymaga, aby wszystkie elementy sterujące ARIA można było obsługiwać za pomocą klawiatury. Czwarta zasada prosi, aby nie używać aria-hidden="true" na elementach, na których jest fokus. Piąty, najbardziej zapomniany, przypomina nam, że każdy element interaktywny wymaga przystępnej nazwy: rola bez etykiety to przycisk wyciszenia.
Jak wybrać: kryteria przed listą
Wybór roli lub atrybutu nie jest kwestią gustu. Kryteria te, stosowane w kolejności, pozwalają uniknąć większości błędów dotyczących ról i atrybutów arii:
Powiązane: — Widżet umożliwiający dostęp do planu za darmo dla każdego użytkownika.
- Czy istnieje natywny element HTML? Jeśli tak, użyj go.
<button>,<details>,<dialog>,<input type="checkbox">obejmują więcej przypadków, niż się ludziom wydaje. - Czy widget potrzebuje stanów dynamicznych? Jeśli zmienia się pomiędzy otwarty/zamknięty, wybrany/niewybrany lub rozwinięty/zwinięty, potrzebne są atrybuty stanu (
aria-expanded,aria-selected,aria-pressed). - Czy potrzebuje relacji pomiędzy elementami? Atrybuty relacji („aria-controls”, „aria-labelledby”,
aria-describedby, „aria-owns”) łączą elementy, których drzewo dostępności nie może wywnioskować z DOM. - Czy potrzebuje ogłoszeń na żywo? Aktywne regiony (
aria-live,role="status",role="alert") obsługują aktualizacje bez przesuwania fokusu. - Czy mogę to utrzymać? Złożony wzorzec ARIA bez testów klawiatury lub czytnika ekranu jest gorszy niż brak niczego.
Koszt utrzymania jest najczęściej ignorowanym kryterium. Dobrze wykonana role="tablist" wymaga zarządzania klawiszami strzałek, obracania tabindex, synchronizacji aria-selected i aria-controls oraz prawidłowego ukrywania nieaktywnych paneli. Jeśli zespół nie może sobie z tym poradzić, zestaw linków z kotwami jest bardziej dostępny i tańszy.
Porównanie najużyteczniejszych ról ARIA
Następująca tabela podsumowuje role, które pojawiają się raz po raz w rzeczywistych audytach, wraz z ich natywnym odpowiednikiem (jeśli istnieje) i najczęstszą pułapką.
| Rola | Zastosowanie | Alternatywa natywna | Częsta pułapka |
|---|---|---|---|
button | Kontrolka wykonująca akcję | <button> | Brak obsługi Enter/Spacji lub tabindex="0" |
link | Nawigacja do innego adresu URL | <a href> | Używanie do akcji, które nie są nawigacją |
dialog | Okno modalne lub niemodalne | <dialog> | Brak pułapkowania fokusu lub jego zwrotu po zamknięciu |
tablist / tab / tabpanel | Interfejs zakładek | Brak bezpośredniej | Brak synchronizacji aria-selected z widocznym panelem |
menu / menuitem | Menu aplikacji | <select> lub lista linków | Używanie do menu nawigacyjnych strony |
alert | Pilny i natychmiastowy komunikat | role="status" dla mniej pilnych | Nadużywanie i przeciążanie czytnika ekranu |
status | Informacyjna aktualizacja | <output> | Brak wstawienia do DOM przed aktualizacją |
progressbar | Postęp zadania | <progress> | Brak aktualizacji aria-valuenow |
tooltip | Opis wyskakujący | title (ograniczony) | Brak powiązania z aria-describedby |
combobox | Pole z listą sugestii | <datalist> (ograniczony) | Brak ogłaszania liczby wyników |
Wybór pomiędzy role="alert" a role="status" jest dobrym przykładem decyzji z niuansami dotyczącymi ról i atrybutów arii. alert przerywa bieżący odczyt czytnika ekranu; „status” czeka na zakończenie działania użytkownika. W przypadku błędu sprawdzania poprawności formularza odpowiednie jest „alert”. W przypadku „Znaleziono 3 wyniki” podczas pisania użytkownika „status” jest poprawny, a „alarm” powoduje natrętność.
Warto zobaczyć: — Accesibilidad gestionada: automatización cobinada con revisión humana.
Niezbędne atrybuty ARIA i sposób ich łączenia
Atrybuty są powiązane z czterema rodzinami i każda z nich rozwiązuje inny problem.
Etiquetado. „aria-label” podaje nazwę, gdy nie ma widocznego tekstu. aria-labelledby odwołuje się do id innego elementu i jest preferowane, gdy tekst już istnieje na ekranie, ponieważ utrzymuje jedno źródło prawdy. aria-describedby dodaje dłuższy opis, taki jak tekst pomocy pola. Różnica ma znaczenie: nazwa jest tym, co użytkownik słyszy po skupieniu; opis jest dodatkowym kontekstem, który można przerwać.
Estados. aria-expanded (prawda/fałsz) dla akordeonów i menu rozwijanych. aria-selected dla zakładek i opcji. „aria-checked” dla niestandardowych pól wyboru, z wartością „mixed” dla stanów trójstanowych. „aria-pressed” dla przycisków przełączania. „aria-disabled”, gdy element nadal można aktywować, ale nie można go używać, w przeciwieństwie do natywnego atrybutu „disabled”, który usuwa go z kolejności tabulacji.
Relacje. „aria-controls” wskazuje, którym elementem steruje przycisk. aria-owns' reorganizuje drzewo dostępności, gdy DOM nie odzwierciedla relacji wizualnej. aria-activedescendant` pozwala utrzymać skupienie na kontenerze podczas ogłaszania aktywnego elementu, co jest powszechnym wzorcem w comboboxach.
Regiony aktywne. aria-live="polite" lub "asertywny" definiują pilność. aria-atomic="true" powoduje, że ogłaszany jest cały blok, a nie tylko jego zmodyfikowana część. aria-relevant filtruje, które zmiany są ogłaszane.
Często pomijany szczegół: atrybuty ARIA działają tylko na elementach z prawidłową rolą. aria-expanded na <div> bez roli nie zostanie ogłoszone. Wartości logiczne ARIA to ciągi tekstowe („prawda”, „fałsz”), a nie wartości logiczne JavaScript; zapisanie aria-expanded="false" jako właściwości logicznej spowoduje niespójne wyniki.
Powiązane: — La certificación profesional que acredita tu experiencia en accesibilidad.
Błędy, które rujnują dostępność widżetu
Najkosztowniejszym błędem jest używanie ARIA do naprawy źle ustrukturyzowanego HTML-a. Dodanie role="navigation" do <div>, gdy dostępny był już element <nav>, duplikuje regiony i dezorientuje nawigację po punktach orientacyjnych (landmarks).
Drugim błędem jest skupienie. Widżet modalny, który nie przesuwa fokusu po otwarciu, nie zatrzymuje go, gdy jest otwarty i nie zwraca go do wyzwalacza po zamknięciu, pozostawia użytkownika klawiatury nawigującego po niewidocznej zawartości. Natywny element <dialog> rozwiązuje część tego problemu, ale nie wszystko: za przywrócenie fokusu nadal odpowiada programista.
Trzecim błędem jest ukrywanie za pomocą aria-hidden elementów, które nadal można ogniskać. Zamknięte menu z aria-hidden="true", ale bez display: none lub visibility: hidden, utrzymuje linki w kolejności tabulacji, przez co użytkownik trafia na elementy, których nie widzi. Poprawną kombinacją jest jednoczesne ukrycie wizualne i usunięcie z drzewa dostępności.
Czwartym błędem jest brak dostępnej nazwy. <przycisk> z pojedynczą ikoną SVG wymaga aria-label lub <span class="visually-hidden"> z tekstem. Dekoracyjny plik SVG wymaga parametrów aria-hidden="true" i focusable="false", dlatego Internet Explorer i niektóre starsze przeglądarki nie uwzględniają ich w kolejności tabulacji.
Narzędzia do testowania ról i atrybutów ARIA
Nie ma innego narzędzia niż testowanie z użyciem rzeczywistego czytnika ekranu, ale kombinacja różnych narzędzi pozwala wykryć większość błędów w rolach i atrybutach arii.
Weryfikacja statyczna. Walidator W3C ARIA (część Nu HTML Checker) wykrywa nieistniejące role, źle napisane atrybuty i zabronione kombinacje. ax DevTools i Lighthouse wskazują role bez dostępnych nazw i brakujących obowiązkowych atrybutów.
Inspekcja drzewa dostępności. Narzędzia deweloperskie Chrome i Firefox pozwalają zobaczyć drzewo dostępności dokładnie tak, jak jest odbierane przez technologię wspomagającą. Jest to najszybszy sposób sprawdzenia, czy rola rzeczywiście została zastosowana i jaką dostępną nazwę obliczyła przeglądarka.
Testowanie ręczne. Poruszaj się po całym widżecie tylko za pomocą klawiatury (Tab, Shift+Tab, strzałki, Enter, Spacja, Escape), a następnie za pomocą NVDA w systemie Windows, JAWS, jeśli jest dostępny, lub VoiceOver na macOS i iOS. Połączenie czytnika stacjonarnego i mobilnego sprawdza się w większości rzeczywistych przypadków.
Dokumentacja referencyjna. Przewodnik W3C ARIA Authoring Practices Guide (APG) zawiera kompleksowe wzorce z przykładami klawiatury i kodu. Jest to źródło, z którym należy zapoznać się przed wymyśleniem nowego wzoru.
Jak decydować w rzeczywistym projekcie XHTML/CSS
W witrynach XHTML z lekkim CSS i JavaScript najbardziej opłacalną strategią jest rozpoczęcie od natywnego HTML i dodanie ARIA tylko tam, gdzie natywny nie dociera. Formularz z poprawnymi <label>, <fieldset> i <legend> wymaga bardzo małej ilości ARIA. Tabela danych z <th scope> również tego nie robi. Role ARIA pojawiają się, gdy pojawiają się wzorce, których HTML nie obejmuje: karty, akordeony, comboboxy z filtrowaniem, modalne okna dialogowe i dynamiczne powiadomienia.
Zaleca się udokumentowanie każdego użycia ról i atrybutów ARIA w samym kodzie komentarzem wyjaśniającym, dlaczego się tam znalazły. Kiedy ktoś dokona refaktoryzacji komponentu sześć miesięcy później, będzie wiedział, czy „aria-controls” jest nadal konieczna, czy też została osierocona. Osierocone atrybuty ARIA — które wskazują na identyfikatory, które już nie istnieją — są cichym źródłem błędów, których żaden walidator nie wykrywa wiarygodnie.
Na koniec traktuj dostępność jako część definicji „ukończenia” komponentu, a nie jako kolejny audyt. Widżet z rolami ARIA testowany z klawiaturą i czytnikiem ekranu od pierwszego zatwierdzenia kosztuje znacznie mniej niż naprawiany po audycie.
Kluczowe wnioski
- Role i atrybuty ARIA nie dodają zachowania: rola bez zarządzania klawiaturą i fokusem jest gorsza niż brak niczego.
- Pierwszą zasadą ARIA jest używanie natywnego HTML, jeśli taki istnieje;
<przycisk>,<dialog>i<szczegóły>obejmują więcej przypadków, niż mogłoby się wydawać. - Atrybuty są pogrupowane według etykiet, stanów, relacji i aktywnych regionów; każda rodzina rozwiązuje inny problem.
role="alert"przerywa, arole="status"czeka: nieprawidłowy wybór obciąża użytkownika czytnikiem ekranu.- Wartości logiczne ARIA są ciągami znaków („prawda”/`„fałsz”), a atrybuty działają tylko na elementach z prawidłową rolą.
- Testowanie za pomocą klawiatury i prawdziwego czytnika ekranu jest obowiązkowe; walidatory wykrywają tylko część błędów.
Ź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
¿Cuál es la diferencia entre un rol y un atributo ARIA?
Rola określa, czym jest element w technologii wspomagającej, np. role="tab" lub role="dialog". Atrybut opisuje jego stan lub relacje, takie jak „aria-expanded” lub „aria-labelledby”. Role są stosowane do elementu reprezentującego komponent; atrybuty są zwykle stosowane do tego samego elementu lub tych, które są z nim powiązane.
Kiedy powinienem użyć ARIA zamiast natywnego HTML-a?
Tylko wtedy, gdy nie ma elementu HTML zakrywającego wzorzec. Pierwsza zasada W3C ARIA jest wyraźna: jeśli istnieje element natywny, użyj go. Role ARIA są potrzebne dla zakładek, akordeonów, comboboxów z filtrowaniem i modalnymi oknami dialogowymi, a także dla innych wzorców, których HTML nie może samodzielnie zaimplementować.
Co oznacza, że element ma dostępną nazwę?
Dostępna nazwa to tekst ogłaszany przez czytnik ekranu podczas skupiania elementu. Jest ona obliczana na podstawie treści, z aria-label, z aria-labelledby lub z powiązanej <label>, w kolejności priorytetów określonej w specyfikacji. Rola interaktywna bez dostępnej nazwy to kontrolka, której użytkownik nie może zidentyfikować.
Dlaczego mój role="button" nie reaguje na klawiaturę?
Ponieważ ARIA nie dodaje zachowania. <div role="button"> wymaga tabindex="0", aby otrzymać fokus i obsługi keydown dla Enter i Spacji. Najprostszym i najbardziej niezawodnym rozwiązaniem jest użycie natywnego elementu <button>, który zawiera już fokus, aktywację klawiatury i przesłanie formularza.
Czy używanie aria-hidden="true" jest złe?
Ukrywanie treści dekoracyjnych lub zduplikowanych w drzewie dostępności jest prawidłowe, ale nigdy nie powinno być stosowane do elementów, na których jest fokus. Jeśli element, który można aktywować, pozostanie z aria-hidden="true", użytkownik klawiatury może skupić się na czymś, czego nie ogłasza czytnik ekranu. Zawsze łącz to z faktycznym ukrywaniem wizualnym.
Jakie narzędzia walidują role i atrybuty ARIA?
W3C Nu HTML Checker umożliwia weryfikację ról i atrybutów ARIA oraz wykrywa nieistniejące role lub zabronione kombinacje. axe DevTools i Lighthouse wskazują role bez dostępnej nazwy i brakujących obowiązkowych atrybutów. Aby zweryfikować efekt końcowy, inspektor drzewa dostępności w przeglądarce DevTools pokazuje dokładnie, co otrzymuje technologia wspomagająca.
¿Cumplir WCAG grzech do samochodu?
Superposición de IA que promete cumplimiento WCAG w 48 godzinach