ARIA: trucizna czy antidotum?

Aaron Leventhal

Co to jest ARIA?

ARIA pozwala autorom stron internetowych tworzyć alternatywną rzeczywistość, widoczną tylko dla czytników ekranu.

Czasami konieczne jest rozszerzenie prawdy lub nawet „okłamywanie” czytników ekranu na temat tego, co dzieje się w treściach internetowych. Na przykład „focus is really over here!” (skupienie uwagi na tym miejscu) lub „this is really a slider!” (to jest suwak). To jak dodanie magicznych samoprzylepnych karteczek na narzędziach i widżetach na pulpicie. Te magiczne karteczki samoprzylepne sprawiają, że wszyscy wierzą w to, co na nich jest napisane.

Gdy istnieje magiczna samoprzylepna notatka, zastępuje ona nasze przekonania o tym, czym jest lub co robi dane narzędzie. Jeśli na przykład dodasz atrybuty ARIA, które mówią, że „to urządzenie to pistolet do kleju”. Mimo że jest to puste niebieskie pudełko, magiczna notatka samoprzylepna mówi nam, że to pistolet do kleju. Możesz też dodać „i jest w 30% pełni”. Czytnik ekranu informuje, że pistolet na klej jest napełniony w 30%.

Odpowiednikiem tego na stronie internetowej jest zwykłe pole div z obrazem wewnątrz, w którym atrybut ARIA określa, że jest to suwak o wartości 30 na 100. ARIA nie powoduje, że divstaje się suwakiem. Tylko informuje czytnik ekranu, że jest to suwak.

ARIA nie wpływa na wygląd strony internetowej ani na zachowanie użytkownika korzystającego z myszy lub klawiatury. Wpływ ARIA jest zauważalny tylko przez użytkowników technologii wspomagających. Deweloperzy mogą dodawać dowolne atrybuty ARIA bez wpływu na użytkowników, którzy nie korzystają z technologii wspomagającej.

Tak, dobrze czytasz: ARIA nie ma wpływu na skupianie się na klawiaturze ani kolejność kart. Wszystko to jest zrobione w HTML, czasami z dodatkiem fragmentów kodu JavaScript.

Jak działa ARIA?

Czytniki ekranu lub inne technologie wspomagające proszą przeglądarki o informacje o każdym elemencie. Gdy element zawiera atrybuty ARIA, przeglądarka pobiera informacje i zmienia to, co mówi czytnikowi ekranu o tym elemencie.

Oto kilka typowych zastosowań ARIA.

• dodawać komponenty specjalne, których nie ma w HTML, np. autouzupełnianie, drzewo czy arkusz kalkulacyjny;
• Dodawanie komponentów, które istnieją w HTML, ale autor postanowił je zmienić, być może dlatego, że chciał zmienić działanie lub wygląd elementu standardowego. Na przykład element HTML <input type="range"> to tak naprawdę suwak, ale autorzy chcą, aby wyglądał inaczej.
  • W większości przypadków można to rozwiązać za pomocą CSS. Jednak w przypadku range usługa porównywania cen jest niewygodna. Autorzy mogą tworzyć własne suwaki i używać role="slider" z aria-valuenow, aby powiedzieć klawiaturze, jaka jest aktualna wartość.
• Uwzględnij regiony na żywo, aby poinformować czytniki ekranu o odpowiednich zmianach w danym obszarze strony.
• Tworzenie punktów orientacyjnych, takich jak nagłówki. Punkty orientacyjne pomagają użytkownikom czytników ekranu szybciej znajdować to, czego szukają. Miejsca warte odwiedzenia mogą obejmować cały obszar. Na przykład „ten kontener jest główną częścią strony” lub „ten kontener to panel nawigacyjny”.

Dlaczego ARIA?

Warto dodać tagi ARIA do kodu HTML, który już działa. Możemy na przykład użyć elementu sterującego w formularzu, aby wyświetlić komunikat o błędzie w przypadku nieprawidłowego wprowadzenia danych. Możemy też chcieć wskazać konkretne zastosowanie tekstu. Te drobne zmiany mogą ułatwić korzystanie z zwykłych witryn za pomocą czytnika ekranu.

Przykład paska menu

Załóżmy, że lokalny sklep internetowy nie sprzedaje wszystkich potrzebnych nam widżetów. Ale jesteśmy MacGyver. Możemy tworzyć własne widżety na podstawie innych widżetów. Jest to podobne do sytuacji, gdy autor witryny musi utworzyć pasek menu.

