Dostępne etykiety elementów interaktywnych.

Oglądając prezentację Tomasza Jakut „Mity o accessibility”, zaintrygowało mnie kilka zdań dotyczących etykiet elementów interaktywnych. Wynikało z nich, że popularne dobre praktyki poprawiające dostępność elementów dla czytników ekranu jednocześnie sprawiają, że te elementy są niedostępne w oprogramowaniach do sterowania głosem. Postanowiłam zrobić niewielki research i dowiedzieć się, jak ostatecznie prawidłowo uzupełniać owe nieszczęsne etykiety.

Hola, hola, od początku poproszę.

Posłuchaj poniższą prezentację od 12:36 do 13:16. Tomek zauważa, że z punktu widzenia oprogramowania do sterowania głosem ważne jest, aby etykiety poszczególnych elementów na stronie były dokładnie takie same jak w kodzie.

Tymczasem w codziennej pracy częściej skupiamy się na czytnikach ekranu i dodajemy różne, szczegółowe informacje do etykiet. W dobrej wierze oczywiście.

Problem niespójności etykiet z nazwami pokażę Tobie na przykładach.

<button aria-label="Details of our XYZ product.">Read more</button>
<!-- P.S. Don’t do this -->

Użytkownik oprogramowania do sterowania głosem mógłby powiedzieć „Click Read more” i (jeśli tylko etykieta w kodzie jest taka sama, jak w interfejsie), oprogramowanie doskonale wie, który przycisk kliknąć. Jeśli jednak przycisk posiada wizualną nazwę „Read more”, jednak jego zaprogramowana etykieta to „Details of our XYZ product”, użytkownik nie będzie w stanie aktywować przycisku za pomocą szybkiej, prostej komendy. Otóż jeśli widzi „Read more”, skąd niby ma wiedzieć, że ma powiedzieć „Details…”? No nie wie. I przycisku nie kliknie, przynajmniej nie tym sposobem. Zero dostępności, mnóstwo frustracji.

Podobnie sytuacja będzie wyglądać tutaj:

<button aria-label="Submit">Send</button>
<!-- P.S. Don’t do this -->

Kolejny przykład pokazuje inną popularną praktykę wśród programistów. I tak samo, jak powyżej: z dobroci serca, jednak bez sensu.

<button>
    Add <span class="visually-hidden">PRODUCT_NAME</span> to Cart
</button>
<!-- P.S. Don’t do this -->

Dodatkowy tekst w elemencie span ułatwia użytkownikom korzystającym z czytników rozpoznanie elementów, po których nawigują. Jednocześnie użytkownicy sterujący aplikacją za pomocą głosu nie są w stanie dodać produktu do koszyka. Widzą przycisk „Add to Cart”, wypowiadają jego nazwę, jednak aplikacja nie reaguje, oczekując komendy „Click Add PRODUCT_NAME to cart”.

Mam nadzieję, że już widzisz ideę problemu. Jednak dla lepszego zrozumienia tematu zachęcam Ciebie do zapoznania się z filmikiem pokazującym działanie jednego z najpopularniejszych programów do sterowania głosem – Dragon Naturally Speaking.

A teraz do brzegu, spróbujmy dowiedzieć się, jak dalej żyć z tymi etykietami.

Zanim jednak zajrzymy do dokumentacji, musimy wyjaśnić sobie nomenklaturę WCAG.

Name vs label

Na początku zwróćmy uwagę na bardzo ważną kwestię nazewnictwa – WCAG korzysta z określeń name oraz label, które są często źle rozumiane.

Label to „text or other component with a text alternative that is presented to a user to identify a component within Web content” (źródło). Spróbujmy po polsku – tekst (lub odrębny komponent zawierający tekst, np. obrazek z tekstem), prezentowany użytkownikowi w celu zidentyfikowania komponentu na stronie.

Name to „text by which software can identify a component within Web content to the user” (źródło). Dosłownie – tekst, dzięki któremu technologie asystujące potrafią zidentyfikować komponent na stronie. Może być ukryty wizualnie, dostępny tylko dla wspomnianych technologii asystujących. Nie ma nic wspólnego z atrybutem name w HTML! W internecie często jest nazywany jako accessible name, programmatic name.

Podsumowując – oba określenia odnoszą się do tekstu, który ma pomóc zidentyfikować element na stronie. Jednak label jest dedykowany użytkownikowi, natomiast name – technologiom asystującym. Bardzo często label jest takie samo, jak name. Jeśli jednak tak nie jest, może to powodować trudności w korzystaniu ze strony za pomocą technologii asystujących. W szczególności za pomocą oprogramowania do sterowania głosem….

Skoro rozumiemy podstawowe definicje name oraz lebel, możemy zajrzeć do dokumentacji.

Jak poprawić dostępność aplikacji dla osób korzystających z czytników jednocześnie nie rezygnując z dostępności dla osób sterujących aplikacją za pomocą głosu?

Jak zjeść ciasto i mieć ciastko?

Zacznijmy od WCAG 2.1 i spójrzmy na kryterium sukcesu 2.5.3 Label in Name (level A).

For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

Celem tego kryterium jest zapewnienie, że tekst widoczny w interfejsie (aka label) jest również zawarty w opisie komponentu (aka name). Dzięki temu owy komponent jest dostępny dla użytkowników różnych technologii asystujących.

Co to znaczy „jest zawarty”? W notatce do dokumentacji możemy przeczytać:

