HTML, CSS, JS — wciąż niezbędne na froncie? Słowo o accessibility

Zaprojektowanie produktu cyfrowego (strony, aplikacji, oprogramowania biznesowego) zgodnie z wytycznymi WCAG sprawia, że osoby z różnymi ograniczeniami są w stanie wygodnie z niego korzystać. W accessibility chodzi o niewykluczanie użytkowników. Zgodnie z Europejskim Aktem o Dostępności instytucje publiczne są zobowiązane do zapewnienia dostępności swoich stron i aplikacji mobilnych… Obowiązek ten nie dotyczy wciąż jednak zwykłych, komercyjnych stron i aplikacji, a ich twórcy zwykle zapominają o zapewnieniu dostępności.

Aplikacja dostępna dla każdego

Kiedy mowa o dostępności, często najpierw pojawiają się skojarzenia z osobami z ograniczoną sprawnością, jednak accessibility ma więcej wymiarów i jest bardzo mocno powiązane z użytecznością i doświadczeniami użytkowników. Chodzi o to, aby dane oprogramowanie było przydatne niezależnie od tego, kto i w jakich warunkach go używa. Cel specjalistów zajmujących się tym zagadnieniem to stworzenie aplikacji niewykluczającej nikogo — ani osób niepełnosprawnych, ani tych, które np. pracują w głośnym otoczeniu i mogą nie usłyszeć nagrania w aplikacji. Powinny być wygodne w użyciu dla użytkowników, którzy mają złamaną rękę i mogą używać tylko jednej i dla takich, które odbierają świat nieco inaczej niż większość ludzi (np. daltonistów).

Do mniej więcej połowy 2025 roku także komercyjne strony i aplikacje będą musiały wdrożyć accessibility, więc to dobry moment, żeby dowiedzieć się więcej na ten temat. Dlaczego frontendowcy pomijają accessibility?

Poznaj najważniejsze trendy UX z 2023 roku!

Accessibility jest często traktowane po macoszemu — pomijane, robione na szybko.

Dlaczego? W końcu twórcom stron i aplikacji powinno zależeć, żeby ich produkty mogły być wykorzystywane przez jak największe grono odbiorców. Odpowiedź jest prosta, chociaż może nieco rozbawić…

Niewielu programistów zna dobrze HTML-a. Nie zaskakuje to, gdyż już od jakiegoś czasu wśród juniorów pożądaną umiejętnością jest biegłe tworzenie aplikacji za pomocą popularnych frameworków. Szkoły programistyczne prowadzą intensywne szkolenia z np. Reacta, a na inne tematy zostaje bardzo mało czasu. Znajomość HTML-a, CSS-a czy nawet czystego JavaScriptu nie jest więc wcale taka oczywista, jak mogłoby się wydawać.

O tym, gdzie i dlaczego frontendowcy popełniają błędy, opowiedział nam Michał Michalczuk, Senior Software Engineer i konsultant w Tektit Consulting:

„Dbanie o accesibility (a11y), czyli dostępność jest szalenie trudne. Angażuje nas na każdym etapie projektowania i tworzenia aplikacji. Temat należy zacząć od wyjaśnienia czterech głównych założeń Web Content Accessibility Guidelines (WCAG) 2, dodając do każdego przykład jej złamania.

Aby aplikacja była dostępna powinna być POUR:

1. Perceivable (dostrzegalna): użytkownicy muszą być w stanie doszukać się i być świadomi zawartości oraz informacji, która jest im prezentowana.
   
   Przykład złamania: formularze, w których nie ma labeli, property opisujących nazwę pola ani atrybutów ARIA. Jeszcze gorzej, jak są reprezentowane wyłącznie przez ikonę, które też nie posiada żadnych semantycznych znaczników. W tak skrajnym wypadku wiele odwiedzających nie będzie wiedziało, o co wam chodzi. Dlaczego? Bo znaki graficzne często są kontekstowe i użytkownik z innego kręgu kulturowego (lub  nieznający jakiegoś kontekstu, odczyta znaczenie ikony inaczej lub wcale). Jest zresztą wiele sposobów na złamanie tego standardu, np. dodawanie nagłówków artykułów w formie obrazów, bez atrybutów alt czy ARIA, albo najzwyklejsze ustawienie zbyt małego kontrastu np. poprzez umieszczenie białego tekstu na jasnokremowym tle.