Chociaż element <nav> istnieje, paski menu są często sklejane za pomocą divów, obrazów, przycisków, elementów obsługi kliknięć, elementów obsługi naciśnięcia klawisza oraz ARIA.

Pomoc dla użytkowników myszy

Zbudujmy razem pasek menu. Wyświetlamy wiele elementów w elementach typu box, zwanych divami. Za każdym razem, gdy użytkownik kliknie element div, zostanie wykonane odpowiednie polecenie. Świetnie, działa to w przypadku osób używających gier z myszką.

Następnie nadajemy mu ładny wygląd. Używamy CSS do ładnego wyrównywania elementów i umieszczania wokół nich wizualnych konturów. Sprawiamy, że wygląda ono na tyle podobnie do innych pasków menu, że użytkownicy intuicyjnie wiedzą, że to pasek menu i jak z niego korzystać. Nasz pasek menu ma nawet inny kolor tła w przypadku każdego elementu, nad którym znajduje się kursor myszy, co daje użytkownikowi przydatne informacje zwrotne.

Niektóre pozycje menu są elementami nadrzędnymi. Tworzą one podmenu podrzędne. Gdy użytkownik najedzie na jeden z nich, rozpocznie się animacja, która wysunie podmenu podrzędne.

To wszystko jest dość niedostępne, jak to zwykle bywa w internecie.

Dostęp do paska menu za pomocą klawiatury

Dodajmy ułatwienia dostępu z klawiatury. Wymaga to tylko zmian w HTML, a nie ARIA. Pamiętaj, że ARIA nie ma wpływu na podstawowe aspekty, takie jak wygląd, mysz czy klawiatura, w przypadku użytkowników bez technologii wspomagających.

Podobnie jak strona internetowa reaguje na mysz, może też reagować na klawiaturę. Nasz kod JavaScript może rejestrować wszystkie wciśnięcia klawiszy i określać, czy są one przydatne. Jeśli nie, zwraca go na stronę jak rybę, która jest za mała, aby ją zjeść. Nasze zasady są następujące:

• Jeśli użytkownik naciśnie klawisz strzałki, spójrzmy na nasze wewnętrzne szablony paska menu i zdecydujmy, jaka powinna być nowa aktywna pozycja menu. Wyłączymy wszystkie obecne wyróżnienia i wyróżnimy nowy element menu, aby widzący użytkownik wiedział, gdzie się znajduje. Strona internetowa powinna wtedy wywołać funkcję event.preventDefault(), aby uniemożliwić przeglądarce wykonanie zwykłego działania (w tym przypadku przewijania strony).
• Jeśli użytkownik naciśnie klawisz Enter, możemy potraktować to jak kliknięcie i wykonać odpowiednie działanie (lub nawet otworzyć inne menu).
• Jeśli użytkownik naciśnie klawisz, który powinien wywołać inną funkcję, prześlij go z powrotem na stronę. Na przykład nasz pasek menu nie potrzebuje klawisza Tab, więc go odrzuć. To nie jest łatwe. Na przykład pasek menu wymaga klawiszy strzałek, ale nie Alt + Strzałka ani Command + Strzałka. To skróty do przechodzenia do poprzedniej i następnej strony w historii przeglądania na karcie przeglądarki. Jeśli autor nie będzie ostrożny, pasek menu zje te elementy. Tego typu błędy zdarzają się często, a my jeszcze nie zaczęliśmy nawet korzystać z ARIA.

Dostęp czytnika ekranu do paska menu

Nasz pasek menu został stworzony za pomocą taśmy klejącej i divów. W efekcie czytnik ekranu nie ma pojęcia, co to jest. Kolor tła aktywnego elementu to tylko kolor. Elementy div pozycji menu to zwykłe obiekty bez szczególnego znaczenia. W rezultacie użytkownik naszego paska menu nie otrzymuje żadnych instrukcji dotyczących tego, które klawisze ma nacisnąć ani na którym elemencie się znajduje.

To niesprawiedliwe. Pasek menu działa prawidłowo dla widzących użytkowników.

ARIA na ratunek. ARIA pozwala nam symulować czytnikowi ekranu, że fokus znajduje się na pasku menu. Jeśli autor wszystko zrobi prawidłowo, nasz niestandardowy pasek menu będzie dla czytnika ekranu wyglądał tak samo jak pasek menu w aplikacji na komputer.

