Ta strona używa cookies
sprawdź politykę prywatności

Rozumiem

Wszystko co FE Developer chce wiedzieć o Accessibility w 2020.

25/3/2020
Bartek Cis

Chcesz dobrze zrozumieć czym jest Accessibility i wiedzieć jak budować aplikacje które spełniają współczesne standardy w tej kwestii? 

Czego się dzisiaj dowiesz?

W tym artykule opiszę czym jest Accessibility, jakie to ma znaczenie zarówno dla Ciebie jako programisty i użytkownika końcowego. W końcu dobrze zrozumiesz jak to wszystko działa. Będzie trochę teorii i sporo praktycznej wiedzy.

Spis treści

  • Czym jest Accessibility
  • Screen Reader’y
  • Accessibility DOM
  • Semantyczny HTML – o co tak naprawdę chodzi?
  • Prawidłowe nawigowanie klawiaturą po aplikacji
  • ARIA
  • Testowanie Accessibility

Dlaczego piszę o Accessibility?

Uważam, że jest to jeden z najmniej rozumianych tematów we współczesnym Front-Endzie. Dość dużo się o tym mówi ale bardzo mało robi. Zwłaszcza w czasach gdy aplikacje pisze się głównie w React’cie czy Vue gdzie programiści bardzo lubią zapominać o dobrych praktykach dotyczących HTML i drzewa DOM (jakiejkolwiek byś nie nazwał jego wariacji).

Sam myśląc o aplikacjach w kontekście dostępności wizualizowałem sobie jakieś specjalne urządzenia/tablety które w jakiś niezbadany sposób wyświetlały zawartość osobom z różnym poziomem niepełnosprawności.

Nie znalazłem z polskim internecie (co nie znaczy, że ich nie ma) open-sourcowych materiałów które skutecznie wyszłyby temu problemowi naprzeciw. Dlatego powstał ten artykuł. 

Większość zawartej tu wiedzy jest oparta o serię od Roba Dodson’a. Wyselekcjonowałem to co uważam za najistotniejsze a jeśli zechcesz zagłębić konkretne zagadnienia to mam nadzieję, że ten artykuł będzie dobrym wstępem. No to ruszamy!

Accessibility – klasyczna definicja 

Po polsku Dostępność. Powszechnie używanym skrótem jest też – a11y.

Jest to zbiór praktyk których zastosowanie ma na celu dotarcie Twojej aplikacji (jej treścią, funkcjonalnościami) do jak największej grupy osób.

W klasycznym rozumieniu tego słowa myślimy o osobach z pewnym poziomem niepełnosprawności ale nie można zapomnieć też o tym, że Accessibility to też umożliwienie dostępu do treści użytkownikom urządzeń mobilnych. Po prostu wszystkich traktujemy tak samo.

Screen Reader’y

W tym artykule kładę największy nacisk na apki dostosowane do osób posiadających pewien stopień niepełnosprawności które aby przeglądać strony czy aplikacje mogą używać Screen Reader’ów. Zacznę więc od wyjaśnienia tego pojęcia.

Screen Reader to oprogramowanie!

Dokładnie 🙂 To software umożliwiający analizę konkretnej aplikacji, ułatwia nawigację za pomocą klawiatury i wydaje odpowiednie polecenia głosowe. Istnieje też opcja obsługi aplikacji pod kątem alfabetu Braille’a ale ten temat nie będzie tutaj opisany.

W kontekście aplikacji internetowych analizowana jest przeglądarka i poszczególne karty / taby które są w niej otwarte.

VoiceOver

To oprogramowanie wbudowane do systemów MacOS oraz iOS i w zasadzie na nim będę pokazywał wszystkie przykłady. Aby uruchomić ten program na Mac’u idź do Preferences a potem wybierz Accessibility.

Jeśli program jest aktywowany to w przeglądarce wystarczy wcisnąć Cmd + F5 aby odpalić VoiceOver’a.

Windows + Android

Analogicznie jeśli używasz Windowsa to zainstaluj sobie NVAccess. Androidy mają wbudowany TalkBack.

Użytkowanie Screen Reader’a

