Ostatnio podczas słuchania podcastu w drodze do pracy trafiłem na odcinek na temat dostępności. Temat ten zaciekawił mnie, ponieważ w podcascie była zwrócona uwaga na dostępność od strony programisty. Potem w ciągu trzech dni temat ten powrócił do mnie dwukrotnie i to z różnych stron. Postanowiłem zatem ten temat zgłębić.

Przyznam szczerze, że kiedy tworzyłem strony, layouty lub aplikacje, nie szczególnie zwracałem uwagę na to aby kod, który pisałem, spełniał kryteria dostępności. Nie wynikało to ze złej woli, raczej z niedostatecznej znajomości tego zagadnienia.

Czym jest dostępność

Dobrym pytaniem na początek jest “Czym jest dostępność?”. Odpowiedź jest w sumie nawet prosta. Wspomagając się Wikipedią można powiedzieć że jest to dziedzina zajmująca się interakcją człowieka z komputerem, mająca na celu dotarcie treściami do jak największej grupy odbiorców, zwłaszcza do osób “wykluczonych cyfrowo” np, osób słabowidzących, niedowidzących, głuchych.

A tak po ludzku, czym jest dostępność? Warto zastanowić się jak osoby z różnymi niepełnosprawnościami korzystają z komputerów, smartfonów ogólnie z internetu. Ludzie znani są z przełamywania barier i wymyślania technologii która pozwala przezwyciężać różne przeciwności losu. Tak więc osoba która jest całkowicie niewidoma może korzystać z komputera za pomocą czytników ekranu. Osoby które nie mogą korzystać z myszki, mogą nawigować po stronie za pomocą Mouse Grida. Tak więc, czy sam kod strony, użyty framework lub jezyk programowanie ma defacto wpływ na to czy strona jest dostępna? Ja bym powiedział że, raczej nie. Ponieważ po pierwsze, duże znaczenie ma tutaj design serwisu (rola projektantów i grafików) a po drugie taki czytnik ekranu można potraktować jako “inną przeglądarkę”. Tak jak kiedyś robiło się haki na IE5, to tak teraz trzeba po prostu dodać trochę dodatkowego kodu, aby obsłużyć takie czytniki.  

Co ciekawe (i w sumie słuszne) wszelkie instytucje rządowe w Polsce są zobowiązane do utrzymywania w pełni dostępnych swoich serwisów na mocy przepisów Unii Europejskiej oraz Rozporządzeniu Rady Ministrów. 19 grudnia 2018 roku rząd Polski przyjął projekt ustawy o dostępności cyfrowej, gdzie podjęto szereg założeń które mają doprowadzić do tego aby wszystkie serwisy organów publicznych były w pełni dostępne. Przewidziano nawet kar dla instytucji, które nie będą się wywiązywali z w/w ustawy, np 10 tyś PLN “na organ, który uporczywie unika zapewnienia dostępności”

WCAG

To jak już wiem czym jest ta dostępność to teraz rodzi się kolejne pytanie, gdzie znaleźć informacje co zrobić aby strona była dostępna. Organizacja W3C utworzyła dokument nazwany Web Content Accessibility Guidelines czyli WCAG, obecnie w wersji 2.1, jest to zbiór zasad jakich powinni przestrzegać programiści aby przygotować stronę maksymalnie dostępną.

Po lekturze tej specyfikacji muszę zweryfikować swoje zdanie na temat tego czy sam kod strony sprawia że strona jest dostępna. Otóż tak! Rzekłbym nawet że, znaczenie ma sposób pisania kodu. Na przykład: Tworzę nagłówek sekcji tekstu. W html mam dostępne znaczniki h1 do h7, które odpowiadają różnym stylom i ważnością nagłówków. Mogę również użyć elementu div lub span, oczywiście odpowiednio ostylowanego. Od strony wizualnej nie ma to najmniejszego znaczenia, oba elementy będą wyglądać tak samo. Poprawności kodu także jest zachowana, div jest bardzo uniwersalnym elementem. Natomiast od strony dostępności jest to kolosalna różnica. Otóż czytniki ekranów skanują stronę. Szukają znaczników typu h1 itp i indeksują je dla użytkownika jako swoisty spis treści. Jeżeli użyliśmy elementu div jako nagłówka, nie zostanie on potraktowany jako nagłówek i czytnik ekranu go pominie i dany nagłówek nie zostanie zaprezentowany użytkownikowi jako element spisu treści. Myślę że, ten przykład bardzo dobrze obrazuje problem.

