11 rozwiązań i technologii mordujących dostępność

Na wstępie

Tak na początek nie uważam, aby opisywane rozwiązania były całkowicie złe. Jako technologie odegrały swoją mniejszą lub większą rolę w tworzeniu cyberprzestrzeni jaką znamy dzisiaj i zapisały się na kartach historii Internetu. Niektóre umarły śmiercią naturalną, a niektóre są z powodzeniem używane do dziś. Jednak tematem przewodnim jest tu dostępność i pod tym kątem były oceniane.

Zacznijmy od małej retrospektywny, na początek…

Animowane Banery Gif

Kto pamięta pierwsze animowane reklamy zrobione w gifach?

Gif jako format graficzny umożliwiał animacje na stronach www. Jednak w naszym przypadku ważniejsze jest to, że gif jako jeden z pierwszych wspierał przezroczystość, co pozwalało w stosunkowo małym rozmiarze pliku dodać animację np. na tle strony.

Tu pojawia się także ogromna wada gifa, a właściwie nadużycia twórców stron, którzy mając przezroczystego gifa, wypychali stronę pustymi gifami, aby wypełnić braki w treści. Nie było to ani dostępne, ani responsywne.

Jego drugą wadą jest fakt, że pozwala on jedynie na użycie do 256 kolorów, co na wyświetlaczach o dużej rozdzielczości wygląda po prostu fatalnie.

Jednak nie przeszkadzało to reklamodawcom i twórcom stron na umieszczanie, mrugających niczym na choice animowanych banerów reklamowych, które na chwilę obecną łamałyby co najmniej kilka wytycznych WCAG.

Gif-a można zrobić trochę dostępnym, ale nadal będzie on łamać kilka wymagań WCAG choćby:

• 1.4.4 Resize text
• 2.2.1 Timing Adjustable
• 2.2.2 Pause, Stop, Hide

Dziś tego formatu praktycznie się już nie używa, a jeśli już to stosowany jest głównie do tworzenia demotywatorów i emotek. Odpowiedzą na małą responsywność i kiepskie odwzorowanie kolorów miała być nowa technologia, umożliwiająca przechowywanie nie tylko ruchomego obrazu, ale również dźwięku.

Macromedia Flash

Powstał w 1996 roku i miał zapewnić tworzenie, skalowalnych, interaktywnych grafik i animacji. Niektórzy wyjadacze używali action scriptu w połączeniu z fleszem do pisania aplikacji webowych.

Flash-a używał sam YouTube i aby odtworzyć film należało pobrać i zainstalować wtyczkę flash player z serwerów Adobe. (firma Adobe przejęła firmę Macromedia w 2005 r.)

Niestety ta technologia miała kilka poważnych wad.

• Pierwszą z nich było bardzo ubogie wsparcie dla dostępności i nawet gdy firma Adobe ulepszyła flasha by ten wspierał dostępność, nikt o tym już nie myślał, a napisane aplikacje, gry czy same animacje pozostały niedostępnymi, aż do ich naturalnej śmierci. Początek końca flasha nastąpił dość wcześnie, bo już w 2014 roku wraz z wprowadzeniem do języka HTML5 obsługi tagu video, natomiast już z początkiem 2015 roku you tube ogłosił, że porzuca wsparcie dla flasha, a filmy będzie można otworzyć w samej przeglądarce obsługującej HTML5 Viedo
• Drugą bolączką flasha była jego kompatybilność. Dla przykładu przeglądarka Firefox non stop zaliczała crashe na stronach gdzie wymagana była ta wtyczka, nawet jeśli był to tylko mały dodatek do strony.
• Trzecią wadą flasha, była spora podatność na ataki. Wtyczka była łatana praktycznie z miesiąca na miesiąc, co w efekcie musiało się skończyć podjęciem decyzji o uśmierceniu tej technologii.

Flash ostatecznie umarł 31 grudnia 2020 roku po 24 latach swojej obecności w sieci. Dziś już go niema, ale w czeluściach Internetu można jeszcze znaleźć strony oparte na tej technologii, która nie miała za wiele wspólnego z dostępną treścią.

SVG i Fontawesome

Miejsce flasza zajęły 2 inne technologie wykorzystujące potencjał skalowania na dużych ekranach.

Scalable Vector Graphics i Fontawesome są świetne, jeśli chodzi o skalowalne grafiki lub ikony, które mają dobrze wyglądać zarówno na małej jak i na dużej rozdzielczości. Jest jednak z nimi jeden dostępnościowy problem. O ile nie są przekazywane w stylach, a umieszczane bezpośrednio w kodzie html, nie są dostępnymi elementami. W obu przypadkach wymagane jest użycie atrybutów ARIA, aby przekazać dla nich treść alternatywną.