To w zasadzie umiejętność sama w sobie. Nawigacja po aplikacjach w tym programie to kombinacja skrótów klawiszowych i znajomości dostępnych opcji. Najlepiej po prostu się trochę tym pobawić – więcej o tym potem. Listę skrótów klawiszowych na Mac’a możesz znaleźć np. tutaj.

Switch device

Jeżeli użytkowanie standardowej klawiatury nie jest możliwe Screen Reader może współpracować ze specjalnym hardwaremSwitch Device’m. 

Najbardziej znanym użytkownikiem był pewnie Stephen Hawking. Switch Device posiada dwie akcje – nawigowanie (przypomina nieco używanie klawiatury) a drugim przyciskiem nawiązuje się interakcję. Chris Hills prowadzi cały kanał o tym gdzie testuje rozmaite rozwiązania na Switch’u.

Accessibility w praktyce

Przechodząc do bardziej technicznych zagadnień…

Przeglądarka renderując aplikację tworzy drzewa DOM i CSSOM. Nie jest to dla Ciebie pewnie żadną niespodzianką. Rzadko się jednak wspomina o tym, że tworzona jest jeszcze dodatkowa struktura… Accessibility Tree.

Credit – Rob Dodson

Accessibility Tree 

Opisuje ono budowę aplikacji pod kątem dostępności. Screen Reader na podstawie informacji na temat każdego elementu (elementy są analogiczne jak w drzewie DOM) jest w stanie przedstawić użytkownikowi dostępną treść.

Aby sprawdzić jak w praktyce wygląda Accessibility Tree najzwyczajniej sprawdź odpowiednią zakładkę w DevToolsach:

A więc jakie informacje mogą być użyteczne dla Screen Reader’a w kontekście poszczególnych elementów? Wygląda to mniej więcej tak:

Role

Czyli rola jaką dany element odgrywa np. button, textbox etc. Na podstawie tej informacji klasyfikowany jest typ interakcji i czy wogóle powinna ona nastąpić.

Title/ Name/ Placeholder/ Label/ Alt

Część opisująca dany element. Możesz tu napisać w zasadzie co chcesz i ta informacja może być odczytana użytkownikowi.

State

Wszystko opisujące aktualny stan danego elementu np. checked, expanded lub disabled.

Value

Jeśli element posiada jakąś wartość np. pole tekstowe, select itp. to będzie ona odczytana użytkownikowi.

Nie każdy element jest taki sam. To jakie informacje będą przypisane do konkretnego elementu zależy od tego czy np. mamy do czynienia z tagiem semantycznym. Te informacje są albo z góry zdefiniowane dla poszczególnych tagów lub podawane za pomocą atrybutów HTML.

Aplikacja w React

Artykuł nabiera rozpędu prawda? Od teraz będę wszystko opisywać na konkretnym przypadku. Napisałem prostą aplikację w React’cie gdzie użyłem semantyczne tagi HTML i inne elementy które poprawią Accessibility. Kod wygląda tak:

Jest to prosty ostylowany layout. Jeśli chcesz sam/a się z nim pobawić pobierz kod z mojego repo.

Semantyczny HTML

Mglista definicja mówi, że jest to taki HTML który może być interpretowany przez przeglądarkę a poszczególne tagi oddają przeznaczenie konkretnej treści w obrębie aplikacji.

No dobra, ale interpretowany pod jakim kątem? I po co to przeznaczenie jest w ogóle przeglądarce potrzebne?

Semantyczne Tagi

Pisząc ten artykuł zakładam, że rozumiesz już dość dobrze HTML. Jeśli jednak z jakiś powodów nie znasz terminu semantycznych tagów to możesz sprawdzić wpis Comandeer’a.

Dobrze jest też wiedzieć jakie tagi oferuje HTML5. Ja bardzo lubię tą tablicę:

Cała filozofia polega na tym, aby dobierać tagi HTML w sposób jak najbardziej odpowiadający treści dla potencjalnego odbiorcy. Jeśli nie wiesz czy Twój HTML jest napisany zgodnie ze sztuką możesz to sprawdzić m.in za pomocą tego walidatora.

Semantyka i SEO 

No właśnie… Sam nie wiem jak się do tego odnieść bo w wielu miejscach piszą, że semantyczny HTML pomaga pod kątem SEO.

