Powrót

5 złotych zasad używania atrybutów ARIA, wiedziałeś?

5 zasad używania ARIA

Pięć prostych zasad ARIA, czyli Accessible Rich Internet Applications. To w wolnym tłumaczeniu znaczy - aplikacji internetowych, które są dostępne dla prawie każdego. Mowa tutaj o osobach z niepełnosprawnościami typu:

• Ograniczenie funkcji poznawczych
• Niedowidzących lub ślepych
• Niedosłyszących lub głuchych
• O ograniczonych funkcjach motorycznych

Kiedy musisz zadbać o ich spełnienie? Na przykład kiedy planujesz tworzyć aplikację dla organizacji rządowych. Muszą one wpisywać się w wytyczne WCAG, które wykorzystują zasady ARIA. Warto też o nie zadbać we większości aplikacji, które są dostępne publicznie, dla szerokiego grona odbiorców.

Dostępne aplikacje przychodzą z bonusem - lepiej się pozycjonują i mogą zdobywać dzięki temu większy ruch oraz zyski.

Wstęp

Sama nazwa ARIA brzmi dość ogólnie, nie? Mówiąc o ARIA w kontekście programowania, mówimy przede wszystkim o atrybutach HTML, które pozwalają nam lepiej opisać dane elementy. Często kontekst nadawany jest poprzez stylowanie, układ elementów, kolory.

Jeżeli ktoś tego nie widzi, bo używa czytnika ekranowego (takie narzędzie, które dosłownie czyta całą zawartość strony internetowej), to bardzo dużo traci. Szczerze mówiąc, jak kiedyś odpaliłem takie narzędzie, to doświadczenie było po prostu koszmarne.

Dlatego więc to tak ważne abyśmy dołożyli starań by te narzędzia mogły sprawnie interpretować to co dzieje się w aplikacji i mogło w jasny sposób wyjaśnić to odbiorcy z niepełnosprawnością.

1. Jeżeli możesz, używaj tagów semantycznych, zamiast atrybutów ARIA

Wspomniane atrybuty mają być wsparciem przede wszystkim w sytuacjach, które są raczej mało standardowe. Jeżeli jednak istnieje tag, który już domyślnie ma jakąś rolę, to po prostu go użyj. Na przykład do niedawna zalecało się przypisanie roli dialog do divów, które są modalami, pop-upami. Od jakiegoś czasu dostępny jest dedykowany tag o takiej samej nazwie więc korzystaj z niego.

Poniżej przykłady złych praktyk:

1// Źle
2<div role="dialog">...</div>
3// Dobrze
4<dialog>...</dialog>
5
6// Źle
7<div role="contentinfo">...</div>
8<footer>...</footer>
9

2. Jeśli jakiś tag ma już znaczenie semantyczne, nie zmieniaj go

Trochę w drugą stronę. Wcześniej mówiliśmy o tym żeby nie używać div kiedy możesz użyć na przykład nav. Tym razem autorzy dokumentacji zwracają uwagę na to by nie zmieniać istniejących już, domyślnych ról. Poniżej przykłady złej praktyki:

1// Źle!
2<main role="dialog"></main>
3// Dobrze :)
4<main>
5	<dialog>...</dialog>
6</main>
7
8// Źle
9<h2 role=tab>heading tab</h2>
10// Dobrze
11<div role=tab><h2>heading tab</h2></div>

Jak widzisz, dokumentacja sugeruje opakowanie nagłówka dodatkowym tagiem. To może wydawać się sprzeczne z logiką - dodajemy element, który tylko “zaśmieca” DOM. Mimo wszystko, mogą być sytuacje kiedy tego nie unikniemy.

3. Każdy element, w którym da się wejść w interakcję myszą, musi pozwalać na to samo przy użyciu klawiatury

Jeżeli tworzysz jakieś modale, nietypowe przyciski i wykorzystujesz przy tym atrybuty roli (np. role="button") to musisz zadbać o to by dało się obsługiwać je klawiaturą.

Tutaj aż prosi się wrócić do pierwszej zasady. Gdy użyjesz natywnych tagów do tego przeznaczonych (np. <button> lub <a>), takie interakcje będą działać automatycznie.

Ważne! Dokumentacja podkreśla, że interakcja za pomocą klawiatury musi odbywać się zarówno przy użyciu klawisza enter (return w komputerach Mac) jak i spacji.

4. Nie ukrywaj przed czytnikami elementów, z którymi da się wejść w interakcję

Jeżeli masz na stronie jakieś elementy, na które da się najechać myszą i zobaczyć dodatkową treść, które da się kliknąć i ogólnie wejść w jakąś interakcję - nie ukrywaj ich. A konkretniej, nie używaj na nich atrybutów role="presentation oraz aria-hidden="true".

Oba mają jedno, główne zadanie - oznaczyć element jako nieistotny dla czytników ekranowych. Na przykład jakąś grafikę, która po prostu uatrakcyjnia wygląd strony.

5. Wszystkie elementy interaktywne muszą mieć dostępną nazwę

Ten punkt ponownie wymaga powrotu do pierwszego. Dlatego, że używając natywnych, dedykowanych pewnym zadaniom tagów - to się dzieje automatycznie. Na przykład, każdy input powinien mieć <label>.

Wtedy te pole tekstowe automatycznie zyskuje widoczną nazwę czyli wizualne wyjaśnienie czemu ma służyć oraz dostępną nazwę, która będzie odczytana przez narzędzia wspierające. Gdybyśmy zamiast <label> użyli <span> do opisania tagu <input> to ten efekt by nie miał miejsca. Mielibyśmy tylko “nazwę widoczną”.

Podsumowanie

Jest kilka różnych miejsc, które wskazują nam jak tworzyć dostępne aplikacje. Jest ta lista, nazwana zasadami ARIA. Są też wytyczne WAI - Web Accessibility Initiative, o których pisałem w innym artykule. Na samym końcu mamy wytyczne WCAG.

Jak do tego podejść i nie zgłupieć?

• Zasady ARIA to dla mnie absolutny fundament. Wdrożenie tych zasad nie wymaga też zwykle więcej niż kilka minut dodatkowego nakładu pracy.
• 11 zasad WAI traktuję jako rozszerzenie powyższego, sprawiające, że nasze aplikacje będą pokrywać znaczną część problemów z dostępnością. Trochę więcej roboty, ale przy odrobinie wprawy - nadal niewiele.
• WCAG to z kolei jasna, zero-jedynkowa lista wymogów do spełnienia jeżeli chcemy mieć absolutną pewność, że nasza aplikacja będzie łatwa w odbiorze przez określony grupy ludzi. Sprawdza się kiedy accessibility to nie jest dla nas nice-to-have tylko must-have.

Powrót