Programiści zazwyczaj o tym zapominają. Na szczęście z pomocą idą twórcy dokumentów: Font Awesome Accessibility oraz Accesible SVG.

Captcha

Wraz z rozwojem e-handlu, naturalnym krokiem do budowy relacji z klientem było budowanie szybkich i prostych w obsłudze kanałów kontaktu. Do dziś odbywa się to najczęściej poprzez media społecznościowe, różnego rodzaju web chaty czy formularze kontaktowe.

Tą ostatnią opcję sprytnie wykorzystali ludzie piszący boty internetowe wysyłające spam, który do dziś jest udręką, ale niezabezpieczony niczym formularz to jakby niejawne przyzwolenie, aby tę furtkę wykorzystać. Trzeba więc było wymyślić zabezpieczenie przez tego typu zjawiskiem.

Captcha jest najpopularniejszym i chyba jednym z najbardziej niedostępnych rozwiązań z jakim spotykają się osoby nie tylko niepełnosprawne. Bardzo prawdopodobne jest, że każdy z nas miał choć raz styczność z tegop typu zabezpieczeniem biorąc pod uwagę fakt, że na rynku tego typu rozwiązań co najmniej kilka.

Captcha powstała w 1997 jako mechanizm weryfikacji m.in. czy osoba wypełniająca formularz faktycznie jest człowiekiem – tak zwany test Turinga. Naturalnie obok korzyści przyniosło to również wiele problemów w szczególności dla osób niewidomych.

Wyłączenie obrazów w przeglądarce lub użycie przeglądarki tylko tekstowej jak np. Lynx powoduje, że takie zabezpieczenie jest nie do przejścia przez osoby niewidome lub niedowidzące. Screen readery też mają problem, gdyż nie są w stanie przeczytać tekstu umieszczonego na obrazku. Stworzono więc nową wersję zabezpieczenia tzw. captchę głosową, aby umożliwić odczyt treści przez czytniki ekranu. Niestety to też nie rozwiązało problemu do końca, gdyż wiadomość z mechanizmu zabezpieczającego jest wypowiadana w języku angielskim, więc jest to problemem dla osób które tego języka nie znają. Osoby ze ślepotą barw, dysleksją lub zaburzeniami poznawczymi, również mają ogromy problem z tego typu zabezpieczeniem. Udowodniono także, że przy użyciu sztucznych sieci neuronowych można złamać zabezpieczenia captcha, czego przykładem było zabezpieczenie o nazwie EZ-Gimpy wykorzystywane przez Yahoo! Briefcase. Dodatkowo istnienie takich serwisów jak Antigate.com czy Anti-captcha.com, na których rozwiązanie 1000 testów captcha można kupić w cenie nieprzekraczającej 1 USD, trochę podkopuje fundament tego zabezpieczenia.

Jak widać zastosowanie obrazków do weryfikacji autentyczności czy jest się człowiekiem, nie jest najlepszym rozwiązaniem pod kątem dostępności, a jeśli ktoś chce się dowiedzieć czegoś więcej o skuteczności zabezpieczeń tego typu, można odwiedzić stronę PWNtcha, natomiast o stopniu wsparcia dostępności przez tego typu rozwiązania doczytać na W3C Captcha alternative

Póki co nadzieja kładziona jest w reCAPTCHA wersji 3 od Google-a.

Programy pocztowe

Jeśli już trzymamy się e-handlu i komunikacji z klientem, to nie można nie wspomnieć o mailingu na przykład w postaci stron www lub elektronicznych formularzy. Możliwość tworzenia i wysyłania e-maili bogatych w grafikę i obrazy dostrzeżono wkrótce po tym jak programy pocztowe potrafiły interpretować umieszczone w mailach dokumenty html, a więc proceder wysyłania dokumentów html poprzez email jest już dobrze znany wszystkim użytkownikom internetu.

Obecnie się mówi o tym aby mailing do klienta był przejrzysty i dostępny. Wszystko fajnie tylko teoria ta trochę kłóci się z faktem, że programy pocztowe takie jak np. Microsoft Outlook niezbyt radzą sobie z tą dostępnością.

Próbowaliście kiedyś zbudować template maila dla Waszych klientów, który nie tylko będzie responsywny, ale tekże będzie spełniał wymogi WCAG? Jeśli nie, to życzę powodzenia. Nie dość, że będziecie zmuszeni do zbudowania waszego template-u używając starego HTML 4.01, to jeszcze będzie on musiał być zbudowany w oparciu o… tabelki. O kiepskim wsparciu CSS-a nie wspomnę.