Nie znalazłem żadnych oficjalnych informacji (co nie znaczy, że ich nie ma) mówiących o tym, że semantyka w znaczeniu tagów HTML pomaga. Nie mówię o oczywistych sprawach jak odpowiednie nagłówki, alty w obrazkach itp. Bardziej chodzi mi te wszystkie niuanse w które się dzisiaj zagłębiamy mające duże znaczenie dla Accessibility…

Znalazłem natomiast wątek z 2012 mówiący o tym, że jakość HTML5 nie wpływa specjalnie na SEO jednak zawsze lepiej używać najlepszych praktyk. Takie stwierdzenie w 2020 pomogłoby mi się ustosunkować…

Co jednak ma wpływ na SEO (wg. Neila Patel’a) to Schema Markup.

Przeznaczenie semantycznych tagów

Każdy semantyczny element ma swoje odpowiednie właściwości o których wspomniałem wcześniej np. role, name, state, value. O ile złożona semantyka w kontekście SEO nie jest dla mnie do końca jasna to jeśli chodzi o Accessibility wszystko nabiera sensu. Ja bym podzielił to na cztery podstawowe kategorie:

Tagi globalne

Nie wiem czy ta nazwa jest fortunna ale chodzi mi o takie tagi które posiadają informacje na temat samego projektu i w ogóle pozwalają na jego prawidłowe działanie: html, metadata, link, script body itp.

Tagi porządkujące

Segregują całą zawartość aplikacji i dzielą na bloki zwane landmarks. Screen reader może po prostu przejść do odpowiedniego bloku bez konieczności sprawdzania wszystkich aktywnych elementów po drodze (zaraz wszystko się rozjaśni).

Do podstawowych tagów porządkujących należą:

  1. nav – nawigacja po stronie
  2. aside – informacje pomocnicze, zazwyczaj sekcja po boku 
  3. main – główna zawartość strony
  4. footer – stopka czyli informacje dodatkowe

Nawigowanie po landmarkach może wyglądać tak:

Aby otworzyć tą opcję w VoiceOver’ze wciśnij ctrl+alt+U a potem nawiguj strzałkami na boki aż znajdziesz to menu.

Tagi informacyjne

Porządkują Accessibility DOM, dzielą na sekcje czy opisują treść jednak użytkownik nie może dokonywać z nimi bezpośredniej interakcji. Będą do nich należały listy – ol, ul, li czy tagi tekstowe h1p.

Nagłówki są o tyle ciekawe, że podobnie do landmarków mogą służyć do nawigacji:

Ciekawym tagiem jest tag section który przez Accessibility DOM jest interpretowany jako region ale nie należy do landmarków:

Tagi interaktywne

Czyli wszystkie te dzięki którym można wykonać jakąś akcję czyli np. a i większość elementów formularzy.

Link

<a href={url} title={`${desc}. Read more`}>{title}</a>

Zauważ, że możesz dodać atrybut title. Wtedy Screen Reader głośno przeczyta podaną wartość.

Linki najczęściej prowadzą do innych stron więc można po prostu nawigować tylko po nich (podobnie jak nagłówki czy landmarki):

Label

Wszystkie nietekstowe elementy które mogą wchodzić w interakcję powinny mieć label. Najłatwiej po prostu użyć go jako wrapper’a wokół jakiegoś elementu:

<label>
       Please provide your name:
       <input type="text" name="name" placeholder="Your name" /></label>

Buttony 

Natywne buttony domyślnie obsługują zdarzenia klawiatury jak spacja czy enter. Do tego można je łatwo kontrolować za pomocą właściwości disabled.

<button type="submit" aria-label="Submit contact form">
       Contact Us
</button>

Zauważ, że dodałem opis za pomocą właściwości aria-label. W Screen Reader’ze wygląda to tak:

Semantyka

Nie będę tutaj tłumaczył jak działają wszystkie semantyczne tagi bo patrząc na to co do tej pory opisałem można łatwo sprawdzić do czego mamy dostęp i domyślić się do czego one służą.

Ważne jest natomiast to, żeby z nich korzystać bo mają odpowiednio zdefiniowane Accessibility. Do tego część kodu w JS’ie w Twoim projekcie może być niepotrzebna jeśli wykorzystasz ich moc 🙂

