Większość deweloperów zna standardowy język znaczników współczesnej sieci, czyli HyperText Markup Language (HTML). Możesz jednak nie znać Accessible Rich Internet Applications (ARIA) (formalnie WAI-ARIA): czym jest, jak się jej używa oraz kiedy i kiedy nie należy jej używać.
HTML i ARIA odgrywają ważną rolę w zapewnianiu dostępności produktów cyfrowych, zwłaszcza w przypadku technologii wspomagającej osoby z niepełnosprawnością, takich jak czytniki ekranu. Oba te formaty służą do przekształcania treści w format alternatywny, np. w Braille’a lub tekst na mowę.
Poznaj krótką historię ARIA, dowiedz się, dlaczego jest ważna, kiedy i jak najlepiej z niej korzystać.
Wprowadzenie do ARIA
ARIA została opracowana w 2008 roku przez grupę Web Accessibility Initiative (WAI), która jest częścią organizacji World Wide Web Consortium (W3C) zarządzającej internetem i regulującej jego działanie.
ARIA nie jest prawdziwym językiem programowania, ale zestawem atrybutów, które można dodać do elementów HTML, aby zwiększyć ich dostępność. Te atrybuty przekazują rolę, stan i właściwości technologiom wspomagającym za pomocą interfejsów API ułatwień dostępu dostępnych w nowoczesnych przeglądarkach. Ta komunikacja odbywa się przez drzewo ułatwień dostępu.
„WAI-ARIA, czyli pakiet Accessible Rich Internet Applications, określa sposób, w jaki treści internetowe i aplikacje internetowe mogą być bardziej dostępne dla osób z niepełnosprawnościami. Jest to szczególnie przydatne w przypadku treści dynamicznych i zaawansowanych elementów sterujących interfejsu użytkownika opracowanych w HTML-u, JavaScript i technologiach pokrewnych”.
Grupa WAI
Drzewo ułatwień dostępu
ARIA modyfikuje nieprawidłowy lub niekompletny kod, aby zapewnić lepsze wrażenia osobom korzystającym z technologii wspomagających. W tym celu zmienia, udostępnia i rozszerza części drzewa dostępności.
Drzewo ułatwień dostępu jest tworzone przez przeglądarkę na podstawie standardowego drzewa obiektowego modelu dokumentu (DOM). Podobnie jak drzewo DOM, drzewo dostępności zawiera obiekty reprezentujące wszystkie elementy znaczników, atrybuty i węzły tekstowe. Drzewo ułatwień dostępu jest też używane przez interfejsy API ułatwień dostępu dopasowane do platformy, aby zapewnić reprezentację zrozumiałą dla technologii wspomagających.
ARIA sama w sobie nie zmienia funkcjonalności ani wyglądu elementu. Oznacza to, że tylko użytkownicy technologii wspomagających zauważą różnice między produktem cyfrowym z ARIA a produktem bez niej. Oznacza to również, że programiści ponoszą wyłączną odpowiedzialność za wprowadzenie odpowiednich zmian w kodzie i stylu, aby element był jak najbardziej dostępny.
Trzy główne funkcje ARIA to role, właściwości oraz stany i wartości.
Role określają, czym jest element lub co robi na stronie lub w aplikacji.
<div role="button">Self-destruct</div>
Właściwości wyrażają cechy lub relacje z obiektem.
<div role="button" aria-describedby="more-info">Self-destruct</div>
<div id="more-info">This page will self-destruct in 10 seconds.</div>
Stany i wartości określają bieżące warunki lub wartości danych powiązane z elementem.
<div role="button" aria-describedby="more-info" aria-pressed="false">
Self-destruct
</div>
<div id="more-info">
This page will self-destruct in 10 seconds.
</div>
Wszystkie 3 elementy ARIA można użyć w jednej linii kodu, ale nie jest to wymagane. Zamiast tego nakładaj na siebie role, właściwości i stany lub wartości ARIA, aż osiągniesz ostateczny cel związany z ułatwieniami dostępu. Prawidłowe włączenie ARIA do bazy kodu zapewnia, że użytkownicy technologii wspomagających będą mieli wszystkie informacje potrzebne do skutecznego i sprawiedliwego korzystania z Twojej witryny, aplikacji lub innego produktu cyfrowego.
Narzędzia deweloperskie w Chrome wprowadziły niedawno funkcję wyświetlania pełnego drzewa dostępności, która ułatwia programistom zrozumienie, jak ich kod wpływa na dostępność.
Kiedy używać ARIA
W 2014 r. organizacja W3C oficjalnie opublikowała rekomendację dotyczącą HTML5. Wraz z nim wprowadziliśmy kilka ważnych zmian, w tym dodaliśmy elementy orientacyjne, takie jak <main>, <header>, <footer>, <aside>, <nav>, oraz atrybuty, takie jak hidden i required. Dzięki nowym elementom i atrybutom HTML5 oraz zwiększonej obsłudze przeglądarek niektóre części ARIA mają teraz mniejsze znaczenie.
Jeśli przeglądarka obsługuje tag HTML z niejawną rolą, która ma odpowiednik w ARIA, zwykle nie trzeba dodawać ARIA do elementu. ARIA zawiera jednak wiele ról, stanów i właściwości, które nie są dostępne w żadnej wersji HTML. Te atrybuty są na razie przydatne.
Dochodzimy do najważniejszego pytania: kiedy należy używać ARIA? Na szczęście grupa WAI opracowała 5 zasad ARIA, które pomogą Ci zdecydować, jak ułatwić dostęp do elementów.
Reguła 1. Nie używaj ARIA
Tak, dobrze czytasz. Dodanie ARIA do elementu nie sprawia, że staje się on bardziej dostępny. Z rocznego raportu WebAIM Million na temat dostępności wynika, że strony główne z ARIA miały średnio o 70% więcej wykrytych błędów niż strony bez ARIA. Wynikało to głównie z nieprawidłowego wdrożenia atrybutów ARIA.
Od tej zasady są wyjątki. Atrybut ARIA jest wymagany, gdy element HTML nie obsługuje ułatwień dostępu. Może to być spowodowane tym, że projekt nie zezwala na użycie określonego elementu HTML lub że żądana funkcja lub zachowanie nie są dostępne w HTML. Takie sytuacje powinny być jednak rzadkie.
Nie rób tego: przypisywać roli.
<a role="button">Submit</a>
Zrób to: użyj elementu semantycznego.
<button>Submit</button>
W razie wątpliwości używaj semantycznych elementów HTML.
Reguła 2. Nie dodawaj (niepotrzebnych) atrybutów ARIA do kodu HTML
W większości przypadków elementy HTML działają prawidłowo i nie wymagają dodawania do nich dodatkowych atrybutów ARIA. W przypadku elementów interaktywnych programiści korzystający z ARIA często muszą dodawać dodatkowy kod, aby elementy działały prawidłowo.
Nie: przypisuj wprowadzających w błąd ról.
<h2 role="tab">Heading tab</h2>
Rób: prawidłowo przypisuj role.
<div role="tab"><h2>Heading tab</h2></div>
Używaj elementów HTML zgodnie z ich przeznaczeniem, aby mniej się napracować i uzyskać lepiej działający kod.
Reguła 3. Zawsze obsługuj nawigację za pomocą klawiatury
Wszystkie interaktywne (niewyłączone) elementy sterujące ARIA muszą być dostępne za pomocą klawiatury. Możesz dodać atrybut tabindex= "0" do dowolnego elementu, który wymaga zaznaczenia, ale zwykle nie jest zaznaczany za pomocą klawiatury. W miarę możliwości unikaj używania indeksów kart z dodatnimi liczbami całkowitymi, aby zapobiec potencjalnym problemom z kolejnością zaznaczania elementów za pomocą klawiatury.
Nie: dodaj atrybut tabindex.
<span role="button" tabindex="1">Submit</span>
Zrób to: ustaw wartość tabindex na „0”.
<span role="button" tabindex="0">Submit</span>
Oczywiście w tym przypadku możesz użyć prawdziwego elementu <button>.
Reguła 4. Nie ukrywaj elementów, które można zaznaczyć
Nie dodawaj atrybutów role= "presentation" ani aria-hidden= "true" do elementów, które muszą być aktywne, w tym do elementów z atrybutem tabindex= "0". Gdy dodasz te role i stany do elementów, wyślesz do technologii wspomagającej komunikat, że te elementy nie są ważne i należy je pominąć. Może to wprowadzać zamieszanie lub utrudniać użytkownikom interakcję z elementem.
Nie: ukrywaj elementy, na których można ustawić fokus.
<div aria-hidden="true"> <button>Submit</button> </div>
Zrób to: udostępnij elementy możliwe do zaznaczenia.
<div> <button>Submit</button> </div>
Reguła 5. Używaj nazw na potrzeby ułatwień dostępu w przypadku elementów interaktywnych
Zanim użytkownik dowie się, jak korzystać z elementu interaktywnego, musi poznać jego przeznaczenie. Upewnij się, że wszystkie elementy mają nazwę na potrzeby ułatwień dostępu dla osób korzystających z urządzeń AT.
Dostępne nazwy mogą być treścią otoczoną elementem (w przypadku elementu <a>), tekstem alternatywnym lub etykietą.
W przypadku każdego z tych przykładów kodu nazwa na potrzeby ułatwień dostępu to „Czerwone skórzane buty”.
<!-- A plain link with text between the link tags. -->
<a href="shoes.html">Red leather boots</a>
<!-- A linked image, where the image has alt text. -->
<a href="shoes.html"><img src="shoes.png" alt="Red leather boots"></a>
<!-- A checkbox input with a label. -->
<input type="checkbox" id="shoes">
<label for="shoes">Red leather boots</label>
Istnieje wiele sposobów sprawdzenia nazwy ułatwienia dostępu elementu, w tym sprawdzenie drzewa ułatwień dostępu za pomocą Narzędzi deweloperskich w Chrome lub przetestowanie go za pomocą czytnika ekranu.
ARIA w HTML
Używanie samych elementów HTML to sprawdzona metoda, ale w niektórych sytuacjach można dodać elementy ARIA. Możesz na przykład używać ARIA w połączeniu z HTML w wzorcach, które wymagają wyższego poziomu obsługi technologii wspomagających ze względu na ograniczenia środowiskowe lub jako metodę rezerwową dla elementów HTML, które nie są w pełni obsługiwane przez wszystkie przeglądarki.
Oczywiście istnieją zalecenia dotyczące wdrażania ARIA w HTML. Najważniejsze: nie zastępuj domyślnych ról HTML, ograniczaj nadmiarowość i uważaj na niezamierzone efekty uboczne.
Przyjrzyj się kilku przykładom.
Nie: przypisuj niewłaściwej roli.
<a role="heading">Read more</a>
Zrób to: użyj właściwej roli i dodatkowego opisu linku.
<a aria-label="Read more about some awesome article title">Read More</a>
Nie: dodawaj zbędnej roli.
<ul role="list">...</ul>
Rób: ograniczaj nadmiarowość.
<ul>...</ul>
Nie: pomijaj potencjalne skutki uboczne.
<details> <summary role="button">more information</summary> ... </details>
Zrób to: zajmij się skutkami ubocznymi.
<details> <summary>more information</summary> ... </details>
Złożoność ARIA
ARIA jest złożona, dlatego zawsze należy zachować ostrożność podczas jej używania. Przykłady kodu w tej lekcji są dość proste, ale tworzenie dostępnych wzorców niestandardowych może szybko stać się skomplikowane.
Jest wiele rzeczy, na które należy zwrócić uwagę, m.in.: interakcje z klawiaturą, interfejsy dotykowe, obsługa technologii wspomagających i przeglądarek, potrzeby związane z tłumaczeniem, ograniczenia środowiskowe, starszy kod i preferencje użytkowników. Niewielka wiedza o kodowaniu może być szkodliwa lub po prostu irytująca, jeśli jest używana nieprawidłowo.
Pomijając te ostrzeżenia, dostępność cyfrowa nie jest sytuacją typu „wszystko albo nic” – to spektrum, które dopuszcza pewne obszary niejednoznaczne, takie jak ten. W zależności od sytuacji kilka rozwiązań programistycznych może być uznanych za „prawidłowe”. Ważne jest, aby stale się uczyć, testować i starać się, aby nasz cyfrowy świat był bardziej otwarty dla wszystkich.