Wymaganie ‘WCAG 1.3.1 Info and relationships’ mówi jasno, nie buduj stron www w oparciu o tabelki, a czym jest taki template maila jak nie stroną www lub jej częścią.

Problem istnieje od dawna i nawet w najnowszej wersji pakietu Office 365 lub 2021, program outlook nie radzi sobie z poprawnym wyświetleniem maila w oparciu o HTML5 - bez użycia tabelek. Oczywiście z pomocą przychodzą atrybuty ARIA, ale taki dokument nigdy nie będzie do końca dostępny i to już na pierwszym poziomie dostępności.

Placeholder

Przejdźmy jednak do tematu budowania stron www i jednego z moich niedostępnych faworytów. W składni języka html-u atrybut placeholder istniał prawie od zawsze, a prostota implementacji i projektowania sprawia, że jest nagminnie używany przez UX-ów i deweloperów. Co sprawia, że placeholder nie jest dostępny?

• Przede wszystkim. Placeholder nie jest alternatywą dla etykiety, przez czytniki ekranowe jest odczytywany jako wartość pomimo, że nie zostało jeszcze nic wprowadzone w pole formularza
• Znika zaraz po rozpoczęciu wprowadzania danych, użytkownik traci wtedy widoczną instrukcję co ma wprowadzić
• Domyślny styl/wygląd nie spełnia minimalnego poziomu kontrastu dla tekstów poniżej 18px
• Czcionka placeholdera jest mała, co sprawia że jest mało widoczna
• Placeholoder nie jest automatycznie tłumaczony, gdy stronę wrzucisz w automatycznego tłumacza, chociażby w google translate
• Topowe serwisy jak Smashing Magazine czy Nilsen Norman Group piszą - nie używaj placeholdera.

Mnie przekonało, a ty co zrobisz?

Parallax

Pierwszy efekt prallax powstał w 2007, ale upowszechnił się z tak naprawdę z wejściem w życie języka HTML5 i CSS3. Animowane tła podczas przewijana strony nadawały charakteru i świeżości w web design-ie.

Do dziś parallax pozostają efektowe i rozwinęły do tego stopnia, że doczekały się kilku różnych technik ich tworzenia. Jednak jaki ma to wpływ na dostępność?

Nie tyle na dostępność co na osoby z zaburzeniami np. z zapaleniem nerwu przedsionkowego. Efekt jaki może wywołać parallax u osób z takim schorzeniem, to ostre zaburzenia ruchu i równowagi, dlatego powinno się unikać stosowania efektu parallax na stronach internetowych. Mówi o tym nawet jedno z wymagań WCAG 2.3.3: Animation from Interactions.

Read more, Learn more, Continue reading etc.

Przycisk stworzony przez UX-ów na potrzeby SEO, mający wywołać u użytkownika odpowiednią reakcję tzw. call to action.

Odpowiednio napisany w kodzie może być dostępnym, jednak w większości przypadków nie jest, a w oderwaniu od treści/kontekstu nic nie znaczy, co jest problemem dla osób używających np. czytników ekranu.

Taki program czyta link „Read more” w oderwaniu od całości tekstu i już kilka takich linków na jednej stronie wprowadza chaos i brak zrozumienia treści na przykład przez osoby niewidome.

Na szczęście stosując odpowiednie atrybuty ARIA, umiemy poradzić sobie z takimi sytuacjami, ale patrząc na braki w zrozumieniu ARIA przez programistów i UX designerów stosowanie przycisków typu 'read more' nie jest dobre dla dostępności.

ARIA

Jak już jesteśmy przy temacie ARIA.

ARIA powstała w W3C jako odrębna specyfikacja atrybutów rozszerzających składnię języka html. W większości przypadków jej użycie jest potrzebne tylko tam, gdzie semantyka kodu nie jest zachowana, po to aby technologie asystujące mogły "zrozumieć" czym jest dany element na stronie.

ARIA sama w sobie nie jest problemem, dzięki niej możemy poprawić wiele błędów dostępności, albo zapewnić ją tam gdzie HTML nie daje sobie rady. Jednak ktoś, kiedyś powiedział, że wiele problemów z dostępnością by nie istniało gdyby nie ARIA. Niestety, tak się składa, że jej błędne użycie lub nadużywanie jest gorsze niż jej brak. Wiec jeśli nie umiesz lub nie rozumiesz atrybutów aria to ich po prostu nie stosuj. Jeśli jednak jesteś ambitnym programistą, to polecam tutorial WAI jak stosować ARIA.