Pierwsza sztuczka polega na tym, że atrybut aria-activedescendant jest fałszywy. Ustaw atrybut na identyfikator aktywnej pozycji menu, pamiętając o jego aktualizowaniu po każdej zmianie. Na przykład: aria-activedescendant="settings-menuitem". W efekcie czytnik ekranu uzna aktywny element ARIA za element skupienia, który jest odczytywany na głos lub wyświetlany na wyświetlaczu brajlowskim.

Wyjaśnienie pojęć przodek, rodzic i potomek

Termin „potomek” odnosi się do faktu, że element jest zawarty w innym. Termin przeciwstawny to „przodek”, co oznacza, że element jest zawarty w przodkach. W przypadku następnego kontenera w górę lub w dół mogą być używane bardziej szczegółowe terminy nadrzędny/podrzędny. Wyobraź sobie na przykład dokument z akapitem zawierającym link. Element nadrzędny linku to akapit, ale ma też dokument jako element nadrzędny. Z drugiej strony dokument może mieć wiele akapitów podrzędnych, z których każdy ma linki. Linki to wszystkie elementy podrzędne dokumentu nadrzędnego.

Gdy używasz aria-activedescendant, aby wskazać od skoncentrowanego paska menu do konkretnego elementu menu, czytnik ekranu wie, gdzie użytkownik się przemieścił, ale nie wie nic więcej o tym obiekcie. Co to w ogóle jest za element div? Dlatego właśnie istnieje atrybut rola. Używamy elementu role="menubar" w przypadku elementu zawierającego całą rzecz, a potem elementu role="menu" w przypadku grup elementów i elementu role="menuitem" w przypadku poszczególnych pozycji menu.

A co, jeśli element menu prowadzi do podmenu? Użytkownik musi o tym wiedzieć. W przypadku osób widzących na końcu menu może znajdować się mały obrazek trójkąta, ale czytnik ekranu nie potrafi automatycznie odczytywać obrazów, przynajmniej na razie. Możemy dodać aria-expanded="false" do każdego elementu menu, który można rozwinąć, aby wskazać, że można go rozwinąć. Dodatkowo autor powinien umieścić znakrole="none" na trójkącie img, aby wskazać, że jest to produkt do użytku wyłącznie w celach kosmetycznych. Zapobiega to temu, aby czytnik ekranu mówił o obrazie coś zbędne.

Naprawianie błędów klawiatury

Chociaż dostęp za pomocą klawiatury jest częścią podstawowego kodu HTML, można go łatwo nadpisać. Przykład:

• Pole wyboru używa spacji do przełączania, ale autor zapomniał wywołać funkcję preventDefault(). Teraz spacja przełącza pole wyboru i przewija stronę w dół, co jest domyślnym zachowaniem przeglądarki w przypadku spacji.
• Okno modalne ARIA chce zablokować nawigację kartami. Jeśli autor zapomni zezwolić na otwieranie nowej karty za pomocą skrótu Ctrl + Tab, funkcja ta nie będzie działać zgodnie z oczekiwaniami.
• Autor tworzy listę elementów i implementuje klawisze w górę i w dół. Autor musi jednak dodać klawisze Home, End, PageUp, PageDown lub First Letter.

Autorzy powinni stosować znane wzorce. Więcej informacji znajdziesz w sekcji Materiały.

W przypadku problemów z klawiaturą warto też sprawdzić, czy nie występują one bez czytnika ekranu lub z wyłączonym trybem przeglądarki wirtualnej. Błędy związane z klawiaturą możesz wykryć bez czytnika ekranu, ponieważ dostęp za pomocą klawiatury jest realizowany za pomocą HTML, a nie ARIA. W końcu ARIA nie wpływa na działanie klawiatury ani myszy. Zamiast tego podaje czytnikowi ekranu informacje o tym, co znajduje się na stronie internetowej, co jest obecnie w fokusie itp.

Błędy związane z klawiaturą to prawie zawsze błąd w treściach internetowych, a w szczególności w HTML i JavaScript, a nie w ARIA.

Dlaczego jest ich tak dużo?

Autor może popełnić wiele błędów związanych z ARIA. Każdy błąd prowadzi do całkowitego uszkodzenia lub niewielkich różnic. Subtelne problemy mogą być jeszcze gorsze, ponieważ autor może ich nie zauważyć przed opublikowaniem.

