Czytniki ekranu to programy umożliwiające osobom niewidomym korzystanie z takich urządzeń, jak komputery, tablety czy smartfony. Wbrew dość szeroko rozpowszechnionemu przekonaniu, nie trzeba tworzyć specjalnych wersji stron internetowych, aby mogły mieć do nich dostęp osoby niewidome. Wystarczy, że strony te będą poprawnie zbudowane, ze zwróceniem szczególnej uwagi na pewne określone kwestie.
Semantyka
Najważniejszym aspektem budowania stron dostępnych dla osób korzystających z czytników ekranu jest stosowanie semantycznego HTML. Każdy element strony, taki jak przycisk, link, nagłówek czy tabela, musi zostać oznaczony przy pomocy prawidłowego elementu HTML. Dlaczego jest to takie ważne?
Czytniki ekranu interpretują informacje przekazane w kodzie strony za pośrednictwem tzw. Accessibility API, czyli dostępnościowego interfejsu programistycznego aplikacji, który zawiera drzewo obiektów (kontrolek i tekstu) i informacji na temat każdego z nich. Do informacji tych należą:
- właściwości opisowe (rola, nazwa, wartość, itd)
- przejściowe stany (wciśnięty, wybrany, otrzymujący fokus klawiatury, itd.)
- zdarzenia (zmiana tekstu, uruchomienie przycisku, zaznaczenie pola wyboru)
- czynności, które użytkownik może wykonać (kliknięcie, zaznaczenie, przeciągnięcie, itd.)
- związki (rodzic / dziecko, kontroluje, itd.)
- zawartość tekstowa
Każdy standardowy element interfejsu użytkownika czy też element HTML ma przypisany mu szereg wymienionych wyżej właściwości, do których czytnik ekranu ma dostęp poprzez AAPI. Spójrzmy na przykład na poniższy fragment kodu formularza:
<fieldset>
<legend>Płeć:</legend>
<label for="kobieta">
<input type="radio" name="plec" id="kobieta" value="kobieta" checked="checked" />
Kobieta
</label>
<label for="mezczyzna">
<input type="radio" name="plec" id="mezczyzna" value="mezczyzna" />
Mężczyzna
</label>
</fieldset>
Jeśli osoba niewidoma przeniesie kursor do pierwszego pola opcji, czytnik ekranu automatycznie przekaże użytkownikowi informację o roli tego elementu (pole opcji), nazwie (zawartość etykiety powiązanej z tym elementem) i stanie (zaznaczony / niezaznaczony). Co więcej, czytnik przekaże też, że pole to należy do grupy przycisków “Płeć”, w skład której wchodzą 2 elementy. Skąd czerpie tę wiedzę? Nie z faktu, że na ekranie wyświetlone są elementy, które wyglądają jak radio buttons (kółeczka z wyświetlonym obok tekstem). Każdy standardowy przycisk opcji udostępnia technologiom asystującym wszystkie te informacje za pomocą swojego AAPI.
Wyobraźmy sobie teraz, że ktoś postanowił zamieścić na stronie przyciski opcji zbudowane przy pomocy niesemantycznych elementów, obrazków tła, oraz JavaScript:
<div class="fieldset">
<span>Płeć:</span>
<div class="przycisk-opcji przycisk-opcji--zaznaczony">
Kobieta
</div>
<div class="przycisk-opcji">
Mężczyzna
</div>
</div>
Choć przy zastosowaniu odpowiedniego stylu oraz JavaScript przyciski te mogą wyglądać i działać identycznie co prawdziwe pola opcji z punktu widzenia osób widzących, z perspektywy osoby niewidomej elementy te będą przedstawiać się zupełnie inaczej. Czytniki ekranu odczytają elementy “płeć”, “kobieta”, “mężczyzna” jako statyczny tekst, bez jakiejkolwiek informacji o tym, że elementy te de facto pełnią rolę przycisków opcji, jeden z nich można wybrać, i który z nich jest aktualnie wybrany. I chociaż można by przekazać wszystkie te brakujące informacje za pomocą atrybutów ARIA, zawsze najlepiej jest po prostu korzystać ze standardowych elementów HTML. Zapewnia to najlepszą kompatybilność z przeglądarkami i technologiami asystującymi i zaoszczędza nam mnóstwa zupełnie niepotrzebnej pracy.
Logiczna kolejność treści w kodzie
Elementy strony internetowej muszą być zamieszczone w kodzie HTML w kolejności, która ma sens, gdy treść odczytywana jest od początku do końca strony, linearnie.
Alternatywne opisy treści nietekstowych
Każdy element nietekstowy (obrazek, zdjęcie, wykres, infografika, wideo), który przekazuje jakąś informację bądź użyty jest jako element interaktywny (np. link), musi posiadać tekstową alternatywę.
Obrazki czysto dekoracyjne nie powinny posiadać alternatywnego opisu.
Opisowe etykiety pól i przycisków
Wszystkie pola formularza i przyciski muszą posiadać zrozumiałe i opisowe etykiety, oznaczone przy pomocy odpowiednich elementów i atrybutów HTML. Komunikaty o błędach muszą zostać prawidłowo zaimplementowane, aby osoby niewidome miały do nich łatwy dostęp.
Opisowe linki
Cel każdego linku powinien być zrozumiały na podstawie samego tekstu linku, bez konieczności odwoływania się do kontekstu, w jakim link ten został użyty.
Czyli np.:
“Zapraszamy do zapoznania się z naszą zimową wyprzedażą.”,
a nie:
“Aby zapoznać się z naszą zimową wyprzedażą, kliknij tutaj.”
Dostępność z klawiatury
Znakomita większość osób korzystających z czytnika ekranu posługuje się klawiaturą. Dlatego tak ważne jest, by każdy element interaktywny otrzymywał fokus klawiatury oraz mógł być aktywowany za pomocą klawiatury.
Określenie języka strony
Aby czytniki ekranu były w stanie prawidłowo przekształcić treść strony na mowę i zaprezentować ją użytkownikom, język, w jakim dana strona została stworzona, musi zostać poprawnie zadeklarowany w kodzie strony.
Brak automatycznie odtwarzanych nagrań audio
Należy unikać zamieszczania na stronie automatycznie odtwarzanych dźwięków, które trwają dłużej niż 3 sekundy, bądź ewentualnie zapewnić przycisk, za pomocą którego użytkownik może ten dźwięk wyłączyć. Ścieżka dźwiękowa może zagłuszyć głos czytnika ekranu i przez to znacznie utrudnić osobie niewidomej korzystanie ze strony.
ARIA
W przypadku, gdy HTML nie wystarczy, by przekazać czytnikom ekranu wszystkie potrzebne informacje na temat elementów strony, należy zastosować odpowiednie role i atrybuty ARIA. Tak jest na przykład w przypadku, gdy strona zawiera dynamiczne treści (takie, które zmieniają się bez odświeżenia strony), bądź interaktywne komponenty, które nie mają swojego odpowiednika w HTML.