blog na temat dostępności stron internetowych

Przejdź do głównej treści

Podstawowe zasady stosowania atrybutów ARIA

Techniczna specyfikacja WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) została stworzona w celu zapewnienia technologii umożliwiającej poprawę dostępności stron i aplikacji internetowych. Poprzez dodanie do określonych elementów atrybutów ARIA, jesteśmy w stanie pomóc osobom niewidomym zrozumieć, jaką elementy te pełnią rolę i w jaki sposób działają. Należy być jednak świadomym tego, że choć stosując ARIA możemy znacząco poprawić dostępność stron dla osób korzystających z czytników ekranu, używając ich nieprawidłowo możemy też znacznie ją pogorszyć. Organizacja W3C sformułowała pięć podstawowych zasad używania atrybutów ARIA.

Zasada nr 1

Zanim postanowimy stworzyć własny, niestandardowy komponent (i dodać do niego atrybuty ARIA), upewnijmy się, czy nie istnieją macierzyste elementy i atrybuty HTML, za pomocą których możemy zbudować ten komponent. Jeśli jest możliwe użycie istniejącego elementu bądź atrybutu HTML, który pod względem semantycznym i funkcjonalnym spełnia nasze wymagania, należy to zrobić.

Na przykład, jaki jest sens stosowania poniższego kodu:

<span aria-label="przycisk" role="button" tabindex="0"></span>

jeśli można po prostu zastosować:

<button>Przycisk</button>

Pamiętajmy, że specyfikacja ARIA została stworzona, by uzupełnić braki w HTML, a nie żeby go zastąpić.

Zasada nr 2:

Nie należy zmieniać semantyki danego elementu HTML, chyba że jest to absolutnie konieczne.
Chodzi tutaj o stosowanie ról ARIA, czyli grupy atrybutów, które mają za zadanie opisać przeznaczenie danego elementu, określić, jaką rolę pełni on na stronie (np. role="heading" – nagłówek, role="button" – przycisk, itd). W3C odradza zatem nadpisywanie roli poprzez nadawanie atrybutu “role” elementom, które posiadają już semantyczne znaczenie. Na przykład, każdy element nagłówkowy (<h1>, <h2>, <h3>, <h4>, <h5>, <h6>) ma domyślną rolę “nagłówek”. Dlatego zamiast zmieniać jego przeznaczenie  poprzez dodanie do niego innej roli ARIA:

<!-- to jest teraz przycisk, nie nagłówek -->
<h2 role="button">Nagłówek</h2>

dodajmy przycisk do elementu nagłówkowego:

<h2><button>Nagłówek</button></h2>

Jeśli z jakiegoś powodu użycie elementu <button> nie jest możliwe, lepiej jest posłużyć się elementem pozbawionym semantycznego znaczenia (np. <span>) i nadać mu odpowiedni atrybut “role”:

 <h2><span role="button">Nagłówek</span></h2>

Innymi słowy lepiej jest używać atrybutów “role” do nadania semantycznego znaczenia niesemantycznym elementom, takim jak <span> czy <div>, niż do zmiany roli elementu semantyczego.

Zasada nr 3:

Wszystkie interaktywne elementy ARIA muszą być dostępne z poziomu klawiatury. Jeśli osoba korzystająca z myszy jest w stanie aktywować, zaznaczyć, czy też przeciągnąć dany element, to osoba korzystająca z klawiatury musi musi mieć możliwość wykonania tych samych czynności.
Na przykład, jeśli tworzymy przycisk stosując element <span>, ARIA i JavaScript, na który użytkownik może kliknąć, musimy upewnić się, że element ten będzie również otrzymywał fokus klawiatury (można to zrobić poprzez dodanie atrybutu tabindex=”0”), i że osoba korzystająca z klawiatury będzie mogła aktywować go poprzez naciśnięcie przycisku Enter / Return bądź spacji (poprzez uzupełnienie zdarzeń myszy zdarzeniami klawiatury w JavaScript).

Zasada nr 4:

Nie dodawaj atrybutów role="presentation" bądź aria-hidden="true" do widocznych elementów, które otrzymują fokus klawiatury.

Atrybut role="presentation" usuwa semantyczne znaczenie elementu, na którym się znajduje. I tak na przykład poniższy nagłówek:

<h2 role="presentation">Wiadomości</h2>

zostanie przedstawiony technologiom asystującym jako zwykły tekst (“Wiadomości”), ciąg znaków, który nie pełni żadnej szczególnej funkcji na stronie, a nie jako nagłówek drugiego poziomu.