W końcu, jeśli autor nie jest doświadczonym użytkownikiem czytnika ekranu, coś może pójść nie tak w przypadku atrybutów ARIA. W przykładzie paska menu autor mógł sądzić, że należy użyć roli „option”, podczas gdy prawidłowa była rola „menuitem”. Mogą zapomnieć użyć funkcji aria-expanded, zapomnieć ustawić i wyczyścić zmienną aria-activedescendant we właściwym czasie lub zapomnieć o pasku menu zawierającym inne menu. A jak jest z liczbą pozycji menu? Czytniki ekranu zwykle wyświetlają elementy menu jako „element 3 z 5”, aby użytkownik wiedział, gdzie się znajduje. Zwykle jest to zliczane automatycznie przez przeglądarkę, ale w niektórych przypadkach i w niektórych kombinacjach przeglądarki i czytnika ekranu mogą być zliczane nieprawidłowe liczby. W takim przypadku autor musi zastąpić te liczby wartościami aria-posinset i aria-setsize.

A to tylko paski menu. Zastanów się, ile jest rodzajów widżetów. Zapoznaj się ze specyfikacją ARIA lub sprawdzonymi metodami pisania. W przypadku każdego wzorca można niewłaściwie używać atrybutów ARIA na kilkanaście sposobów. ARIA wymaga, aby autorzy wiedzieli, co robią. Co może pójść nie tak, skoro większość autorów nie korzysta z czytników ekranu?

Innymi słowy, użytkownicy czytników ekranu muszą mieć możliwość przetestowania widżetów ARIA, zanim będą mogli je wdrożyć. Za dużo niuansów. W idealnej sytuacji wszystko powinno zostać przetestowane z kilkoma różnymi kombinacjami przeglądarek i czytników ekranu, ponieważ istnieją liczne dziwactwa związane z wdrożeniem, a dodatkowo niektóre wdrożenia są niekompletne.

Podsumowanie

Atrybuty ARIA mogą być używane do zastąpienia lub uzupełnienia dowolnego elementu w pliku HTML. Możesz wprowadzić drobne zmiany w prezentacji dostępności lub stworzyć całą sekcję. Z tego powodu ARIA jest niesamowicie potężna, ale jednocześnie niebezpieczna w rękach naszych deweloperów, którzy nie są użytkownikami czytników ekranu.

ARIA to warstwa znaczników, która zastępuje inne opcje. Gdy czytnik ekranu zapyta, co się dzieje, użytkownik otrzyma wersję ARIA.

Dodatkowe materiały

W dokumentach W3C ARIA Authoring Practices znajdziesz ważne informacje o poruszaniu się po interfejsie za pomocą klawiatury w każdym przykładzie. Znajdziesz tam też działające kody JavaScript, CSS i ARIA. Przykłady koncentrują się na tym, co działa obecnie, i nie dotyczą urządzeń mobilnych.

Co to jest interfejs API Accessibility API?

Interfejs API ułatwień dostępu pozwala czytnikowi ekranu lub innej technologii wspomagającej określić, co znajduje się na stronie i co się na niej dzieje. Przykłady: MSAA, IA2 i UIA. Interfejs Accessibility API składa się z 2 części:

• „Drzewo” obiektów, które reprezentuje hierarchię kontenerów. Dokument może na przykład zawierać wiele akapitów. Akapit może zawierać tekst, obrazy, linki i elementy dekoracyjne. Każdy element w drzewie obiektów może mieć właściwości, takie jak rola (co reprezentuję?), nazwa lub etykieta, wartość wprowadzona przez użytkownika, opis oraz stany logiczne, takie jak focusable (możliwość skupienia), focused (skupienie), required (wymaganie) i checked (zaznaczone). ARIA może zastąpić dowolną z tych właściwości.
  • Czytniki ekranu korzystają z drzewa, aby ułatwić użytkownikom poruszanie się w trybie bufora wirtualnego, na przykład „Przejdź do następnego nagłówka”.
• Seria zdarzeń opisujących zmiany w drzewie, np. „focus is now over here!” (skup się tutaj). Czytnik ekranu używa zdarzeń, aby poinformować użytkownika o tym, co się właśnie stało. Gdy zmieni się ważny znacznik HTML lub znacznik ARIA, zostanie wywołane zdarzenie, aby poinformować czytnik ekranu o zmianie.

HTML dobrze współpracuje z tymi interfejsami API ułatwień dostępu. Jeśli HTML nie wystarcza, możesz dodać ARIA, aby przeglądarka zastąpiła semantykę HTML przed wysłaniem drzewa obiektów lub zdarzeń do czytnika ekranu.