2. Operable (wykonywalna): każdy element strony może być użyty, niezależnie od sposobu, w jakim ją obsługujesz. Chodzi o poruszanie się po nawigacji, klikanie przycisków, kontrolek playerów audio-video etc.
   
   Przykład złamania: klasyczny błąd - div który obsługuje kliknięcie, ale nie posiada żadnych ARIA attributes ani przycisku button. To powszechny grzech większości stron. Na dodatek może jeszcze być wykluczony z tzw. “tab order”, czyli nie można do niego przenawigować za pomocą klawiatury. To gwarantuje, że część użytkowników strony nie będzie w stanie wykonać tej akcji. Pozwolę sobie jeszcze wspomnieć o modalach. Jeśli wyświetlimy na stronie modal lub pop-up i nie przenawigujemy tam użytkownika, który porusza się za pomocą klawiatury lub czytnika ekranowego, nie będzie miał możliwości interakcji z tą treścią.
3. Understandable (zrozumiała): treść w aplikacji musi być zrozumiała a zachowania przewidywalne, zarówno zawartość pisana, jak i graficzna.
   
   Przykład złamania: brak labeli lub wskazań jak wysłać formularz, który właśnie uzupełniamy. To, co twórcy określają jako przewidywalność (predictability) też można kreatywnie złamać — np. odpalając modal przechwytujący focus, gdy jakiś element dostanie focus. Dla osób operujących myszką — po najechaniu na element otwiera się popup. Dla osób operujących klawiaturą — przewija się tab-index, aby sprawdzić, jakie operacje można wykonać na stronie i nagle niespodzianka — użytkownik znajduje się w innym miejscu.
4. Robust: zawartość strony może być interpretowana przez urządzenia takie jak czytniki ekranowe (screen readers) i inne technologie.
   
   Przykłady złamania: tutaj możemy wrzucić wszystkie grzechy opisane powyżej i polać je sosem generowania niesemantycznego HTML-a, który utrudni czytnikowi ułożenie sobie mapy treści czy mapy strony (po co komu znacznik nav, skoro można użyć div na wszystko itd.)

Jak widzicie, część tych elementów jest istotna już na etapie projektowania graficznego czy układania layoutu strony — jak kolory, nawigacja czy znaki graficzne. Inne problemy mogą wynikać wprost z wymagań biznesowych. Część błędów może wynikać z niewiedzy developerów lub być wynikiem przeoczenia — brak properties czy atrybutów, używanie nieodpowiednich znaczników HTML, interaktywne elementy, które są nieosiągalne dla czytników.

Niepoświęcanie uwagi kwestii dostępności strony może być też całkiem świadomą decyzją. Praca nad a11y przekłada się bezpośrednio na czas poświęcony pracy nad projektem, który zwłaszcza w early-stage czy podczas tworzenia MVP jest kluczowym i limitowanym zasobem. W tym — oraz w opisanej złożoności — upatrywałbym brak dostępności naszych aplikacji" - stwierdził Michał. 

Wsparcie dla developerów

Część rozbudowanych frameworków cieszących się dużym zaufaniem programistów ma już komponenty, które umożliwiają wdrożenie accessibility w pewnym stopniu. Dostosowując różne gotowe elementy pochodzące z frameworka do stylu swojej marki trzeba pamiętać jednak o tym, aby przypadkowo nie zmienić tych spełniających założenia użyteczności na takie, które nie będą ich spełniać.