Atrybut aria-hidden="true" usuwa dany element z dostępnościowego drzewka przeglądarki. Na przykład, poniższy nagłówek zostanie przez czytniki ekranu całkowicie zignorowany (łącznie z zawartym w nim tekstem):

<h2 aria-hidden="true">Wiadomości</h2>

Problem pojawia się wtedy, gdy atrybuty te dodane są do interaktywnych elementów. Z punktu widzenia osób korzystających z czytnika ekranu, przeznaczenie tych elementów będzie nieznane – elementy te wciąż będą “widoczne” (gdyż będzie możliwe przeniesienie do nich fokusa klawiatury oraz wirtualnego kursora czytnika ekranu), lecz ich funkcja będzie nieznana.  Dlatego nie należy stosować następujących rozwiązań:

<button role="presentation">Przycisk</button>

<button aria-hidden="true">Przycisk</button>

<a aria-hidden="true" href="[...]">Link</a>

Jeśli jednak element interaktywny jest niewidoczny i nieaktywny, wtedy użycie aria-hidden="true" jest dozwolone, np:

 <button aria-hidden="true" style="visibility: hidden">Przycisk</button>

Więcej na temat poprawnego ukrywania treści można przeczytać w artykule “Ukrywanie elementów strony”).

Zasada nr 5:

Wszystkie interaktywne elementy muszą  posiadać dostępną nazwę (etykietę). Co to znaczy dostępną? Taką, która została odpowiednio oznaczona w kodzie, a co za tym idzie, do której technologie asystujące mają dostęp poprzez AAPI.

W przypadku linków bądź przycisków “dostępną nazwę” stanowi tekst zawarty pomiędzy znacznikiem początkowym (<a>, <button>), a końcowym (</a>, </button>):

<a href="[...]">Wiadomości</a>
<button>Znajdź</button>

W przypadku linków – obrazków może być to też zawartość atrybutu “alt”:

<a href="[...]"><img src="[...]" alt="Firma XYX - strona główna"></a>

W przypadku pól formularza jest to zawartość elementu <label> prawidłowo powiązanego z danym polem przy pomocy atrybutów “for” i “id”:

<label for="nazwisko">Nazwisko:</label>
<input type="text" id="nazwisko">

Element <span> czy też <p> zamieszczony przed polem formularza nie jest w żaden sposób powiązany w kodzie strony z polem, który opisuje i dlatego jego zawartość nie zostanie odczytana, gdy osoba korzystająca z czytnika ekranu przeniesie do pola fokus klawiatury. Pole to nie posiada zatem nazwy dostępnej dla technologii asystujących.

<!-- to nie jest dostępna nazwa! -->
<span>Nazwisko:</span>
<input type="text" id="nazwisko">
<!-- to też nie jest dostępna nazwa! -->
<input type="text" id="nazwisko" placeholder="Nazwisko">

Jeśli nie jest możliwe użycie elementu <label>, należy użyć odpowiednich atrybutów ARIA aby zapewnić etykietę, która będzie rozpoznana przez czytniki ekranu:

<input type="text" id="nazwisko" aria-label="nazwisko">

albo:

<span id="nazwisko-label">Nazwisko:</span>
<input type="text" id="nazwisko" aria-labelledby="nazwisko-label">

Zasada 6:

Choć organizacja W3C podaje 5 głównych zasad, ja dodałabym od siebie jeszcze szóstą (mniej ważną) zasadę: nie stosuj ARIA tam, gdzie jest to zbyteczne. Na przykład, nie ma potrzeby stosować atrybut “role” by przypisać danemu elementowi rolę, którą ten już pełni:

<!-- to już jest link! -->
<a role="link" href="[...]">Link</a>
<!-- to i tak jest przycisk! -->
<button role="button">Zamknij</a>
<!-- wiemy, że jest to nagłówek pierwszego poziomu! -->
<h1 role="heading" aria-level="1">heading text</h1>

Choć nie spowoduje to żadnych problemów dla osób korzystających z czytników ekranu, jest to po prostu niepotrzebne.

Komentarze:

  1. Comandeer

    Zasada 6 też się przewija wśród rekomendacji W3C, zwłaszcza w dodatkowych informacjach o wykorzystaniu ARIA w HTML. W sumie dziwię się, że nie zrobili z tego faktycznie 6. zasady.

Dodaj komentarz

Należy wypełnić wszystkie pola oznaczone asteryskiem (*).
Zanim komentarz zostanie opublikowany będzie musiał zostać zatwierdzony przez moderatora.

Możesz wykorzystać następujące elementy HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>