ARIA: trucizna czy antidotum?

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 notatka, zastępuje ona nasze przekonania na temat tego, do czego każde narzędzie jest lub czym jest. 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żemy też dodać: „i jest w 30% zapełniony!”. Czytnik ekranu zgłasza teraz, że pistolet do klejenia w 30% jest w pełni wyposażony.

Odpowiednikiem tego na stronie internetowej jest zwykłe pole div z obrazem, w którym za pomocą atrybutów ARIA określa się, że jest to suwak o wartości 30 na 100. ARIA nie powoduje, że divstaje się suwakiem. Po prostu mówi czytnikowi ekranu, że jest to suwak.

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

Czytelnie: ARIA nie wykonuje żadnej czynności w zakresie zaznaczenia klawiatury ani kolejności kart. Wszystko to robi się w języku HTML, niekiedy dodając fragmenty JavaScriptu.

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 na nowo wymyślić, być może dlatego, że chciał zmienić działanie lub wygląd elementu standardowego. Na przykład element HTML <input type="range"> jest suwakiem, ale autorzy chcą, żeby 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ą. Punkty orientacyjne mogą obejmować cały powiązany obszar. Na przykład: „ten kontener to główna część strony” i „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 po prostu wymyślić własne widżety z 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 brukowane za pomocą elementów div, obrazów, przycisków, modułów obsługi kliknięć, uchwytów naciśnięć klawiszy i ARIA.

Pomoc dla użytkowników myszy

Razem utworzymy pasek menu. Wyświetlamy wiele elementów w elementach typu box o nazwie div. 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ą.

a potem dbamy o to, by wszystko wyglądało ładnie. Używamy CSS, by wyrównać elementy i obramować je obramowaniem. Sprawiamy, że wygląda on na tyle jak inne paski menu, dzięki czemu osoby korzystające z niego intuicyjnie wiedzą, że to jest pasek menu. Nasz pasek menu ma nawet inny kolor tła w przypadku każdego elementu, nad którym znajduje się kursor myszy, co zapewnia użytkownikowi przydatne informacje zwrotne.

Niektóre pozycje menu należą do elementów nadrzędnych. Tworzone są podrzędne menu 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 w postaci klawiatury. Wymaga to tylko zmian w HTML, a nie w 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, tak samo może reagować na klawiaturę. Nasz JavaScript wykrywa wszystkie naciśnięcia klawiszy i decyduje, czy naciśnięcie klawisza jest przydatne. Jeśli nie, wraca na stronę jak ryba, która nie mogła go zjeść. Nasze zasady są takie:

• 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. Usuniemy wszystkie aktualnie wyróżnione pozycje i wyróżnimy nową pozycję w menu, aby użytkownik mógł zobaczyć, 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ć inne działanie, 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 do obliczenia. Na przykład pasek menu wymaga klawiszy strzałek, ale nie Alt + Strzałka ani Command + Strzałka. To skróty do poprzedniej i następnej strony w historii przeglądania na karcie przeglądarki. Jeśli autor nie będzie ostrożny, pasek menu je zje. 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. Divy 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.

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

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

Naszym pierwszym kłamstwem ARIA jest atrybut aria-activedescendant. Ustaw atrybut na identyfikator aktywnego elementu menu, pamiętając o jego aktualizowaniu po każdej zmianie. Na przykład: aria-activedescendant="settings-menuitem". Czytnik ekranu uzna aktywny element ARIA za element skupienia, który jest odczytywany na głos lub wyświetlany na wyświetlaczu brajlowskim.

Gdy używasz aria-activedescendant, aby wskazać od skoncentrowanego paska menu konkretny element 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 z tego diva? Dlatego właśnie potrzebny jest atrybut roli. Używamy elementu role="menubar" w przypadku elementu zawierającego całą rzecz, a elementu role="menu" w przypadku grup elementów. Element role="menuitem" stosujemy w przypadku poszczególnych pozycji menu.

A jeśli pozycja menu może prowadzić do menu podrzędnego? 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ć na trójkącie img znakrole="none", aby wskazać, że jest to produkt do użytku kosmetycznego. Zapobiega to temu, aby czytnik ekranu mówił o obrazie coś zbędnego.

Naprawianie błędów klawiatury

Chociaż dostęp do 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 przez naciśnięcie Ctrl + Tab w oknie dialogowym, funkcja nie będzie działać zgodnie z oczekiwaniami.
• Autor tworzy listę elementów i wdraża klawisze w górę i w dół. Trzeba jednak dodać opcje nawigacji na stronie głównej, końcowej, Page-up, Pagedown lub pierwszej litery.

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 i myszy. Odczytuje na podstawie zawartości strony internetowej, co aktualnie znajduje się w przeglądarce itd.

Błędy na klawiaturze to prawie zawsze błędy w treściach internetowych, zwłaszcza w kodzie HTML i JavaScript, a nie w ARIA.

Dlaczego jest ich tak dużo?

Autor może popełnić wiele błędów w przypadku atrybutów ARIA. Każdy błąd prowadzi do całkowitego uszkodzenia lub drobnych różnic. Subtelne problemy mogą być jeszcze gorsze, ponieważ autor mało prawdopodobne jest, aby je wychwycić przed opublikowaniem.

W końcu, chyba że autor jest doświadczonym użytkownikiem czytnika ekranu, w ARIA coś pójdzie nie tak. 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 liczone automatycznie przez przeglądarkę, ale w niektórych przypadkach i w niektórych przypadkach, gdy kombinacja czytnika ekranu będzie używana w przeglądarce, mogą zostać obliczone nieprawidłowe liczby, w związku z czym autor powinien je zastąpić wartościami aria-posinset i aria-setsize.

A to tylko paski menu. Pomyśl, 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żyć 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. Z powodu licznych problemów z implementacją i kilku niepełnych implementacji w idealnej sytuacji najlepiej korzystać z kilku różnych kombinacji czytnika ekranu w przeglądarce.

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 ułatwień dostępu lub stworzyć całą sekcję. Dlatego ARIA jest niesamowita i niezwykle niebezpieczna w przypadku naszych programistów, którzy nie korzystają z 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

W3C ARIA Authoring Practices zawiera ważne informacje o charakterystyce nawigacji za pomocą klawiatury w każdym przykładzie oraz zapewnia działające kody JavaScript, CSS i ARIA. Przykłady koncentrują się na tym, co działa obecnie, i nie obejmują urządzeń mobilnych.

Co to jest interfejs API Accessibility?

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 to MSAA, IA2 i UIA. Interfejs Accessibility API składa się z 2 części:

• „Drzewo” obiektów reprezentujące 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 to jest), nazwa lub etykieta, wartość wpisana przez użytkownika, opis oraz stany logiczne (np. do zaznaczenia, zaznaczone, wymagane, 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. „fokus jest teraz tutaj”. Czytnik ekranu wykorzystuje zdarzenia, aby poinformować użytkownika, co właśnie się wydarzyło. W przypadku zmiany ważnych znaczników HTML lub ARIA wywoływane jest zdarzenie, które informuje czytnik ekranu o tym, że coś się zmieniło.

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.