Jak szczerość na czytnikach ekranu pomaga wyleczyć się z ułatwień dostępu, jeśli nie trzeba w nim posypać soli.
Co to jest ARIA?
ARIA pozwala autorom stron internetowych tworzyć alternatywną rzeczywistość, dostrzegalną tylko dla czytników ekranu 🤥
Czasami trzeba rozwijać prawdę, a nawet sprecyzować, że czytniki ekranu informują, co dzieje się w treści internetowej. Na przykład: „tu wszystko jest w całości!” lub „To jest naprawdę suwak!”. To jak dodawanie magicznych notatek na stole do narzędzi i widżetów. Dzięki tym magicznym karteczkom każdy uwierzy, co jest na nich napisane.
Za każdym razem, gdy istnieje magiczna notatka, przewyższa nasze przekonanie o tym, do czego służy poszczególne narzędzia lub jakie są ich zalety. Przykład: „Tu tu jest pistolet do klejenia”. Chociaż na stole warsztatowym nadal jest puste, niebieskie pudełko, dzięki magicznej notatce zobaczysz, że to jest pistolet do kleju. Możemy też dodać informację „i jest zapełniony w 30%”. Czytnik ekranu poinformuje Cię, że jest tam 30% kleju.
W internecie odpowiednik jest taki, że wystarczy użyć elementu prostokątnego (elementu div) z obrazem w środku i użyć ARIA, aby wskazać, że suwak ma wartość 30 na 100.
Czym nie jest ARIA?
ARIA nie ma wpływu na wygląd strony internetowej ani na działanie myszy lub klawiatury. Tylko użytkownicy technologii wspomagających zauważą różnicę w stosunku do funkcji ARIA. Programiści stron internetowych mogą dodawać dowolne identyfikatory ARIA bez wpływu na użytkowników, którzy nie korzystają z technologii wspomagających osoby z niepełnosprawnością.
Dobrze czytasz: ARIA nie ma wpływu na zaznaczenie klawiatury ani kolejność kart. Wszystko to wpisuje się w HTML, czasem dopracowywane jego fragmenty.
Jak działa ARIA?
Czytnik ekranu lub inne technologie wspomagające przeglądarki pytają o informacje o każdym elemencie. Gdy w elemencie występuje ARIA, przeglądarka pobiera informacje i zmienia informacje, jakie przekazuje czytnikowi ekranu.
Dlaczego ARIA?
Po co mielibyśmy okłamywać naszych użytkowników?
Załóżmy, że lokalny sklep internetowy nie sprzedaje wszystkich potrzebnych widżetów. Ale jesteśmy MacGyver, cholera. Możemy po prostu wymyślać własne widżety na podstawie innych widżetów. FWIW, siedem najczęściej używanych przedmiotów MacGyver to szwajcarskie noże wojskowe, gumy do żucia, sznurki do butów, zapałki, spinacze, świece urodzinowe oraz taśmy klejące. Wykorzystuje je do konstruowania bomb i innych rzeczy, które nie są po prostu leżące. Wygląda to podobnie do autora, który musi stworzyć pasek menu. Paski menu są tak przydatne, że mogłoby się wydawać, że stanowią część HTML, ale tak nie jest. No cóż! Wydawało Ci się, że autorzy będą zadowoleni z linków i przycisków? Twórca zestawi więc wszystkie elementy, używając swoich ulubionych narzędzi: elementów div, obrazów, stylów, modułów obsługi kliknięć, modułów obsługi klawiszy, spitu i ARIA.
Czasami zamiast pełnego korzystania z ARIA używamy jej jako ulepszenia. Warto dodać trochę ARIA do kodu HTML, który już działa. Na przykład element sterujący formularza może wskazywać alert z komunikatem o błędzie dotyczący nieprawidłowych danych wejściowych. Możemy też wskazać, że pole tekstowe służy do wyszukiwania. Te drobne zmiany ułatwiają obsługę zwykłych stron internetowych z użyciem czytnika ekranu.
Przykład paska menu
Wspieramy osoby, które kliknęły myszką
Stwórzmy razem pasek menu. Pokazujemy grupy elementów w ogólnych elementach pola zwanych div. Za każdym razem, gdy użytkownik kliknie element div, wykona odpowiednie polecenie. Świetnie. To działa dla osób, które klikają myszą.
Następnie wszystko robimy ładnie. Używamy CSS, czyli stylów, wyrównuj elementy i umieszczamy wokół nich wizualne kontury. Dobieramy wygląd tak samo jak inne paski menu, które użytkownicy intuicyjnie wiedzą, że jest to pasek menu i jak z niego korzystać. Nasz pasek menu używa nawet innego koloru tła dla każdego elementu, który znajduje się po najechaniu myszą, dzięki czemu użytkownik może zobaczyć przydatne informacje.
Niektóre pozycje menu są elementami nadrzędnymi. Pojawią się podrzędne menu podrzędne. Gdy użytkownik najedzie kursorem na jedno z tych elementów, uruchamiamy animację, która wysuwa menu podrzędne.
Są one oczywiście niedostępne, tak jak w przypadku wielu elementów w internecie. Głównie dlatego, że kreatory standardów HTML nie dodały wszystkiego, czego potrzebuje autor stron internetowych. Nawet gdyby tak było, autorzy stron internetowych i tak chcieliby stworzyć własną wersję.
Ułatwianie dostępu do klawiatury na pasku menu
Na początek dodajemy ułatwienia dostępu z klawiatury. Ta część używa tylko 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 niekorzystających z technologii wspomagających.
Tak jak strona internetowa może reagować na ruch myszą, może też reagować na klawiaturę. Nasz kod JavaScript wychwytuje wszystkie naciśnięcia klawiszy i określa, czy dany klawisz jest przydatny. Jeśli nie, wyświetla ją z powrotem na stronę jak ryba, która jest zbyt mała, by ją zjeść. Oto nasze zasady:
- Jeśli użytkownik naciśnie klawisz strzałki, przyjrzyjmy się naszym wewnętrznym planom paska menu i zdecydujmy, jaka powinna być nowa aktywna pozycja menu. Usuniemy wszystkie wyróżnione informacje i wyróżnimy nową pozycję menu, aby użytkownik widzący wiedział, gdzie się znajduje. Strona internetowa powinna następnie wywołać
event.preventDefault(), aby uniemożliwić przeglądarce wykonanie standardowego działania (w tym przypadku przewinięcia strony). - Jeśli użytkownik naciśnie klawisz Enter, możemy traktować to jak kliknięcie i wykonać odpowiednie działanie (lub nawet otworzyć kolejne menu).
- Jeśli użytkownik naciśnie klawisz, który powinien wykonać inną czynność, nie rób go. Odrzuć go na stronę zgodnie z oczekiwaniami. Na przykład nasz pasek menu nie wymaga klawisza Tab, więc wystarczy go użyć. Ciężko jest do tego dopasować, a autorzy często fałszują. Na przykład do paska menu potrzebne są klawisze strzałek, ale nie Alt+strzałka ani Command+strzałka. Są to skróty do przechodzenia do poprzedniej/następnej strony w historii online na karcie przeglądarki. Jeśli autor nie będzie ostrożny, skorzysta z paska menu. Takie błędy zdarzają się bardzo często i nie zaczęliśmy jeszcze używać ARIA.
Dostęp czytnika ekranu do paska menu
Pasek menu został utworzony z tamy klejącej i elementów div. Dlatego czytnik ekranu nie ma pojęcia, co to jest. Kolor tła aktywnego elementu jest tylko kolorem. Elementy div pozycji w menu to po prostu obiekty bez żadnego znaczenia. W efekcie użytkownik paska menu nie otrzymuje instrukcji na temat tego, jakie klawisze należy nacisnąć ani na którym elemencie się kliknąć.
Ale to niesprawiedliwe! Pasek menu działa w dobrze widocznym miejscu.
Na ratunek. ARIA pozwala nam udawać, że czytnik ekranu znajduje się na pasku menu. Jeśli autor zrobi wszystko prawidłowo, nasz niestandardowy pasek menu będzie wyglądać na czytniku ekranu tak samo jak pasek menu w aplikacji komputerowej.
Pierwszym z nich jest użycie atrybutu aria-activedescendant i ustawienie go na identyfikator aktualnie aktywnego elementu menu. Pamiętaj, aby aktualizować go, gdy się zmieni. Przykład: aria-activedescendant="settings-menuitem". To małe białe kłódko powoduje, że czytnik ekranu traktuje aktywny element ARIA jako główny element, który jest odczytywany na głos lub wyświetlany na monitorze brajlowskim.
Termin element podrzędny oznacza, że element jest umieszczony gdzieś wewnątrz innego elementu. Odwrotny termin to element nadrzędny, czyli element zawarty w elemencie nadrzędnym. W przypadku następnego kontenera w górę/w dół można użyć bardziej szczegółowych terminów nadrzędnych/podrzędnych. Wyobraź sobie na przykład dokument, w którym znajduje się akapit. Elementem nadrzędnym linku jest akapit, ale w przypadku tego linku istnieje też jego element nadrzędny. I na odwrót, dokument może mieć wiele elementów podrzędnych, każde z linkami. Linki są elementami potomnymi dokumentu nadrzędnego.
Wróć do: aria-activedescendant. Dzięki temu, że wskażesz element menu z aktywnego paska menu, czytnik ekranu wie, gdzie przeszedł użytkownik, ale nie ma nic więcej o obiekcie. Co to w ogóle jest ten element div? Właśnie tu do akcji wkracza atrybut roli. Stosujemy role="menubar" w elemencie składowym. Następnie używamy role="menu" dla grup elementów oraz role="menuitem" dla... poszczególnych pozycji menu.
A co, jeśli element menu może prowadzić do menu podrzędnego? Użytkownik musi o tym wiedzieć? Użytkownik widzący na końcu menu może widzieć mały obraz trójkąta, ale przynajmniej na tym etapie czytnik ekranu nie wie, jak automatycznie odczytać obrazy. Do każdego rozwijanego elementu menu możemy dodać element aria-expanded="false", aby wskazać, że 1) jest coś, co można rozwinąć, i 2) element obecnie nie jest rozwinięty. Dodatkowo autor powinien umieścić w trójkącie obrazu atrybut role="none", aby wskazać, że służy on wyłącznie do uproszczenia. Dzięki temu czytnik ekranu nie powie nic o obrazie, które byłoby w największym stopniu nadmiarowe i może irytujące.
Usuwanie błędów
Błędy klawiatury (HTML!)
Choć korzystanie z klawiatury jest częścią podstawowego kodu HTML, autorzy przez cały czas plączą się w niej – dlatego, że rzadko poruszają się przy użyciu klawiatury, albo z powodu wielu niuansów, które trzeba tu rozwiązać.
Przykłady błędów:
- Pole wyboru przełącza się za pomocą spacji, ale autor zapomniał wywołać
preventDefault(). Teraz spacja przełącza pole wyboru i stronę w dół. Jest to domyślne działanie przeglądarki, jeśli chodzi o spację. - Okno modalne ARIA chce blokować nawigację po kartach, a autor zapomina o zezwoleniu na dostęp do przeglądarki za pomocą kombinacji klawiszy Control+Tab. Teraz klawisze Control+Tab po prostu poruszają się po oknie, ale nie przełączają kart w przeglądarce tak, jak powinny. Wrrr...
- Autor tworzy listę wyboru i implementuje nawigację w górę/w dół, ale nie implementuje nawigacji „home” (główna), „end”, „pageup” (strona „pageup”) ani „pagedown” bądź „pagedown”.
Autorzy powinni przestrzegać znanych wzorców. Więcej informacji znajdziesz w sekcji Materiały.
Jeśli masz problemy z dostępem do klawiatury, warto spróbować również bez czytnika ekranu lub po wyłączeniu trybu wirtualnej przeglądarki. Czytniki ekranu nie są zwykle potrzebne do wykrywania błędów klawiatury, a dostęp do klawiatury jest przeprowadzany za pomocą kodu HTML, a nie ARIA. W końcu ARIA nie ma wpływu na podstawowe funkcje, takie jak działanie klawiatury czy myszy, a jedynie informacje o tym, co znajduje się na stronie, co jest aktualnie zaznaczone itp.
Błędy klawiatury są prawie zawsze błędem w treści internetowej, a konkretnie w kodzie HTML i JavaScript – nie w ARIA.
Błędy ARIA: dlaczego jest ich tyle?
Jest wiele miejsc, w których autorzy mogą popełnić błąd ARIA. Każde z nich prowadzi do całkowitego uszkodzenia lub na drobne różnice. Bardziej subtelne są prawdopodobnie gorsze, ponieważ autor nie wyłapuje większości z nich przed opublikowaniem.
Jeśli autor nie ma doświadczenia w czytniku ekranu, w ARIA coś pójdzie nie tak. W przypadku paska menu autor może uznać, że rola „opcja” powinna zostać użyta, gdy element „menuitem” był prawidłowy. Mogą zapomnieć o korzystaniu z aria-expanded, zapomnieć o ustawieniu i wyczyszczeniu danych aria-activedescendant we właściwych momentach lub zapomnieć o pasku menu zawierającym inne menu.
A co z liczbą pozycji w menu? Zazwyczaj pozycje menu są wyświetlane przez czytniki ekranu razem z opisem na przykład „3 z 5”, dzięki czemu użytkownik wie, gdzie się znajduje. Zwykle jest to zliczane automatycznie przez przeglądarkę, ale w niektórych przypadkach, a w niektórych przypadkach, a w niektórych przypadkach, a w niektórych przypadkach, w przypadku niektórych kombinacji czytników ekranu może zostać obliczona nieprawidłowa liczba, a autor musi zastąpić te wartości wartościami aria-posinset i aria-setsize.
A to tylko paski menu. Zastanów się, ile rodzajów widżetów jest dostępnych. Jeśli chcesz, zerknij na specyfikację ARIA lub sposoby tworzenia treści. W przypadku każdego wzorca istnieje kilkanaście sposobów, aby niewłaściwie wykorzystać ARIA. ARIA polega na tym, że autorzy wiedzą, 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ą w 100% wypróbowywać widżety ARIA, zanim zostaną one uznane za możliwe do wysyłki. Za dużo niuansów. Najlepiej jest wypróbować kilka różnych kombinacji czytników ekranu w przeglądarce i czytników ekranu. Jest to możliwe ze względu na liczne problemy związane z implementacją oraz kilka niekompletnych implementacji.
Podsumowanie
Podsumowując, magia ARIA może służyć do zastępowania lub uzupełniania wszystkich treści w kodzie HTML. Można za jego pomocą wprowadzić drobne zmiany w prezentacji ułatwień dostępu lub uzyskać pełny efekt. Dlatego w rękach naszych przyjaznych lokalnych autorów treści, którzy zwykle nie używają czytników ekranu, ARIA jest niezwykle zaawansowana, a jednocześnie niebezpieczna.
ARIA to po prostu warstwa znaczników zastąpień obserwacyjnych. Gdy czytnik ekranu zapyta, co się dzieje, i jeśli system ARIA istnieje, otrzyma wersję prawdy ARIA, a nie prawdziwą, bazową prawdę.
Załącznik 1. Dodatkowe materiały
Odniesienie hybrydowe z informacjami o klawiaturze i przykładami kodu
- Zasady W3C tworzenia treści ARIA: dokumentują ważne cechy nawigacji z użyciem klawiatury w każdym przykładzie i dostarczają działający kod JS/CSS/ARIA. Koncentrują się one na tym, co obecnie się sprawdza, a nie na urządzeniach mobilnych.
Załącznik 2. Do czego najczęściej używa się ARIA?
Ponieważ ARIA może zastępować lub uzupełniać małe lub duże prawdy, jest to zwykle przydatne do mówienia rzeczy, na których zależy czytnikowi ekranu.
Oto kilka typowych zastosowań ARIA.
- specjalne widżety, których nie ma w kodzie HTML, takie jak pasek menu, autouzupełnianie, drzewo lub arkusz kalkulacyjny;
- Widżety obecne w kodzie HTML, ale i tak ich autor wymyślił własne, prawdopodobnie dlatego, że musiał dostosować działanie lub wygląd zwykłego widżetu. Na przykład element HTML
<input type="range">jest w zasadzie suwakiem, ale autorzy chcą go zmienić. W większości przypadków można używać CSS, ale w przypadkuinput type="range"ten kod jest niezrozumiały. Autor może utworzyć własny suwak i użyć na nim elementurole="slider"wraz z atrybutemaria-valuenow, aby określić aktualną wartość. - Regiony aktywne informują czytniki ekranu, że „w tym obszarze strony warto poinformować użytkownika o wszystkim, co się zmieni”.
- punkty orientacyjne (w formacie HTML dostępne są obecnie odpowiedniki). Przypomina to nieco nagłówki, ponieważ pomagają użytkownikom czytników ekranu szybciej znajdować to, czego szukają. Różnią się one jednak tym, że obejmują cały powiązany obszar. np. „ten kontener to główny obszar strony” czy „ten kontener to panel użytkownika”.
Załącznik 3. Co to jest interfejs Accessibility API?
Dzięki Accessibility API czytnik ekranu lub inny pracownik obsługi klienta wie, co znajduje się na stronie i co się dzieje w danej chwili. Przykłady to MSAA, IA2 i UIA. A to tylko Windows! Interfejs Accessibility API składa się z 2 części:
- „Drzewo” obiektów reprezentujące hierarchię kontenera. Wyglądają jak rosyjskie lalki, ale każda z nich może zawierać kilka innych lalek. Na przykład dokument może zawierać kilka akapitów, a akapit z tekstem, obrazami, linkami, pogrubieniem itp. Każdy element w drzewie obiektów może mieć takie właściwości jak rola (czym jestem?), nazwa/etykieta, wartość wpisana przez użytkownika, opis oraz stany wartości logicznej, takie jak „możliwy do zaznaczenia”, „zaznaczony”, „wymagany”, zaznaczone. ARIA może zastąpić każdą z tych właściwości. Czytnik ekranu korzysta z drzewa, aby ułatwić użytkownikowi nawigowanie w trybie wirtualnego bufora, np. „Przejdź do następnego nagłówka”.
- Seria zdarzeń opisujących zmiany w drzewie, np. „fokus jest teraz tutaj!”. Czytnik ekranu używa zdarzeń, aby poinformować użytkownika, co się właśnie wydarzyło. Gdy ważne zmiany w znacznikach HTML lub ARIA zostaną zmienione, wywoływane jest zdarzenie informujące czytnik ekranu o tym, że coś się zmieniło.
Zwykle autorzy używają po prostu kodu HTML, który dobrze odpowiada tym interfejsom API ułatwień dostępu. Gdy kod HTML jest niewystarczający, używany jest standard ARIA, a przeglądarka zastępuje semantykę HTML przed wysłaniem drzewa obiektów lub zdarzeń do czytnika ekranu.