Jedną z ważniejszych wytycznych WCAG jest to aby stosować semantyczny html i elementy zgodnie z ich przeznaczeniem elementy <h1> jako nagłówki, <button> jako przyciski itd.  

Drugim istotnym aspektem są znaczniki “aria”. Jednym zdaniem można powiedzieć że ‘aria’ dla elementu jest tym czym alt dla obrazka. Czyli dodatkowym opisem danego elementu. Specyfikacja jest żywa, ciągle rozwijana więc zapewne niedługo pojawią się jej nowe wersje, warto tą dokumentację śledzić. więcej na tej stronie (https://www.w3.org/TR/WCAG21/)

Moje obserwacje

Miałem okazję obserwować dwa przypadki użycia internetu przez osoby niepełnosprawne. Pierwszą osobą jest Jenny, która na co dzień pracuje jako native speaker prowadząca kursy online. Zdzwania się na skype, swoim kursantom podsyła artykuły o których potem dysktuje. Czyli typowy online native speaker, z tym że Jenny jest całkowicie niewidoma. W pracy pomaga jej sprzęt z nadgryzionym jabłkiem. Po pierwsze iOS posiada VoiceOver, czyli bardzo dobry wbudowany czytnik ekranu, a w połączeniu z Siri pozwala użytkować iPhona całkowicie za pomocą interfejsu głosowego. Po wczytaniu się w temat odkryłem, że istnieją także linijki brajlowskie, które pozwalają za pomocą języka braille’a wpisywać treści do urządzenia. Takie urządzenia także lepiej działają na iOS, ponieważ iOS posiada jeden swój standard i każde urządzenia Appla w ten sam sposób to wszystko interpretuje. Android natomiast przegrywa na tym polu swoim zróżnicowaniem. Mam na myśli to, że istnieje bardzo dużo wersji i dystrybucji Androida, gdzie czasami sterowniki do tego typu urządzeń są zaniedbane, więc nie ma pewności, że taka linijka zadziała poprawnie.

Drugą osobą którą obserwowałem był Adam, chłopak z porażeniem mózgowym, który bardzo lubił oglądać filmy na YouTubie. Adam wcześniej oglądał na laptopie, nawigacja myszką była dla niego trudną sztuką, ale chęć oglądnięcia swoich filmów sprawiła, że opanował tą czynność w stopniu umożliwiającym korzystanie z serwisu. Któregoś dnia ktoś podał Adamowi tablet 8-calowy z odpaloną aplikacją YouTube, okazało się, że nawigacja gestami na ekranie dotykowym była o wiele łatwiejsza i intuicyjna, a sam interfejs aplikacji jest o wiele bardziej dostępny niż serwis www. I teraz Adam korzysta tylko z tabletu z natywną aplikacją YT, porzucając całkowicie serwis dostępny z poziomu laptopa. Ciekawe prawda …

Przemyślenia

Mam także mały dysonans, ponieważ WCAG zaleca stosowanie <button> jako przycisków oraz <a > jako linków. No ok, ale w swoje pracy, w pracy z javascriptem bardzo często te elementy nie występują w takiej formie. Ponieważ na clicku przychwytuje zdarzenia i odpalam inne funkcje, stosowanie elementu <a> jest czasami wręcz niepożądane.

Podobnie jest z designem i kolorem. Zaleca się silne kontrasty dla osób słabo widzących. Chrom nawet w swoim inspektorze pomaga teraz pokazać jaki jest kontrast pomiędzy emitentem i jego tłem. I to wszystko jest naprawdę super, ale jak w takim razie wpisuje się w to obecnie popularny flat design ze swoimi pastelowymi kolorami, delikatnymi przejściami?

W kwestii linków jeszcze. Za jak najbardziej dostępne należałoby chyba uznać domyślnie ostylowane linki w przeglądarce. Mam na myśli te niebieskie linki z podkreśleniem po najechaniu. Ale czy w jakimkolwiek projekcie one zostały takie domyślne? Chyba nie. Zawsze się je zmienia ponieważ są one po prostu brzydkie (ok, to moja subiektywna ocena, ale nawet W3C je przestylowali u siebie na stronie ). Może było by lepiej gdyby we wszystkich przeglądarkch zmieniono domyślne style dla np linków, aby było one bardziej używalne bez konieczności ich redesignu i bez zmian ich stylu (jakie by to było fajne dla frontend developerów). Tematyka dostępności pojawia się w coraz szerszym aspekcie. Mam wrażenie, że dostępność stanie się buzz wordem. A rok 2019 będzie rokiem dostępności(sic!) ale żeby nie było. Jak dla mnie idea sama w sobie jest jak najbardziej słuszna. Kropka.