Accessibility, czyli semantyczny i dostępny HTML

Dostępność to najczęściej niedoceniany i pomijany aspekt tworzenia stron internetowych. Czym jest i dlaczego accessibility jest w dzisiejszym świecie webdevelopmentu szalenie istotne?

Semantyka ≠ dostępność

Rzadko w ofertach pracy dla frontendowców można spotkać wymóg umiejętności pisania semantycznego HTML. Najczęściej będzie to wzmianka o tym, że kandydat powinien wprawnie posługiwać się HTML w wersji 5. To, co przyniosła ta wersja języka znaczników faktycznie wprowadziło dużo zmian i nowe standardy do sieci, których na ogół programiści starają się przestrzegać. Dostępność to jednak coś więcej niż znacznik main, footer, header, aside itp. Semantyka oznacza, że te znaczniki dają nam jakieś konkretne znaczenie, jakąś konkretną rolę samą w sobie. Tak, aby inne narzędzia mogły czytać te znaczniki i "domyślać się" co jest pięć i jak poprowadzić potencjalnego użytkownika przez stronę. Semantyczne znaczniki HTML mają swoją rolę by default. Nie trzeba do nich używać JSa, zewnętrznych bibliotek itd. Nie znaczy to jednak, że nasza strona będzie dostępna. Używanie semantycznego HTML nie daje gwarancji accessibility. Trzeba to robić z głową, co jednak dla wielu z nas jest niechętnym zajęciem. Oczywiście, można to osiągnąć samymi tagami. Jednak w wielu przypadkach będziemy musieli iść na jakiegoś rodzaju kompromis.

Czym więc jest dostępność? Jakbym miał to określić własnymi słowami to powiedziałbym tak: jak najmniejszym przeszkadzaniem użytkownikowi w odbiorze treści zamieszczonych na stronie internetowej. Dostępność to nie tylko tagi i sposób w jaki czytniki ekranowe czytają je na stronie i nawigują po nich (choć jest to bardzo ważne w kontekście dostępności). Są to również wszelkie mikro interakcje (np. focus na konkretne przyciski, poprawne zaprogramowanie alertów, poprawny collapsing, tabindexy). Ok, w porządku, jak screen reader przeczyta to, co znajduje się w znaczniku h6 jako "nagłówek poziomu szóstego", a nawigację wyczyta jako "nawigacja", ale co z tego, jeśli zaraz wyskoczy jakieś okienko z alertem, który zablokuje dalszą nawigację klawiaturą na stronie? Nie powinniśmy także blokować żadnych rzeczy związanych z natywnymi ustawieniami przeglądarki, np. wielkość czcionki. Każda z powyższych potencjalnych rzeczy może przeszkodzić na drodze do odbioru zainteresowanego użytkownika. Użytkownika, który może posiadać jakąś niepełnosprawność.

Dlaczego i dla kogo?

Często chęć posiadania accessibility na stronie argumentuje się czystym altruizmem i moralnością wobec drugiego człowieka. Więc i ja zacznę od tego tematu. Nie każdy człowiek na świecie jest w pełni zdrowy. Jest wiele osób z różnymi niepełnosprawnościami, które mogą potencjalnie (negatywnie) wpłynąć na użytkowanie strony internetowej. Aby dać tym osobom taką samą szansę na skorzystanie z dobrodziejstw internetu, co zdrowym użytkownikom, to my, jako twórcy stron, musimy sami o to zadbać. Nie mówię tutaj tylko o osobach niewidzących/niedowidzących (choć podejrzewam, że ta grupa osób z niepełnosprawnościami ma najbardziej utrudniony dostęp do treści w internecie). Są tutaj także inne grupy: osoby z zaburzeniami daltonistycznymi, osoby głuche/niedosłyszące, starsze, z ubytkami kończyn, z różnymi chorobami przewlekłymi i pewnie z tuzin więcej. Myślenie, że ta grupa jest nieznacząca, jest absolutnie błędne. W samym naszym kraju szacuje się, że liczba osób z niepełnosprawnościami wynosi ponad 6 mln. To prawie 20% ludności Polski, więc nawet co 5 człowiek, którego spotykasz na ulicy może posiadać jakąś niepełnosprawność. A niektórzy z nich być może odwiedzą twoją stronę. Chcieliby wtedy na pewno móc z jej zasobów swobodnie korzystać. Tym samym tworzymy sieć piękniejszą.

Innym argumentem idącym za tworzeniem dostępnych stron jest kwestia czysto materialna. Dzięki dostępności, ilość potencjalnych użytkowników, czy nawet klientów/chętnych na zakup twojego produktu w sieci wzrasta. Użytkownik z niepełnosprawnością, która to uniemożliwia lub utrudnia mu korzystanie ze strony, najprościej w świecie ją opuści i już raczej nigdy nie wróci.