A best practice is to have the text of the label at the start of the name.

Ok, informacja o tym, że name powinno zaczynać się od treści label wydaje się rozwiewać część moich wątpliwości. Wiem już, jak powinna być zbudowana nazwa accessible name. Pozostaje jednak pytanie – w jaki sposób ją zaprogramować?

Accessible name

Wartość accessible name może być pozyskana z widocznej (np. tekst na przycisku) lub niewidocznej (np. wartość atrybutu aria-label) własności elementu interfejsu.

Element <label>, atrybuty aria-label , aria-labelledby, alt, title, desc(dla elementu SVG) mają zawsze wyższy priorytet niż widoczny opis.

Oprogramowania różnego rodzaju mogą przypisywać powyższym atrybutom/elementowi różny priorytet. Istnieje całkiem obszerny, przytłaczający algorytm, według którego każdy user agent określa accessible name. Zainteresowanych tematem polecam zacząć od algorytmu HMTL Acccessiblity API. Nie wchodząc w szczegóły, zapamiętajmy kilka zasad:

Wartość name zdefiniowana za pomocą powyższych atrybutów/elementu zawsze będzie miała wyższy priorytet niż widoczny label. Technologie asystujące określą name na podstawie widocznego opisu tylko wtedy, gdy element nie ma przypisanego żadnej etykiety w dodatkowych atrybutach.
Atrybuty z rodziny ARIA przeważnie mają wyższy priorytet niż inne atrybuty i mogą je nadpisywać.
Element <label>, atrybut alt mają wyższy priorytet niż atrybut title (zresztą o niefortunnej sytuacji atrybutu title pisałam już w tym artykule).

Była teoria, czas na praktykę.

Spróbujmy poprawić powyższe przykłady.

<button>Send</button>

Usunięcie atrybutu aria-label="Submit" było najlepszym pomysłem, bo… nie dawał żadnej wartości.

<button aria-label="Read more about details of our XYZ product.">Read more</button>

Accessible name zaczyna się od wartości label. Wszystko gra i buczy.

<button aria-describedby="Details of our XYZ product.">Read more</button>

Atrybut aria-describedby zostanie odczytany przez czytniki ekranu zaraz po odczytaniu jego dostępnej nazwy. Użytkownicy czytników dostaną porcję szczegółowej wiedzy, natomiast użytkownicy sterujący głosem nie mają problemu z nawigacją. Też dobre rozwiązanie!

<button>
    Add to Cart <span class="visually-hidden">, PRODUCT_NAME</span>
</button>

I tu podobnie, jak powyżej. Użytkownicy czytników ekranu usłyszą szczegółowe informacje na temat produktu. Użytkownicy sterujący głosem mogą powiedzieć „Add to cart”, a następnie oprogramowanie ponumeruje każdy z elementów, którego nazwa zaczyna się od „Add to cart”. Wypowiadając liczbę, użytkownik aktywuje odpowiedni element. Win win!

Podzielę się z Tobą jeszcze jednym przykładem, bardzo istotnym dla stron wielojęzycznych.

<h4 id="poor">Insufficient Link Names Invade Community</h4>
<p>Citizens are reeling from the growing invasion of useless "read more" links appearing in their online resources. <a href="poor.html" aria-labelledby="generic poor"><span id="generic">More...</span></a>

Accessible name to kombinacja widocznej nazwy odnośnika i nagłówka. Dzięki temu mamy pewność, że podczas tłumaczenia tekstu na różne języki nie zgubimy dostępności elementów.

Elementy bez widocznego opisu

Być może zastanawiasz się, w jaki sposób tworzyć etykiety dla elementów bez widocznego opisu (np. przyciski z ikonami, nawigacja karuzeli)? Dobrym rozwiązaniem jest skorzystanie z atrybutów aria-label oraz aria-labelledby. Jednak w tym artykule chciałabym skupić się na powyższym kryterium sukcesu 2.5.3, a ono nie odnosi się do tego przypadku.

Z punktu widzenia użytkownika sterującego głosem – komenda „kliknij w ikonę prawej strzałki” odpada, jednak istnieją też inne formy kontroli oprogramowania do sterowania głosem. Jednym z nich są komendy do poruszania się po stronie w taki sposób, w jaki poruszamy się klikając Tab na klawiaturze. Inną formą kontroli może być tzw. mouse grid, jednak nie będę zanudzać opisem jego działania. Zainteresowanych odnoszę do powyższego filmu pokazującego działanie Dragona.

Mimo wszystko pamiętajmy – są to formy kontroli o wiele mniej wygodne niż proste wydanie komendy „go to About”, „click About”. Istnienie innych opcji nie zwalnia nas z obowiązku pamiętania o etykietach przyjaznych użytkownikowi.

TLDR

Etykiety elementów interaktywnych są niezwykle ważne w dostępności. Uzupełniając je należy pamiętać zarówno o użytkownikach czytników ekranu, jak i oprogramowania do sterowania głosem. Według rekomendacji, ukryte etykiety powinny być takie same, jak widoczne opisy elementów lub powinny zaczynać się tymi samymi słowami, co widoczny tekst.

Źródła (inne, niż zamieszczone w treści):

Hola, hola, od początku poproszę.

Name vs label

Jak zjeść ciasto i mieć ciastko?

Accessible name

Była teoria, czas na praktykę.

Elementy bez widocznego opisu

TLDR

Artykuły, które mogą Ci się spodobać...