ARIA i HTML

Większość programistów zna standardowy język znaczników naszego nowoczesnego witryny – HyperText Markup Language (HTML). Być może jednak nie wiesz, co to jest Accessible Rich Internet Applications (ARIA) (wcześniej WAI-ARIA): co to jest, jak jest używane oraz kiedy – a kiedy nie – należy z nich korzystać.

HTML i ARIA odgrywają ważną rolę w ułatwieniach dostępu do usług cyfrowych, zwłaszcza w przypadku technologii wspomagających osoby z niepełnosprawnością (AT), takich jak czytniki ekranu. Oba umożliwiają konwertowanie treści na alternatywny format, taki jak brajl lub zamiana tekstu na mowę (TTS).

Omówmy teraz pokrótce historię ARIA, jej znaczenie oraz czas i sposób korzystania.

Wprowadzenie do ARIA

Platforma ARIA została opracowana w 2008 roku przez grupę Web Accessibility Initiative (WAI) – podzbiór nadrzędnej konsorcjum World Wide Web Consortium (W3C), który reguluje internet.

ARIA nie jest prawdziwym językiem programowania, ale zbiorem atrybutów, które można dodawać do elementów HTML, aby zwiększyć ich dostępność. Atrybuty te przekazują informacje o roli, stanie i właściwości technologii wspomagających za pomocą interfejsów API ułatwień dostępu dostępnych w nowoczesnych przeglądarkach. Komunikacja odbywa się za pomocą drzewa ułatwień dostępu.

WAI-ARIA, pakiet Accessible Rich Internet Application Suite, to sposób na ułatwienie osobom z niepełnosprawnościami dostępu do treści internetowych i aplikacji internetowych. Jest to szczególnie przydatne w przypadku zawartości dynamicznej i zaawansowanych elementów interfejsu użytkownika opracowanych przy użyciu języka HTML, JavaScript i powiązanych technologii”.

Grupa WAI

Drzewo ułatwień dostępu

ARIA modyfikuje nieprawidłowy lub niepełny kod, aby poprawić wrażenia użytkowników korzystających z funkcji AT przez zmianę, ujawnienie i uzupełnienie części drzewa ułatwień dostępu.

Drzewo ułatwień dostępu jest tworzone przez przeglądarkę na podstawie standardowego drzewa DOM. Podobnie jak drzewo DOM, drzewo ułatwień dostępu 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 związane z poszczególnymi platformami, aby zaprezentować w zrozumieniu technologii wspomagającej osoby z niepełnosprawnością.

Drzewo z rozszerzonym ułatwieniem dostępu ARIA.

Sama ARIA nie zmienia funkcjonalności ani wyglądu elementu. Oznacza to, że tylko użytkownicy sieci AT będą zauważyli różnice między produktem cyfrowym z ARIA a innym bez niego. Oznacza to również, że to oni są odpowiedzialni za wprowadzenie odpowiednich zmian w kodzie i stylu elementu, tak by dany element był jak najbardziej przystępny.

Trzy główne cechy ARIA to role, właściwości i stany/wartości.

Role określają, co element lub robi na stronie bądź w aplikacji.

<div role="button">Self-destruct</div>

Właściwości określają 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/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żywać w jednym wierszu kodu, ale nie jest to wymagane. Zamiast tego umieszczaj w warstwach role, właściwości i stany/wartości ARIA, aż osiągniesz ostateczny cel związany z ułatwieniami dostępu. Właściwe uwzględnienie ARIA w bazie kodu zapewnia, że użytkownicy AT mają wszystkie informacje potrzebne do korzystania z Twojej witryny, aplikacji lub innego produktu cyfrowego.

Ostatnio w Narzędziach deweloperskich w Chrome możesz zobaczyć pełne drzewo ułatwień dostępu, aby ułatwić deweloperom zrozumienie, jak ich kod wpływa na ułatwienia dostępu.

Kiedy używać ARIA

