Technologia asystująca

Czym jest technologia asystująca? Pozwolę sobie zacytować słowa Jacka Zadrożnego:

Technologie asystujące (ang. assistive technologies) są technologiami pomagającymi w codziennym funkcjonowaniu. Pomagają zobaczyć, usłyszeć, zrozumieć lub przemieścić się. Takimi technologiami są zatem alfabet Braille’a, aparat słuchowy, ETR czy wózek inwalidzki. Są nimi także biała laska, piktogramy, winda, podjazd, pętla indukcyjna i setki innych rozwiązań.

Jeśli jakiś przedmiot, urządzenie lub oprogramowanie pomaga danej osobie użytkowniczej korzystać z naszej strony WWW, to można tę rzecz nazwać właśnie technologią asystującą.

Drzewko dostępności

Zanim jednak przejdziemy bezpośrednio do technologii asystującej, warto chwilę pochylić się nad innym problemem: w jaki sposób przeglądarka komunikuje się z większością tej technologii? Odpowiedź brzmi: przy pomocy drzewka dostępności!

Okazuje się, że przeglądarka w momencie wyświetlania strony osobie użytkowniczej konstruuje kilka różnych drzewek. Pierwszym z nich jest drzewko DOM – powstałe w czasie parsowania HTML-a do obiektowej formy, którą można modyfikować następnie przy pomocy JS-a. Obok powstaje z kolei CSSOM, czyli drzewko powstałe w czasie parsowania kodu CSS. Niejako z połączenia tych dwóch drzewek powstaje drzewko renderowania – dzięki któremu przeglądarka wie dokładnie, jak wygląda strona, i może wyświetlić ją w formie zbioru pikseli na ekranie osoby użytkowniczej. A na podstawie drzewka renderowania powstaje też drzewko dostępności. Przechowuje ono informacje m.in. o rolach dla każdego elementu DOM na stronie. Dzięki temu technologia asystująca wie, że nagłówek jest nagłówkiem, a tabelka – tabelką. Z kolei informacje zaczerpnięte z CSS-a służą choćby do wyrzucania z drzewka dostępności tych elementów, które nie są renderowane (np. tych z display: none).

Technologia asystująca nie ma bezpośredniego dostępu do strony, “rozmawia” z nią wyłącznie za pośrednictwem drzewka dostępności. Na całe szczęście nie jest to wielkie misterium skryte za zasłoną cienia. Drzewko dostępności można podejrzeć w narzędziach developerskich przeglądarki. Dzięki temu szybko sprawdzimy, czy nasz kod jest interpretowany w taki sposób, w jaki byśmy sobie tego życzyli. Co jest szczególnie istotne w przypadku bardziej skomplikowanych przypadków, czyli – wtedy, kiedy używamy dużej liczby atrybutów ARIA.

Szybki przykład. Wyobraźmy sobie, że mamy nagłówek drugiego poziomu:

<h2>Tworzymy czytnik ekranowy</h2>

Jeśli klikniemy taki nagłówek prawym przyciskiem myszy i wybierzemy “Zbadaj element”, otworzy nam się inspektor DOM. Niemniej gdzieś w pobliżu powinna być opcja, aby podejrzeć ten element także w drzewku dostępności. W przypadku Chrome’a można to zrobić przy pomocy panelu po prawej stronie i zakładce “Dostępność”:

Otwarte narzędzia developerskie Chrome, w których podglądany w zakładce Dostępność jest element h2: ma on przypisaną rolę "heading" i poziom 2.

Jak widać, nagłówek działa i w drzewku dostępności jest przedstawiany jako nagłówek (rola heading) drugiego poziomu. Oczywiście dostęp do drzewka dostępności pozwala robić wiele niecnych rzeczy, jak np. zrobienie z nagłówka przycisku przy pomocy ARIA:

<h2 role="button">Tworzymy czytnik ekranowy</h2>

Tylko… po co? Należy zawsze pamiętać, że wielka moc to też wielka odpowiedzialność!

Czytniki ekranu

Jeśli mówi się o technologii asystującej, to czytniki ekranu bez wątpienia są pierwszą rzeczą, która przychodzi do głowy. Stworzone przez niewidome osoby programujące, czytniki ekranu stały się podstawowym narzędziem nawigacji po stronach WWW dla sporej rzeczy osób niewidomych, mających poważne wady wzroku czy po prostu korzystających z ficzerów czytnika ekranowego. Dzisiaj stały się też synonimem technologii asystującej.

Czym jednak jest czytnik ekranu? To technologia asystująca, która transformuje tekstową treść strony na język mówiony. Innymi słowy: pozwala osobie użytkowniczej usłyszeć stronę WWW. To również oznacza, że z dużym prawdopodobieństwem można założyć, że osoba korzystająca z takiego czytnika nie zobaczy naszego wymuskanego designu, który zdobył pięć nagród branżowych. Zamiast tego czytnik przedstawi takiej osobie jedynie to, co znajduje się w drzewku dostępności.