Warto zagłębić się w dokumentację, bo to właśnie w niej możesz znaleźć informacje na temat tego, co da się zrealizować w ramach frameworku, a co trzeba zrobić, kodując od podstaw. Można znacznie przyspieszyć testowanie aplikacji pod kątem dostępności, gdyż istnieje sporo narzędzi, które pozwalają na częściową automatyzację tego procesu np. axe DevTools. Wtyczkę tę można wykorzystać do przeprowadzania zarówno testów jednostkowych, jak i E2E. Niezwykle ważne są jednak testy manualne i należy je przeprowadzić z uwagą.

„Rynek narzędzi developerskich wspierających pracę nad a11y jest ogromny" - zauważył Michał - „Pozwolę sobie wyróżnić tylko część z nich:

• Axe — najpopularniejsze narzędzie oraz wtyczka do Chromium, które automatycznie wygeneruje dla Was raport z naruszeniami a11y. Jeśli preferujecie manualną listę, to polecam https://www.a11yproject.com/checklist/.
• React-aria — rozwijana przez Adobe biblioteka React składa się z komponentów, które zostały napisane z myślą o accessiblility. Są dostarczane bez stylowania, więc można je spokojnie dopasować do konkretnego UI. Jeśli chcecie wykorzystać react-aria do bardziej customowych lub istniejących komponentów — biblioteka dostarcza też niskopoziomowe API oparte o react hooks, których możemy użyć aby zapewnić a11y komponentom.
• Pakiet a11y z @angular/cdk — zbiór serwisów, dyrektyw i różnych helperów wspierających a11y dostępny w anguar CDK. Nie musisz używać @angular/material, aby z nich skorzystać.
• Wzorce UI ze wsparciem ARIA — jeśli chcecie zagłębić się w to, czego „spodziewają się” czytniki i użytkownicy od treści prezentowanej za pomocą popularnych wzorców UI jak “accordion”, “checkbox”, modal, etc.
• Storybook addon a11y — oficjalna wytyczna dostarczana przez Storybook która uruchamia pod spodem Axa i dostarcza nam raport dla elementów użytych w storybooku.
• WhoCanUse — tester kontrastu tła do treści. Bardzo obrazowo pokazuje, jak różni użytkownicy odbiorą to połączenie barw oraz jak sprawdzi się w wymagających sytuacjach, np. podczas mocnego słońca padającego na ekran.
• Accessible Color Matrix — sprawdź, czy poziom kontrastu dla twojej palety barw jest wystarczający".

Accessibility staje się dużym wyzwaniem, kiedy zostaje ono złożone jedynie na barki developerów. W praktyce zapewnienie dostępności powinno być zadaniem całego zespołu. Ważną rolę grają tu designerzy, którzy są odpowiedzialni za oprawę graficzną aplikacji czy strony.

Accessibility to „must have”?

Dla programistów accessibility nie jest kluczowe w aplikacjach i stronach, ale to nie znaczy, że nie jest ważne.

• Po pierwsze: rezygnując z accessibility, tracisz możliwość komunikacji z różnymi grupami nowych użytkowników.
• Po drugie: nie tworząc udogodnień, ryzykujesz pogorszenie doświadczeń użytkownika podczas czasowych niedogodności.
• Po trzecie: niska dostępność może negatywnie wpłynąć na SEO.
• Po czwarte: możesz stracić użytkownika na rzecz konkurencji.
• Po piąte: firmy są zobowiązane prawem do wdrożenia accessibility w swoich produktach cyfrowych do czerwca 2025.

Twórz dostępne aplikacje, z których każdy będzie mógł skorzystać i zadbaj o doświadczenia wszystkich swoich użytkowników.

Na pytania redaktorki odpowiadał Michał Michalczuk:

Senior Software Engineer i konsultant w Tektit Consulting, IT trainer w infoShare Academy, coś dłubał wcześniej przy Jira Cloud i Atlassian Forge.

Gada, występuje i nagrywa o rzeczach związanych z Front-end'em i IT. Prezentował na największych polskich konferencjach: Infoshare, 4developers, Sphere.it, Boiling Frogs. Współprowadzi front-end'owe "Śniadania z Programowaniem" z JustJoin.it.

Zajrzyj na stronę Michała.