W 2014 r. organizacja W3C oficjalnie opublikowała rekomendację HTML5. Wprowadziliśmy też duże zmiany, w tym dodanie elementów punktów orientacyjnych, takich jak <main>, <header>, <footer>, <aside> i <nav>, oraz atrybutów takich jak hidden i required. Nowe elementy i atrybuty HTML5 oraz zwiększona obsługa przeglądarek sprawiają, że niektóre elementy ARIA mają teraz mniejsze znaczenie.

Gdy przeglądarka obsługuje tag HTML z rolą niejawną z odpowiednikiem ARIA, zazwyczaj nie ma potrzeby dodawania do tego elementu ARIA. ARIA nadal zawiera jednak wiele ról, stanów i właściwości, które nie są dostępne w żadnej wersji HTML. Na razie te atrybuty są nadal przydatne.

Tutaj stajemy przed najważniejszym pytaniem: kiedy należy używać ARIA? Na szczęście grupa WAI opracowała 5 reguł ARIA, które pomagają określić sposób udostępniania elementów.

Reguła 1. Nie używaj ARIA

Tak. Dobrze czytasz. Dodanie ARIA do elementu z natury nie zwiększa jego dostępności. Z rocznego raportu WebAIM Million wynika, że na stronach głównych z ARIA wykryto średnio o 70% więcej błędów niż strony bez tej funkcji. Główną przyczyną była nieprawidłowa implementacja atrybutów ARIA.

Od tej reguły istnieją wyjątki. Jeśli element HTML nie obsługuje ułatwień dostępu, parametr ARIA jest wymagany. Może to być spowodowane tym, że dany projekt nie zezwala na określony element HTML lub że żądana funkcja/działanie nie jest dostępne w kodzie HTML. Takie sytuacje powinny być jednak niewiele.

Nie
<a role="button">Submit</a>
Tak
<button>Submit</button>

W razie wątpliwości używaj semantycznych elementów HTML.

Reguła 2: nie dodawaj (niepotrzebnej) identyfikatora ARIA do kodu HTML

W większości przypadków elementy HTML działają od razu i nie wymagają dodawania do nich dodatkowych ARIA. Deweloperzy korzystający z ARIA często muszą dodawać dodatkowy kod, aby elementy działały w przypadku elementów interaktywnych.

Nie
<h2 role="tab">Heading tab</h2>
Tak
<div role="tab"><h2>Heading tab</h2></div>

Korzystanie z elementów HTML zgodnie z zamierzeniami wymaga mniej pracy i uzyskuje lepszy kod.

Reguła 3. Zawsze obsługuj nawigację za pomocą klawiatury

Wszystkie interaktywne (niewyłączone) elementy sterujące ARIA muszą być dostępne przy użyciu klawiatury. Do każdego elementu, który zwykle nie jest zaznaczony, możesz dodać tabindex= „0”. Jeśli to możliwe, unikaj używania indeksów kart z dodatnimi liczbami całkowitymi, aby uniknąć potencjalnych problemów z kolejnością zaznaczenia klawiatury.

Nie
<span role="button" tabindex="1">Submit</span>
Tak
<span role="button" tabindex="0">Submit</span>
Oczywiście, jeśli możesz, w tym przypadku użyj rzeczywistego elementu <button>.

Reguła 4. Nie ukrywaj elementów, które można zaznaczyć

Nie dodawaj role= "presentation" ani aria-hidden= "true" do elementów, które muszą być zaznaczone, w tym do elementów z atrybutem tabindex= "0". Gdy dodajesz te role/stany do elementów, wysyła to do agencji AT komunikat, że elementy te są nieistotne i można je pominąć. Może to dezorientować lub zakłócić działanie użytkowników, którzy próbują wejść w interakcję z elementem.

Nie
<div aria-hidden="true"><button>Submit</button></div>
Tak
<div><button>Submit</button></div>

Reguła 5. Używaj nazw na potrzeby ułatwień dostępu dla elementów interaktywnych

Użytkownik musi zostać przedstawiony, zanim będzie mógł wchodzić z nim w interakcję. Upewnij się, że wszystkie elementy mają nazwy dostępne dla użytkowników urządzeń AT.