Istnieje też koncepcja Affordances czyli próba przekazania znaczenia semantycznego wyglądem np. button się wyróżnia się shadow’em / kształtem, dropdown ma swoje menu, radio buttony są okrągłe a checkbox’y kwadratowe etc.

Niesemantyczne elementy

No ale nie mógłbym przejść do kolejnego tematu bez nawiązania do legendarnego div 🙂 Jest to prosty niesemantyczny element blokowy. Ludzie używają go często i gęsto. Nie ma w tym nic złego ale miej na uwadze, że w Screen Reader’ze wygląda tak:

A więc jest on widziany jako generic. Nie niesie ze sobą żadnych informacji. Czasem jest to w 100% ok. Ale czasem nie 🙂

Nawigowanie po stronie

Większość osób używa myszki czy touchpada. Są też tacy to używają klawiatury (pewnie nie raz się poddali kiedy strona była kiepska pod względem Accessibility 🙂 ). Na klawiaturze chcę się tu skupić.

Teoretycznie jest to bardzo proste bo do przejścia do kolejnego interaktywnego elementu na stronie trzeba nacisnąć TAB. Aby cofnąć się o element do tyłu używasz SHIFT+TAB.

Focus

Jest to właściwość po której można poznać, że dany element jest aktualnie aktywny i można nawiązać interakcję poprzez naciśnięcie np. ENTER.

Bardzo często się zdarza, że developer usuwa domyślny styl focus za pomocą CSS: outline: none np. przy stylowaniu buttonów.

Jest to duży błąd w kwestii Accessibility bo bez tego użytkownik nie widzi czy element jest aktualnie aktywny. To co powinieneś zrobić to usunąć ten styl dla eventów myszki ale zostawić go dla klawiatury.

Tabindex

Istnieje atrybut który kontroluje kolejność w jakiej interaktywne elementy przyjmują focustabindex (brawo dla tłumacza 😛 – fokusyjny).

<a href="https://bedekodzic.pl/" tabindex="1">Bedekodzic.pl</a>

Jeżeli go nie modyfikujesz to wszystkie elementy mają domyślną wartość 0. Wtedy kolejność otrzymywania focus’a jest skorelowana z tym kiedy ten element został zdefiniowany w drzewie DOM. Im wyżej, tym element otrzyma focus wcześniej.

Możesz mu nadać wartość negatywną – focus dla elementu nie będzie aktywny lub pozytywną wtedy będzie wcześniej niż elementy z niższą wartością tabindex.

Zmiana kolejności focus

Tabindex należy zmieniać umiejętnie bo szybko może się okazać, że powstał nawigacyjny chaos jak masz skomplikowaną aplikację. Ja wolę tego nie ruszać jeśli naprawdę nie muszę.

Jeżeli chcesz zmodyfikować kolejność to zaplanuj swoje drzewo DOM tak aby istniała pewna logiczna sekwencja w nawigacji. Jeśli trzeba to przesuń pewien element wyżej lub niżej.

Wszelkie modyfikacje stylów w CSS które sprawią, że element będzie na samym dole ekranu a nie na samej górze nie wpływają na kolejność focus’a. Jeśli umieścisz na górze drzewa DOM komunikat o cookies i w CSS umieścisz go na samym dole ekranu, to cookies będą ciągle pierwszym elementem który przyjmie focus.

Inert

Ale często może dojść do sytuacji gdzie część aktywnych elementów jest ukryta np. w mobilnym menu albo sidebar’ze który jest aktualnie niewidoczny. Użytkownik ciągle musi nacisnąć tab kilka razy aby znowu zobaczyć focus.

Istnieje specjalna biblioteka która dynamicznie sprawdza które elementy są aktualnie widoczne i odpowiednio dostosowuje focus. Rob to dość klarownie wytłumaczył tutaj.

Nawigowanie w Screen Reader’ze

Generalnie zasady są te same. Dodatkowo ma się dostęp do opcji które ułatwiają sprecyzować które elementy mają otrzymywać focus jak np. menu landmarków, headerów czy linków. Wspomniałem już o tym wcześniej.

Ciekawą opcją jest skip link. Czyli szybka nawigacja która pozwala uniknąć masę niepotrzebnych elementów i po prostu przejść do najbardziej interesującej sekcji na stronie np. główna treść.