Na szczęście jest dość prosty sposób na to, aby w tym drzewku znalazło się wszystko to, co chcemy: pisanie semantycznego HTML-a. A przy okazji: niepróbowanie być sprytnym. Często można spotkać się z sytuacją, w której osoby niekorzystające z czytników ekranowych, ale testujące stronę przy ich użyciu, odnoszą wrażenie, że czytnik czyta coś niepoprawnie. Najczęściej zdarza się to przy skrótowcach czy liczbach. Dlatego często próbuje się nadpisywać to, jak coś czytnik czyta. To nie ma zbytnio sensu i może jedynie wprowadzać chaos i frustrację, bo np. wymusimy czytanie informacji, których czytanie osoba użytkownicza specjalnie wyłączyła w ustawieniach swojego czytnika. Osoby użytkownicze czytników ekranowych są najczęściej przyzwyczajone do ich “dziwactw” i najlepiej pozwolić czytnikom robić ich robotę. Innymi słowy: dobrze napisana pod względem interpunkcyjnym i gramatycznym treść będzie również treścią dobrze dostosowaną pod działanie czytnika ekranu.

Warto też zwrócić uwagę na sposób nawigacji przez osoby używające czytników ekranu. Nie jest to w rzeczywistości tradycyjne nawigowanie przy pomocy klawiatury. Czytniki ekranowe udostępniają wiele dodatkowych ficzerów nawigacyjnych. Jednym z nich jest ich własny wskaźnik focusu, który pozwala przeskakiwać pomiędzy wszystkimi elementami strony, nie tylko tymi dostępnymi z poziomu klawisza Tab. Innym ficzerem jest możliwość przeskakiwania między różnymi regionami strony, nagłówkami, linkami, itd. Najczęściej przyjmuje to postać listy elementów danego typu, z których możemy wybrać ten nas interesujący. Warto przy tym zwrócić uwagę, że badania wskazują na to, że osoby używające czytników ekranowych najchętniej nawigują przy pomocy przeskakiwania między nagłówkami.

Lista wszystkich nagłówków na stronie; pierwszy nagłówek jest zaznaczony; dla każdego nagłówka jest podany jego poziom oraz treść.
Funkcja rotora w VoiceOver: lista wszystkich nagłówków na stronie, pozwalająca przeskakiwać między nimi

Na urządzeniach mobilnych z kolei focus czytnika ekranowego przesuwać można odpowiednimi gestami dłoni.

Czytniki ekranu można znaleźć na praktycznie wszystkie systemy operacyjne, w tym też i te mobilne:

Warto testować stronę przy pomocy czytników ekranowych (najlepiej więcej niż jednego). Choćby po to, żeby oswoić się z tym, jak inne może być doświadczanie naszej strony przez osobę użytkowniczą od tego, jak my sami jej doświadczamy. A przy okazji można wykryć jakieś dość oczywiste błędy, typu przyciski bez etykiety.

Sterowanie głosem

Drugą sporą grupę technologii asystującej stanowią programy do sterowania głosem. Pozwalają one osobom użytkowniczym na nawigowanie po stronach WWW wyłącznie przy pomocy komend głosowych – bez używania myszki czy klawiatury. Tego typu doświadczanie strony – zwłaszcza przez osobę, która widzi treść na ekranie – jest zupełnie odmienne od korzystania z niej przy pomocy czytnika ekranu. Stawia więc też inne wyzwania przed osobą webdeveloperską.

Największym wyzwaniem są wszystkie te miejsca, w których widoczna treść rozjeżdża się z tym, co znajduje się w drzewku dostępności. Prosty przykład:

<button aria-label="Zamknij">OK</button>

Ten przycisk na stronie będzie miał tekst “OK”:

Ale dla technologii asystującej w drzewku dostępności będzie reprezentowany jako przycisk “Zamknij”. W momencie, gdy osoba korzystająca z programu do sterowania głosem, powie “Kliknij przycisk OK”, nic się nie wydarzy. A stąd już prosta droga do frustracji, bo przecież wyraźnie widać, że jest taki przycisk, a niby go jednak nie ma! Warto też sprawdzić, czy na stronie nie ma dziwnych wygibasów językowych oraz elementów, które nie są tym, na co wyglądają. Nic tak nie wkurza, jak powiedzenie “Kliknij przycisk OK”, który w rzeczywistości jest linkiem i program do sterowania głosem nie wie, o co nam chodzi. Albo link z napisem “Kontakt z PPSZOoI”. Powodzenia z wymową!