Semantyczny HTML i dostępność sama w sobie zwiększa SEO strony i ranking jej indeksowania w Googlu. Sam Google nalega, by korzystać z dostępności na swoich stronach. Roboty indeksujące czytają kod HTML i na tej podstawie oceniają, jak bardzo strona jest dostępna. Przy tworzeniu projektu, warto ten czynnik wziąć pod uwagę i już od razu założyć, żeby trzymać się najlepszych konwencji dot. semantyki i dostępności.

Zasada Pareto

Powiedzieliśmy sobie o korzyściach płynących ze stosowania "dostępnego" kodu HTML. Należy sobie jednak zadać pytanie: czy warto? Jak to często bywa przy różnych technologiach i rozwiązaniach, nie ma korzyści bez tradeoffów. Tutaj jest dokładnie tak samo.

Tworzenie dostępnej strony z perspektywy frontendu jest trudne. Nie dlatego, że dostępność to jakaś zaawansowana logika, ale ogrom encyklopedycznej wiedzy do przyswojenia i wkucia. Standardami i ustalaniem zasad dot. accessibility zajmuje się W3C z inicjatywy WAI (Web Accessibility Initiative). A zbiór zasad do studiowania to WCAG (Web Content Accessibility Guidelines). Oficjalny guide można znaleźć tutaj. Jest to ogromna ilość wiedzy do przyswojenia. Moim zdaniem, ten guideline, czy też może handbook, wymaga o wiele więcej wiedzy niż CSS. Żeby to zobrazować przedstawię piramidę nauki HTML:

zdjęcie tematyczne
Nazwijmy ją piramidą Senior HTML Developera

Często skupiamy się na nauce frameworków i JSa, nie pamiętając, że nadal trzeba się rozwijać u podstaw. Ważne jest, żeby pamiętać o najprostszych mechanizmach działania sieci, jak HTML, czy CSS. HTML ciągle ewoluuje, nowe standardy nadchodzą, więc nie można tego lekceważyć. Według mnie accessibility jest na szycie nauki HTML jako języka lub technologii. Jest to rzecz, na którą potrzeba najwięcej encyklopedycznej wiedzy i czasu. Nie jest jednak tak źle, jak na to wygląda.

W kontekście dostępności panuje zasada Pareto (lub też Pareta). Oznacza to, że 20% wysiłku danego zwróci nam się pod postacią 80% efektów. Pozostałe 80% wysiłku to pozostałe 20% wysiłku. Brzmi lepiej? Na dobrą sprawę, w dostępności trzeba nauczyć się najważniejszych rzeczy i najbardziej oklepanych wzorców, aby zapewnić większości użytkownikom swobodny dostęp do strony. Przykładowo poprawne linkowanie i teksty w nim zawarte mają ogromny wpływ na klarowność strony. Raz nauczony poprawny sposób umieszczania linków w HTML sprawi, że już zawsze na naszych stronach będzie zapewniona dostępność przynajmniej pod tym względem. Podobnie będzie tak z nauczeniem się podstaw dot. kontrastu na stronach i jak go czytać. Dzięki temu użytkownicy z różnymi zaburzeniami wzroku lub daltonizmem, nie będą mieć problemu w czytaniu strony (aczkolwiek dobrym pomysłem jest też wprowadzenie wersji wysoko kontrastowej na stronie). Zastosowaniami trywialnymi i podstawowymi (często nie wykorzystujących nawet atrybutów aria, o których powiem za chwilę) możemy osiągnąć naprawdę dostępną stronę. Czy to wystarczy? To bardzo często będzie zależało od wymagań, np. klienta.

zdjęcie tematyczne
Zasada Pareto mówi, że 20% włożonego wysiłku daje 80% rezultatów

ARIA i a11y

To, co odróżnia accessibility od semantyki, to w głównej mierze standaryzacja ARIA (Accessible Rich Internet Applications). Jest to zbiór atrybutów HTML, które zapewnią wszystko to, czego nie osiągnęliśmy zwykłym HTMLem (np. nowymi znacznikami HTML5). Jest to pozostałe 80% wysiłku i 20% efektów. To tutaj nasza wiedza musi wznieść się na wyżyny. To tutaj zdałem sobie sprawę, jak mało wiem o HTMLu i jak dużo brakuje mi, żeby zostać Senior HTML Developerem. Atrybuty te można przypisać do każdego znacznika HTML. Sprawiają one na przykład, że zwykłe, z założenia nie posiadające semantycznego przeznaczenia tagi (div, span), otrzymują je. Istnieje na przykład atrybut aria-role, który możemy użyć tak:

<div aria-role="list">
    <span aria-role="listitem">1</span>
</div>