Nazwy ułatwień dostępu mogą obejmować treść otoczoną przez element (w przypadku elementu <a>), tekst alternatywny lub etykietę.

W przypadku każdego z poniższych przykładów kodu nazwa na potrzeby ułatwień dostępu to „Czerwone buty skórzane”.

<!-- 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>

Nazwę elementu na potrzeby ułatwień dostępu możesz sprawdzić na wiele sposobów, w tym przez sprawdzenie drzewa ułatwień dostępu za pomocą Narzędzi deweloperskich w Chrome lub przetestowanie go przy użyciu czytnika ekranu.

ARIA w kodzie HTML

Sprawdzoną metodą jest używanie samych elementów HTML, ale w niektórych sytuacjach można je dodawać. Możesz na przykład powiązać ARIA z HTML w wzorcach, które wymagają wyższego poziomu obsługi AT ze względu na ograniczenia środowiskowe, lub jako metodę zastępczej dla elementów HTML, które nie są w pełni obsługiwane przez wszystkie przeglądarki.

Oczywiście istnieją też zalecenia dotyczące implementacji ARIA w HTML. Przede wszystkim: nie zastępuj domyślnych ról HTML, zmniejsz nadmiarowość i pamiętaj o niezamierzonych skutkach ubocznych.

Przyjrzyjmy się kilku przykładom.

Nie
<a role="heading">Read more</a>
Przypisano niewłaściwą rolę.
Tak
<a aria-label="Read more about some awesome article title">Read More</a>
Prawidłowa rola i dodatkowy opis linku.

Nie
<ul role="list">...</ul>
Zbędna rola.
Tak
<ul>...</ul>
Usunięto nadmiarowość

Nie
<details>
  <summary role="button">more information</summary>
  ...
</details>
Potencjalne skutki uboczne.
Tak
<details>
  <summary>more information</summary>
  ...
</details>
Brak niezamierzonych skutków ubocznych.

Złożoność ARIA

ARIA jest skomplikowaną kwestią, więc podczas korzystania z niej należy zachować ostrożność. Chociaż przykłady kodu przedstawione w tej lekcji są proste, tworzenie łatwo dostępnych wzorców niestandardowych może być bardzo skomplikowane.

Jest wiele kwestii, na które trzeba zwrócić uwagę, w tym między innymi: interakcje z klawiaturą, interfejsy dotykowe, obsługa AT/przeglądarki, potrzeby związane z tłumaczeniem, ograniczenia środowiskowe, starszy kod i preferencje użytkownika. Niewielka wiedza o programowaniu może być szkodliwa – lub po prostu irytująca, jeśli będzie używana nieprawidłowo. Pamiętaj, że kod powinien być prosty.

Poza ostrzeżeniami dostępność cyfrowa nie zawsze jest czymś złym – jest to spektrum, na którym można znaleźć takie szare obszary. W zależności od sytuacji wiele rozwiązań do kodowania może być postrzegane jako „prawidłowe”. Ważne jest, by ciągle się uczyć, testować i pracować nad tym, aby nasz cyfrowy świat był bardziej otwarty dla wszystkich.

Sprawdź swoją wiedzę

Sprawdź swoją wiedzę o ARIA i HTML

Która z tych opcji jest sprawdzoną metodą tworzenia łatwo dostępnego przycisku?

<div id="saveChanges" aria-role="button" aria-pressed="false" tabindex="0">Go to shop</div>
Niezupełnie. Nie należy używać ARIA, gdy dostępny jest semantyczny element HTML.
<a id="saveChanges" aria-label="Some awesome article title">Go to shop</a>
Niezupełnie. Możesz zmienić styl tego linku jak przycisk za pomocą CSS, ale nie jest to sprawdzona metoda.
<button id="saveChanges" type="button">Go to shop</button>
Brawo! Utwórz przycisk, używając prawidłowego semantycznego kodu HTML oraz jego typu.