Kiedy używać role=”presentation”, a kiedy to niewskazane

Co to jest ARIA

Kilkukrotnie już wspominaliśmy o atrybutach ARIA. Tylko co to jest i dlaczego tak często można je spotkać w kodzie?

Najprościej ujmując, jest to zbiór atrybutów i technik wspomagających, wprowadzonych do standardu WCAG 2.0 w 2014 roku link do artykułu o WAI-ARIA, otwiera się w nowym oknie.. Najszerzej patrząc, techniki ARIA służą do nadania odpowiedniej semantyki elementowi, który jej nie ma z powodów choćby projektowych. Z drugiej strony potrzebna jest również możliwość wykluczenia elementu z drzewa dostępności. Z pomocą przychodzą różne techniki ukrywania obiektów. W zależności na jakim poziomie chcemy pominąć semantykę, mamy do wyboru takie atrybuty jak:
– disabled
– display: none
– aria-hidden=”true”
– role=”presentation” (synonim role=”none” wprowadzony w 2016 roku Link do artykułu otwiera się w nowym oknie.).

Pierwsza opcja powoduje kompletnie wyłączenie elementu interaktywnego, ale pozostaje on widoczny dla czytników ekranu jako element wyłączony.

Druga opcja ukrywa element zarówno wizualnie jak i dla narzędzi asystujących. Obie opcje omówimy w kolejnym artykule, ponieważ ich wykorzystanie łączy się z innymi przypadkami użycia.

Dzisiaj  zainteresujemy się bliżej dwoma pozostałymi atrybutami. Różnice w nich nie są duże, ale znaczące i często (przez niepoprawne zastosowanie) powodujące duże zamieszanie w obsłudze przez technologie asystujące.

Podobieństwa pomiędzy role="presentation" a aria-hidden="true"

Oba w pewien sposób ukrywają element przed technologiami asystującymi. Na tym jednak podobieństwa się kończą.

W pierwszej kolejności zajmijmy się aria-hidden = ”true”. Ten atrybut kompletnie ukrywa element przed technikami asystującymi. Oznacza to, że korzystający z czytnika ekranu użytkownik nie będzie świadom jego istnienia. Jest to przydatne w sytuacji, gdy fragment kodu nie jest elementem interaktywnym takim jak przycisk, link czy pole tekstowe. Kiedy mamy do czynienia z plikami SVG jest to wręcz konieczne, ale o tym opowiemy w kolejnym artykule 😊

Przykłady zastosowania role="presentation"

Rola presentation ma delikatną różnicę w zastosowaniu. Używamy jej, aby „wykasować” semantykę elementu. Można sprawdzić działanie roli na prostym przykładzie, jakim jest nagłówek:

<h2>Przykładowy nagłówek</h2>

Po dodaniu atrybutu:

<h2 role=”presentation”>Przykładowy nagłówek z rolą</h2>

Zapis jest równoważny zwykłemu tekstowi, który został odpowiednio ostylowany:

<div>Przykładowy nagłówek z rolą</div>

Czytnik ekranu nie potraktuje tekstu jako nagłówek, choć wizualnie dalej formatowanie pozostanie takie jak dla h2.

Rola początkowo była wykorzystywana w rozwiązaniach, które opierały się na układzie tabelarycznym lub grafikach służących tylko do zrobienia odstępu. Obecnie nie projektuje się już serwisów w ten sposób, a z pewnością nie jest to zalecane. Czy oznacza to, że ta rola nie jest już potrzebna? Nie, dalej można ją spotkać w nawigacjach. Rozwijając tę myśl spójrzmy na takie proste zastosowanie:

<ul role="presentation">
 <li>
  <a href="#">Link 1</a>
 </li>
 <li>
  <a href="#">Link 2</a>
 </li>
 <li>
  <a href="#">Link 3</a>
 </li>
</ul>

W tym wypadku pozbyliśmy się semantyki listy, ale linki nadal wizualnie ułożone są jeden po drugim. Moglibyśmy użyć też roli na elemencie listy:

<ul role="tree">
 <li role="presentation">
  <a role="treeitem" href="#">Link 1</a>
 </li>
 <li role="presentation">
  <a role="treeitem" href="#">Link 2</a>
 </li>
 <li role="presentation">
  <a role="treeitem" href="#">Link 3</a>
 </li>
</ul>

W takim wypadku semantycznie brakuje nam jednak w liście <ul> elementów, więc niespełnione jest kryterium 1.3.1 WCAG Link otwiera się w nowym oknie.. Dlatego konieczne jest zadbanie o to, żeby lista miała semantycznych potomków. Dodając role="tree" zapewniliśmy zgodność z WCAG, ale musieliśmy o tym wiedzieć/pamiętać.
Inne zastosowania przedstawione są również pod poniższym linkiem https://w3c.github.io/aria-practices/#presentation_role Link otwiera się w nowym oknie..

Podsumowanie

Jak widać, wprowadzenie role="presentation" może pomóc, ale również mocno skomplikować kod wyjściowy. Dodatkowo nie na wszystkich elementach rola jest akceptowalna. Nie wolno jej używać na linkach, przyciskach i innych elementach ściągających fokus, bo dalej fokus będzie ściągany, ale nie zawsze będzie to semantycznie opisane jako link, przycisk etc. Spowoduje to nieścisłości i osoba korzystająca z technologii asystujących może nie zrozumieć kontekstu użycia elementu.

Tak samo jest z elementami, które mają ustawiony którykolwiek z 21 stanów lub właściwości opisanych atrybutami ARIA Link otwiera się w nowym oknie..