Dzięki temu div dostaje rolę znacznika ul lub ol, więc czytnik ekranowy rozpozna to właśnie jako listę (do listy używaj zawsze dedykowanych, semantycznych znaczników! - powyższe zastosowanie to tylko przykład przedstawiający mechanizmy aria). Mamy też na przykład znacznik aria-expanded, który mówi czytnikowi, że dany kontener jest rozwinięty lub nie. Tych przykładów jest masa, dlatego najlepiej będzie jak odeślę to oficjalnej dokumentacji aria. Często atrybuty te muszą być zintegrowane z JSem, czy nawet CSSem, tak by zapewnić w pełni poprawne i profesjonalne działanie dostępności. Ten mechanizm powinien być stosowany raczej jako rozszerzenie do semantyki HTML. Przykład z życia: trzeba zrobić customowy element select do formularza. Mamy taki natywny element w HTML (select), aczkolwiek użycie go sprawi, że nie będzie można go ostylować CSSem. Taki znacznik select posiada swoje sterowanie (np. nawigacja za pomocą klawiszy strzałkowych). Aby stworzyć generyczny komponent imitujący zachowanie natywnego selecta, musimy się trochę namęczyć, pisząc do nieg javascript, ostylować wg uznania w CSSie i poprawnie połączyć to wszystko z atrybutami i rozwiązaniami aria. I w większości przypadków tak to właśnie wygląda: możemy skorzystać z rozwiązania istniejącego, najczęściej w postaci semantycznego tagu w HTML, ale w zamian nie mamy tego, co chcemy (np. stylowania). Wtedy napiszemy własne rozwiązanie, ale ceną tego będzie konieczność zapewnienia poprawnej dostępności (np. nawigacja klawiaturą lub czytanie ekranowe poszczególnych opcji). 

Dopiero standaryzacja aria jest w stanie uzupełnić to, czego sam semantyczny HTML nam nie zapewni. Dodajmy do tego wiedzę o właściwych i dobrych praktykach o dostępności (jest to temat rzeka) i zaawansowane właściwości HTML, a każda nasza strona będzie dostępna dla wszystkich.

Czy zawsze powinno dbać się o dostępność?

Chciałbym powiedzieć, że tak, jednak jak to zazwyczaj w życiu bywa, nic nie jest takie proste. Mając na celowniku dostępność, należy zastanowić się, czy aby na pewno jest ona potrzebna w projekcie. Może się okazać, że grupa docelowa użytkowników to społeczność, w której nie ma osób z niepełnosprawnościami. Wtedy jest to nieco bez sensu.

Dużą rolę na pewno odgrywa też sam klient, który nie będzie sobie życzył, żeby programiści spędzali czas na czymś takim, jak dostępność (a klient płaci za czas). Podczas prac koncepcyjnych ważne jest ustalenie także, czy klientowi zależy na pozycjonowaniu i SEO. Stosując semantykę, zwiększymy indeksowanie w Googlu, co może być dla niego istotne.

Kiedy projekt jest wewnętrzny i prywatny, wymaganie o dostępności także można sobie odpuścić. Tworząc projekt dla siebie (własnej nauki) stanowczo nalegam na pisanie dostępnej strony (chociażby używając semantycznych tagów i najprostszych atrybutów aria), a zwłaszcza kiedy będzie ona publiczna. Na początku będzie trudno. Kiedy jednak złapie się już bakcyla, pisanie dostępnych stron internetowych staje się naturalne, a ty stajesz się Senior HTML Developerem :)

Za rozwój accessibility w sieci odpowiada również projekt społeczności a11y, do którego każdy może kontrybuować. Społeczność ta propaguje wszelkie dobre praktyki związane z dostępnością w sieci i zapewniają źródła, które mają pomóc programistom w pisaniu dostępnych stron, np. książki, ale też pluginy. Jednym z takich pluginów jest dodatek do eslinta stworzony właśnie przez a11y. Podpowiada on podczas pisania HTML lub JSX (React), co robimy źle i co powiniśmy zastosować w pisaniu. Jest to spore ułatwienie w pracy nad dostępnością. Plugin jest dostępny tutaj, a link do strony projektu a11y to a11yproject.com.

Podsumowanie

Dostępność to temat bardzo często zlewany przez początkujących programistów. Chyba nigdy nie widziałem semantycznie napisanego kodu w portfolio developerów Wannabe. Jest to ogromny błąd. HTML może być niepozorny i jest obiektem wielu memów i żartów, ale jest to chyba najdobitniejszy reprezentant powiedzenia easy to learn - hard to master.

Tworzenie dostępnych stron w sieci nie jest łatwe. Sieć internetowa to jednak miejsce, o które trzeba dbać. Tak, aby każdy człowiek, nieważne kim jest i skąd jest, mógł z niego spokojnie korzystać. Codziennie mamy styczność z wieloma ludźmi. Nawet co 5. z nich może mieć utrudniony dostęp do sieci z jakiegoś powodu. Nie dotyczy więc to tylko niszy, a często dużej grupy potencjalnych klientów. Należy pamiętać, że semantyka to nie to samo, co dostępność, chociaż dostępność oznacza raczej, że z semantyki będziemy musieli skorzystać. Dostępność to rozbudowane mechanizmy HTML wraz z ARIA i nierzadko javascriptem. Stanowi ostatni, najwyższy szczebel nauki w piramidzie HTML, wymagający ogromu encyklopedycznej wiedzy. Dlatego zachęcam do nauki dostępnych technik już teraz.

© Damian Kalka 2021
Wszelkie prawa zastrzeżone