Wprowadzenie do drzewa ułatwień dostępu
Wyobraź sobie, że tworzysz interfejs użytkownika tylko dla użytkowników czytników ekranu. W tym przypadku nie musisz tworzyć żadnego wizualnego interfejsu – wystarczy podać wystarczającą ilość informacji, aby czytnik ekranu mógł z niego korzystać.
W tym przypadku tworzymy interfejs API opisujący strukturę strony, podobny do interfejsu DOM API, ale niewiele informacji można uzyskać, mając do dyspozycji mniej informacji, ponieważ wiele z tych informacji nadaje się tylko do prezentacji wizualnej. Może to wyglądać mniej więcej tak.
![Model DOM API czytnika ekranu](https://web.developers.google.cn/static/articles/the-accessibility-tree/image/screen-reader-dom-api-moc-86f15b848dd25.jpg?authuser=0000&hl=pl)
To w rzeczywistości to, co przeglądarka przedstawia czytnikowi ekranu. Przeglądarka pobiera drzewo DOM i modyfikuje je do postaci przydatnej dla technologii wspomagającej. To zmodyfikowane drzewo nazywamy drzewem ułatwień dostępu.
Drzewo ułatwień dostępu może wyglądać jak stara strona internetowa z lat 90. – kilka obrazów, dużo linków, a może pole i przycisk.
![strona w stylu lat 90.](https://web.developers.google.cn/static/articles/the-accessibility-tree/image/a-1990s-style-web-page-71a74592e602e.png?authuser=0000&hl=pl)
Wizualne skanowanie strony, tak jak w tym przypadku, działa podobnie jak w przypadku czytnika ekranu. Dostępny jest interfejs, ale jest prosty i bezpośredni, jak w przypadku drzewa ułatwień dostępu.
Drzewo ułatwień dostępu to elementy, z którymi najczęściej wchodzą w interakcje technologie wspomagające osoby z niepełnosprawnością. Przepływ wygląda mniej więcej tak.
- Aplikacja (przeglądarka lub inna aplikacja) za pomocą interfejsu API udostępnia semantyczną wersję swojego interfejsu technologii wspomagającej osoby z niepełnosprawnością.
- Technologia wspomagająca może wykorzystać informacje odczytane przez interfejs API do utworzenia alternatywnej prezentacji interfejsu użytkownika. Na przykład czytnik ekranu tworzy interfejs, w którym użytkownik słyszy wypowiadaną reprezentację aplikacji.
- Technologia wspomagająca osoby z niepełnosprawnością może też umożliwiać użytkownikowi korzystanie z aplikacji w inny sposób. Na przykład większość czytników ekranu ma haki umożliwiające łatwe symulowanie kliknięcia myszą lub dotknięcia palcem.
- Technologia wspomagająca przekazuje intencję użytkownika (np. „kliknięcie”) z powrotem do aplikacji za pomocą interfejsu Accessibility API. To aplikacja odpowiada za właściwą interpretację działania w kontekście pierwotnego interfejsu.
W przypadku przeglądarek trzeba wykonać dodatkowy krok w każdym kierunku, ponieważ przeglądarka jest w rzeczywistości platformą dla aplikacji internetowych, które działają w niej. Przeglądarka musi więc przetłumaczyć aplikację internetową na drzewo ułatwień dostępu i upewnić się, że odpowiednie zdarzenia są wywoływane w języku JavaScript na podstawie działań użytkownika pochodzących z technologii wspomagającej osoby z niepełnosprawnością.
Jednak to cała odpowiedzialność przeglądarki. Jako programista chcemy mieć świadomość tego, co się dzieje i tworzyć strony, które korzystają z tego procesu, aby zwiększyć wygodę użytkowników.
Robimy to, upewniając się, że poprawnie określają semantykę naszych stron, czyli czy ważne elementy na stronie mają prawidłowe dostępne role, stany i właściwości, a także określamy łatwo dostępne nazwy i opisy. Dzięki temu przeglądarka może udostępnić te informacje technologii wspomagającej osoby z niepełnosprawnością, aby spersonalizować działanie usługi.
Semantyka w natywnym kodzie HTML
Przeglądarka może przekształcić drzewo DOM w drzewo ułatwień dostępu, ponieważ większość elementów DOM ma ukryte znaczenie semantyczne. Oznacza to, że interfejs DOM korzysta z natywnych elementów HTML, które są rozpoznawane przez przeglądarki i działają przewidywalnie na różnych platformach. Ułatwienia dostępu w przypadku natywnych elementów HTML, takich jak linki i przyciski, są obsługiwane automatycznie. Możemy wykorzystać tę wbudowaną dostępność, pisząc kod HTML, który odzwierciedla semantykę elementów strony.
Czasami używamy jednak elementów, które wyglądają jak elementy natywne, ale nimi nie są. Na przykład ten „przycisk” w ogóle nie jest przyciskiem.
Może ona być skonstruowana w kodzie HTML na wiele sposobów; jeden z nich został przedstawiony poniżej.
<div class="button-ish">Give me tacos</div>
Gdy nie są używane elementy przycisku, czytnik ekranu nie jest w stanie ustalić, na którym miejscu trafił. Musielibyśmy też dodać tabindex, aby był dostępny tylko dla użytkowników korzystających tylko z klawiatury. Jest on już zakodowany, dlatego można z niego korzystać tylko za pomocą myszy.
Możemy to łatwo naprawić, używając zwykłego elementu button
zamiast div
.
Stosowanie elementów natywnych ma też tę zaletę, że za nas odpowiadają za interakcje z klawiaturą. Pamiętaj, że to, że korzystasz z elementów natywnych, nie oznacza utraty efektownych efektów wizualnych. Możesz stylizować elementy natywne,
aby wyglądały tak, jak chcesz,
zachowując ich semantykę i działanie.
Wcześniej zauważyliśmy, że czytniki ekranu rozpoznają rolę, nazwę, stan i wartość elementu. Stosując odpowiedni element semantyczny, rolę, stan i wartość, musimy też zadbać o to, aby nazwa elementu była wykrywalna.
Ogólnie istnieją 2 rodzaje nazw:
- widoczne etykiety, które są używane przez wszystkich użytkowników do kojarzenia znaczenia z określonym elementem;
- Teksty alternatywne, które są używane tylko wtedy, gdy nie ma etykiety wizualnej.
W przypadku elementów na poziomie tekstu nie musimy nic robić, ponieważ z definicji zawierają tekst. Musimy jednak podać odpowiednią nazwę w przypadku elementów wejściowych i sterujących oraz treści wizualnych, np. obrazów. Udostępnianie tekstowych odpowiedników treści innych niż tekstowe to pierwsza pozycja na liście kontrolnej WebAIM.
Możesz to zrobić, stosując się do ich zaleceń, że „Dane wejściowe formularza mają powiązane etykiety tekstowe”. Są 2 sposoby powiązania etykiety z elementem formularza, np. z polem wyboru. Każda z tych metod powoduje, że tekst etykiety staje się też celem kliknięcia dla pola wyboru, co jest przydatne także w przypadku użytkowników myszy i ekranów dotykowych. Aby powiązać etykietę z elementem:
- Umieść element wprowadzania wewnątrz elementu etykiety
<label> <input type="checkbox">Receive promotional offers? </label>
lub
- Użyj atrybutu
for
etykiety i odwołaj się do atrybutuid
elementu
<input id="promo" type="checkbox">
<label for="promo">Receive promotional offers?</label>
Jeśli pole wyboru jest prawidłowo oznaczone, czytnik ekranu może zgłosić, że element ma przypisaną rolę pola wyboru, jest zaznaczony i ma nazwę „Otrzymuj oferty promocyjne?”.
![wyświetlane na ekranie komunikaty głosowe z VoiceOver, z wyświetloną etykietą pola wyboru](https://web.developers.google.cn/static/articles/the-accessibility-tree/image/on-screen-text-output-vo-2bf0c33d65f23.png?authuser=0000&hl=pl)