Obecnie nisza oprogramowania sterowania głosem jest na tyle rozwinięta, że istnieją nawet zaawansowane rozwiązania dla osób webdeveloperskich, które nie są w stanie używać klawiatury. Dzięki nim mogą dyktować kod, a nawet tworzyć makra głosowe, które wykonują określone czynności, np. wklejają zawartość schowka w wybrane miejsce.

Pozostałe

Czytniki ekranu i oprogramowanie do sterowania głosem to jednak nie wszystkie istniejące formy technologii asystującej. W końcu tak naprawdę spełniają potrzeby jedynie części osób z niepełnosprawnościami. Inne osoby mogą mieć inne potrzeby, a tym samym – korzystać z innej technologii asystującej. A tej może być zaskakująco dużo rodzajów. Można wymienić m.in. stylusy przystosowane do trzymania w ustach (dla osób z niepełnosprawnościami ruchowymi), monitor brajlowski (dla osób niewidomych), pojedyncze przyciski sterujące (dla osób z niepełnosprawnościami ruchowymi) czy nawet tak zaawansowane rozwiązania, jak implant pozwalający komunikować się z komputerem przy pomocy fal mózgowych. Co więcej, część osób z niepełnosprawnościami może korzystać z wielu technologii asystujących naraz. Choćby dlatego, że każda z technologii odpowiada na inną potrzebę tych osób. I nigdy nie wiadomo, kto i przy pomocy czego będzie korzystał z naszej strony WWW.

Monitor brajlowski: ma trzy przycisku po lewej stronie, które służą do pisania alfabetem Braille'a, oraz kilka rzędów pośrodku wysuwających się i chowających pręcików służących do wyświetlania tekstu.
Monitor brajlowski.
Źródło: CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=654118
Duży pojedynczy przycisk sterujący, umocowany z boku wózka inwalidzkiego.
Pojedynczy przycisk sterujący.
Źródło: Debbie L OU - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=6424109

Ale wróćmy na chwilę do bardziej software’owej gałęzi technologii asystującej. Systemy operacyjne (a zwłaszcza Windows) oferują też szereg przydatnych funkcji dla osób, które mają poważne wady wzroku. Jedną z nich jest tryb wysokiego kontrastu. Nadpisuje on wszystkie kolory zdefiniowane przez osobę autorską strony zdefiniowanymi z góry kolorami – takimi, które zapewniają odpowiednio wysoki współczynnik kontrastu. Dzięki temu osoby z wadami wzroku mogą zdecydowanie łatwiej zauważyć poszczególne elementy strony internetowej. To oczywiście stanowi pewne wyzwanie dla osoby webdeveloperskiej, ale przystosowanie strony do tego trybu nie jest jakoś przesadnie trudne, a warto to zrobić. Drugą funkcją jest z kolei możliwość powiększania fragmentu ekranu. Można o niej pomyśleć jak o lupie wbudowanej bezpośrednio w system operacyjny.

Jest w końcu i ostatnia kategoria technologii asystującej, o której się często zapomina. Same przeglądarki mają bowiem wbudowanych nieco ułatwień dostępu, np. możliwość powiększenia strony czy zmiany rozmiaru tekstu. Nie jest tych ułatwień zatrważająco dużo, ale są – i to zawsze pod ręką. Od lat też toczą się dyskusje nad tym, jak można jeszcze usprawnić przeglądarki. Jednym z przykładowym pomysłów jest dodanie tzw. skip linków, czyli linków pozwalających przeskoczyć bezpośrednio do najważniejszych fragmentów strony.

AI – przyszłość?

Nie da się ukryć, że najmodniejszym obecnie tematem branżowym jest sztuczna inteligencja – a dokładniej: wielkie modele językowe. Pozwalają one generować teksty, obrazki, ostatnio nawet filmiki. Są też dość dobre w rozpoznawaniu przedmiotów na zdjęciach. Nasuwa się więc dość oczywiste pytanie: czy da się wykorzystać AI do polepszenia dostępności stron internetowych?

Ten problem można ugryźć od kilku różnych stron. Pierwszą z nich jest pytanie, czy AI potrafi pomóc w pisaniu kodu, który jest bardziej dostępny i spełnia ogólnie uznane standardy dostępności. Na tak postawione pytanie odpowiedź brzmi: nie bardzo. Modele często się mylą albo – jeśli już podadzą poprawną odpowiedź – argumentują w błędny sposób. Pozwoliłem sobie wziąć przykład zaprezentowany przez Léonie Watson w jej artykule i zapytać ChatGPT 3.5, czy spełnia on wymogi WCAG 2.2 na poziomie AA.

Treść mojego pytania:

Czy poniższy kod HTML spełnia wymogi WCAG 2.2 na poziomie AA?

<p>It was reported today that a dog ate my homework.
    <a href="news.html" aria-label="Dog ate my homework">Read more...</a>
</p>