CMS (content management system)

O zaletach cms-ów pisała już nie jedna osoba. Jednak mało kto podjął się opinii, że cms-y nie są dobrym przykładem wspierania dostępności, a na pewno nie w standardzie. Na co najczęściej się zwraca uwagę podczas wyboru cms-a:

• Ile to mnie będzie to kosztować?
• Na szybkość i prostotę postawienia serwisu na wybranej platformie.
• Jak szybko jestem w stanie umieścić na nim jakiś sklep lub artykuł?

CMS jest jednym z wielu przykładów gdzie najpierw wypuszcza się produkt, dopiero później myśli o "dodatkach", gdyż na starcie o dostępności nikt nie myśli. Oczywiście dostępność tą można później „włączyć” poprzez instalację specjalnych wtyczek, stosując odpowiednie szablony lub(i) konfigurację samego cms-a. Jednak to nie zagwarantuje 100% dostępności serwisu.

Jak już wcześniej pisałem w jednej z moich wypowiedzi na temat mitów dostępności, dostępność nie jest czymś extra, czymś co można sobie tak po prostu zagwarantować poprzez instalację wtyczki lub zmianę szablonu. To autor strony musi dbać o dostępność, a nie system zarządzania treścią. CMS może to w jakiś mniej lub bardziej pokrętny sposób to umożliwić, ale do nas należy zapewnienie dostępności.

Dodatkowo jak już wspomniałem o dostępności nikt nie myśli w pierwszej kolejności co sprawia, że CMS zabija dostępne myślenie.

Spójrzmy na to z następującej perspektywy: Jak już uporałem się z wszystkim, postawiłem sklep, wprowadziłem tam produkty, dodałem do nich zdjęcia i teraz nagle mam zmieniać mój szablon, instalować jakieś wtyczki, coś dodatkowo konfigurować i może jeszcze zmieniać treść lub dodawać teksty alternatywne… to ja to sobie odpuszczę, a biznes jakoś się będzie kręcił bez tej dostępności.

Dlatego uważam, że CMS-y choć są świetnymi narzędziami wspierającymi małe lub średnie firmy, startup-y czy blogi, to zabijają dostępne myślenie.

Specjalnie też nie wymieniłem tu żadnego ze znanych systemów zarządzania treścią, żeby nie robić krypto reklamy, ale mamy 2021 rok standard dostępności istnieje już od kilkunastu lat, a najpopularniejszy z cms-ów nadal ma kłopoty z zachowaniem dostępności.

Poza tym dobry CMS to taki, który spełnia zarówno wymagania ATAG 2.0, a strony w nim wygenerowane spełniają wymagania WCAG 2.1 (przypominam zgodność z WCAG 2.1 jest już wymagana przez prawo), tego ostatniego standardu nie spełnia póki co żaden z cms-ów.

Klikalne divy

W dobie framworków programistycznych, analizy statycznej kodu, masy różnego rodzaju komparerów, walidatorów itp. narzędzi, ten problem nie powinien istnieć. Niestety nadal można spotkać elementy języka html jak np. tag 'div' z obsługą onClick(), nie będący linkiem, a jedynie symulacją takiego linku lub przycisku.

W powyższym przykładzie przycisk zrobiony z elementu ‘div’ lub ‘span’ nie jest elementem fokusowalnym, więc nigdy nie będzie dostępny, a na pewno nie z klawiatury. Oczywiście mamy ARIA i inne atrybuty języka HTML5, można się uprzeć i zrobić to dostępnym, ale po co na siłę coś szminkować, zamiast to uprościć i zrobić zgodnie ze sztuką. W tym przypadku nie sam element div jest problemem, ale tak zwana droga na skróty którą obiera developer podczas tworzenia serwisu. Dość często dla zapewnienia dostępności jest to droga zbyt krótka.

Konkluzia

Wymienione przeze mnie technologie lub rozwiązania posiadają mniejsze lub większe problemy z dostępnością. Czy to oznacza że mamy ich nie używać? Absolutnie nie.

Co prawda niektóre z nich, nie są już wspierane przez producentów i te akurat odradzam stosować. Są również także te, które nadal sa rozwiajne, tyle że mają pewne problemy z dostępnością, których musimy być świadomi decydując się na nie.

Faktem jest, ze podczas wyboru rozwiązania lub technologii, którą chcielibyśmy zastosować na naszej witrynie, mailu lub aplikacji pamiętać musimy o nie tylko o tym, czy dana technologia jest jeszcze rozwijana lub wspierana, ale także o tym czy po wytworzeniu interfejsu w oparciu o nią będzie on dostępny.