ARIA

Już podkreśliłem jak ważne jest używanie natywnych semantycznych elementów jeśli zależy Ci na Accessibility jednak jeśli z jakiegokolwiek powodu nie możesz tego zrobić (bo np. tworzysz swoje własne web komponenty lub używasz zewnętrznej biblioteki) jest inne rozwiązanie. 

Aby stworzyć własne atrybuty do a11y możesz użyć standardu ARIA. W praktyce każdy (?) niesemantyczny element może stać się semantyczny i być odpowiednio interpretowany przez Screen Reader. Znowu, Rob poświęcił temu oddzielny odcinek więc po prostu możesz go sprawdzić 🙂

Kontrast

Kolejnym punktem który należy mieć na uwadze przy tworzeniu aplikacji to kontrast na stronie. W zasadzie to jest bardziej domena designer’a lub kogokolwiek innego tworzącego projekt graficzny.

Chodzi po prostu o to, aby jeden element był widoczny na tle drugiego. W praktyce oznacza to, aby był po przeciwnej stronie na kole kolorów:

Współczynnik kontrastu

Porównując dwa kolory pod kątem kontrastu obliczany jest współczynnik. Możesz sprawdzić ile on wynosi w Twojej aplikacji korzystając np. z tej porównywarki.

Aby apka spełniała kryteria Accessibility współczynniki generalni nie mogą spadać poniżej 4.5 : 1. Szczegółowe wartości mogą się zmieniać w zależności od kontekstu i aktualnej wersji specyfikacji.

Jak testować accessibility?

Ja bym powiedział, że są trzy główne etapy gdzie możesz testować Accessibility.

Development

Czyli na bieżąco podczas pisania kodu. Masz do tego dwa główne narzędzia o których już tutaj wspomniałem – Accessibility Tree w Chrome Dev Tools i Screen Reader jak np. VoiceOver.

Działa to dokładnie tak samo wszystkie inne testy które robisz podczas developmentu. Piszesz kod i sprawdzasz czy działa 🙂 No chyba, że robisz TDD 🙂

Audyt

Apka jest gotowa i po prostu chcesz sprawdzić czy standardy są zachowane – przeprowadzasz audyt. Jeśli jakimś cudem nie znasz Lighthouse w Chrome Dev Tools to poznaj. Pisałem o tym przy okazji serii o Progressive Web Apps. Generalnie wydaje mi się, że wyniki z Lighthouse co do Accessibility są trochę zbyt optymistyczne.

Kolejną metodą jest wtyczka do Chrome jak np. AXE.

Te narzędzia powinny dać Ci listę rzeczy które są do poprawki. Jeśli taki jest plan to po prostu poprawiasz punkt po punkcie 🙂

Testy Automatyczne

Osobiście tego jeszcze nie robiłem ale wiele wskazuje na to, że możesz zintegrować AXE-CLI ze swoim projektem który będzie uruchamiał testy accessibility tak samo jak to może się dziać z testami jednostkowymi lub e2e. Ten artykuł też może posłużyć jako przykład.

Po prostu integrujesz to ze swoim pipeline’m i za każdym razem kiedy jest nowy deploy to masz pewność, że wszystko jest ok.

Podsumowanie

To w zasadzie wszystko co dla Ciebie dzisiaj przygotowałam 🙂

Już powinieneś wiedzieć czym jest Accessibility w aplikacjach internetowych, jak napisać odpowiedni kod a potem go przetestować.

Najważniejsze punkty to:

  1. Orientacja na stronie przy użyciu landmark‚ów i skip linków
  2. Logiczna nawigacja za pomocą TAB – tabindex, inert
  3. Opisy przy interaktywnych elementach aby użytkownik wiedział co aktualnie robi. Opisy są głośno czytane przez screen reader.
  4. Możesz tworzyć custom’owe accessibility za pomocą standardu ARIA
  5. Zachowanie kontrastu.

Accessibility to cały nowy świat który czeka na eksploracje

Cześć jestem Bartek.

Na tym blogu wprowadzę Cię w tajniki Front-Endu i programowania webowego.

Warto
Social media & sharing icons powered by UltimatelySocial