Jak wskazała Watson, ten kod nie spełnia wymogu 2.5.3 Etykieta w nazwie. Nazwa elementu (wartość atrybutu aria-label) jest niespójna z etykietą elementu (“Read more…”). Tym samym kod oblewa test i nie jest zgodny ze standardem WCAG.

ChatGPT stwierdził natomiast, że nie widzi większych problemów w pokazanym mu fragmencie kodu:

Zgodnie z Wytycznymi dostępności treści internetowych (WCAG) 2.2 na poziomie AA, istnieją różne kryteria, które muszą być spełnione, aby treść była uznana za dostępną. Poniżej analizuję kod HTML pod kątem kilku istotnych punktów:

  1. Tekst alternatywny dla obrazów:
    1. W tym przypadku nie ma obrazów, więc nie jest konieczne dostarczanie tekstu alternatywnego dla obrazów.
  2. Prawidłowa struktura dokumentu:
    1. Kod zawiera jedynie prosty paragraf z odnośnikiem, co ogólnie jest odpowiednie.
  3. Tekst łącza (linku):
    1. Link zawiera tekst “Read more…”, co jest stosunkowo krótkim i zwięzłym opisem celu linku.
  4. Atrybut **aria-label**:
    1. Dodano atrybut aria-label, co jest pozytywne, ponieważ zapewnia dodatkową dostępność dla osób korzystających z czytników ekranu.
  5. Wizualna prezentacja:
    1. Jednak, jeśli istnieje potrzeba dodatkowej informacji wizualnej, warto sprawdzić, czy nie trzeba dostarczyć dodatkowego stylu lub klasy CSS w celu poprawy prezentacji dla osób z niepełnosprawnościami.

Podstawowy kod wydaje się spełniać kilka wymagań WCAG, ale ocena dostępności powinna uwzględniać także inne aspekty stron internetowych, takie jak kontrast kolorów, użyteczność czy obsługa klawiatury. Warto również sprawdzić dostępność na różnych urządzeniach i przeglądarkach.

Dlatego też ostateczną ocenę dostępności można przeprowadzić tylko po dokładniejszej analizie treści, stylów i dodatkowych interakcji na stronie.

Innymi słowy: po raz kolejny oblał test wykrycia błędu w konkretnym kryterium standardu WCAG. Jego odpowiedź zawiera także kilka innych informacji, które są wątpliwej jakości, np. stwierdzenie, że atrybut aria-label zapewnia dodatkową dostępność dla osób używających czytników ekranu. To nie jest do końca prawda. W wielu przypadkach ten atrybut może wręcz pogarszać dostępność dla użytkowników czytników ekranowych:

<a href="#" aria-label="Zapisz i wyjdź">Wyjdź bez zapisywania</a>

Podczas gdy osoba używająca czytnika ekranu usłyszy “Zapisz i wyjdź”, osoba widząca tekst zauważy, że ten link robi coś zupełnie odwrotnego. Dlatego to, czy atrybut aria-label podnosi dostępność, zależy od konkretnego przypadku jego zastosowania. Zatem podpowiedzi AI przy pisaniu kodu, który ma być dostępny, lepiej dokładnie sprawdzić. Chociaż to w dużej mierze przeczy sensowności pytania AI o pomoc w tym zakresie…

Więc spróbujmy z innej strony: czy AI może być dobrą technologią asystującą? Prawdopodobnie tak. Owszem, AI wciąz nie jest doskonałe i zdarza mu się halucynować, ale jest kilka nisz, w których już teraz może z powodzeniem działać jako technologia asystująca. Chyba sztandarowym przykładem jest rozpoznawanie przedmiotów na zdjęciach i opisywanie ich. Nie są to, co prawda, opisy na poziomie tych robionych przez profesjonalne osoby redaktorskie, ale średni opis wciąż jest lepszy niż brak opisu. AI jest też dobre w rozpoznawaniu mowy – a więc jest w stanie zapewnić transkrypcję dla filmów czy nawet streamów na żywo. Może też działać w drugą stronę: generować mowę. No i nie zapomnijmy o jednej z podstawowych funkcji ChatuGPT: redagowaniu tekstów. To dobry sposób na przerobienie trudnego, nafaszerowanego technicznym żargonem tekstu na taki, który jest napisany o wiele prostszym językiem i jest zrozumiały dla zdecydowanie szerszej grupy odbiorców.

Innymi słowy: AI może pomóc osobom użytkowniczym tam, gdzie osoby autorskie stron często zawodzą. A więc doda opisy do zdjęć, które ich nie mają, zapewni transkrypcję dla filmów, w których takowej nie ma, czy pozwolą zrozumieć tekst, który w innym wypadku wymagałby doktoratu z kilku dziedzin nauki. Natomiast AI niekoniecznie pomoże osobom webdeveloperskim w tworzeniu dostępnych rozwiązań.

Źródła

Dodatkowe materiały