Dobrze wiemy, że dostępność cyfrowa to nie trend ani dodatek do wymagań projektowych czy chwytliwy temat, wokół którego pojawia się dużo dyskusji. Jest to nieodłączny aspekt naszych cyfrowych doświadczeń, które spotykamy w produktach bankowych, sklepach internetowych, platformach edukacyjnych czy produktach z branży transportu pasażerskiego i wielu innych.
Co to oznacza dla zespołu, które tworzy produkty cyfrowe?
W praktyce oznacza to, że o dostępności nie powinniśmy myśleć dopiero w momencie audytu gotowej strony czy aplikacji. Mniej kosztownym i pracochłonnym podejściem jest uwzględnienie jej na samym początku, czyli od momentu researchu, tworzenia interfejsu, przygotowywania treści, implementacji komponentów i testowania produktu.
Co to jest WCAG, czyli Web Content Accessibility Guidelines?
To zbiór wytycznych pomagających tworzyć strony i aplikacje dostępne dla jak największej liczby użytkowników, także osób z niepełnosprawnościami. WCAG 2.2 - najnowsza wersja standardu opiera się na 4 głównych zasadach, zawiera 13 wytycznych i 86 kryteriów sukcesu. Kryteria są podzielone na trzy poziomy zgodności: A, AA i AAA.
Tworzenie dostępnych produktów zgodnie z wytycznymi to wspólna odpowiedzialność, zwykle kojarzona jedynie z kodem. W rzeczywistości wszystko zaczyna się od zaprojektowania architektury informacji, flow i interfejsu. Osoby odpowiedzialne za content przygotowują treści, komunikaty i opisu grafik. Ostatecznym etapem jest implementacja dewelopera, który wciela wszystko w życie i tworzy działający produkt. Dlatego dostępność to wspólna i równa odpowiedzialność całego zespołu.
Dostępność zaczyna się już na etapie idei
Jednym z najczęstszych praktyk przy tworzeniu produktów cyfrowych jest: „najpierw zróbmy aplikację, a później zajmiemy się dostępnością”.
Takie podejście kończy się zazwyczaj listą poprawek, które obejmują problem z kontrastem, nieprawidłową strukturą semantyczną kodu, brakiem etykiet formularzy czy komponentami, których nie da się obsłużyć za pomocą klawiatury ani przez technologie asystujące (czytniki ekranu).
Im później wykryjemy problem z dostępnością, tym bardziej kosztowna i czasochłonna może być jego naprawa. Co ważniejsze, konsekwencje ponosi przede wszystkim użytkownik może nie być w stanie dokończyć zakupu, zarezerwować wizyty czy kupić biletu lotniczego.
Jeśli designer już podczas tworzenia komponentów w design systemie uwzględni dostępność, sporządzi dokumentację handoff do implementacji, rozwiązanie może zostać zastosowane konsekwentnie w całym portfolio produktów firmy. Jeżeli ten sam błąd zauważymy po wdrożeniu kilkudziesięciu ekranów w różnych projektach, nawet niewielka zmiana zaczyna wymagać znacznie więcej ilości poprawek i nadrabianie długu technicznego.
Co designer powinien brać pod uwagę?
Kontrast to dopiero początek
Kontrast jest prawdopodobnie jednym z najbardziej rozpoznawalnych tematów związanych z dostępnością. Dla WCAG 2.2 na poziomie AA zwykły tekst powinien mieć kontrast minimum 4.5:1, duży tekst 3:1, istotne elementy interfejsu i grafiki 3:1, a informacja nie powinna być przekazywana wyłącznie za pomocą koloru.
Znaczenie mają również czytelność typografii, wielkość tekstu, hierarchia informacji, odstępy i sposób komunikowania stanów interfejsu. Dotyczy to głównie wytycznych WCAG: 1.3.1 Informacje i relacje, 1.4.1 Użycie koloru, 1.4.4 Zmiana rozmiaru tekstu, 1.4.12 Odstępy w tekście oraz 4.1.3 Komunikaty o statusie. Oznacza to, że treść powinna być czytelna i logicznie uporządkowana, tekst możliwy do powiększenia, odstępy nie mogą zaburzać interfejsu, a ważne informacje nie powinny być przekazywane wyłącznie kolorem.
Kolejnym tematem, który powoduje wiele problemów z dostępnością, są formularze. Jeśli błędne pole zostanie oznaczone wyłącznie czerwoną ramką, część użytkowników może nie zauważyć, co poszło nie tak. Dlatego warto łączyć kolor z ikoną i przede wszystkim z jasnym komunikatem, który wskazuje błąd i podpowiada, jak go poprawić. Dotyczy to m.in. wytycznych WCAG: 1.4.1 Użycie koloru, 3.3.1 Identyfikacja błędu, 3.3.2 Etykiety lub instrukcje oraz 3.3.3 Sugestie dotyczące błędów.
Logiczna kolejność fokusu
Dla użytkownika korzystającego z klawiatury focus pełni bardzo ważną funkcję: pokazuje, z którym elementem strony może wejść w interakcję, może to być przycisk, accordion, link czy też pola w formularzu.
Jeśli jest niewidoczny lub przykryty innymi elementami na stronie użytkownik traci orientację i nie może wykonać podstawowych czynności np: wyłączyć okno modalnego, które blokuje cały serwis.
Dlatego projektując flow strony lub aplikacji, warto zadbać o logiczną i przewidywalną nawigację, użytkownik powinien wiedzieć, co wywołuje kolejny ekran, gdzie aktualnie się znajduje i jak wrócić do poprzedniego kroku, bez ryzyka utknięcia w pętli.
Dotyczy to m.in. wytycznych WCAG:
- 2.4.3 Kolejność fokusu - fokus powinien przechodzić przez elementy w logicznej kolejności,
- 2.1.2 Brak pułapki klawiatury - użytkownik nie może zostać „uwięziony” w jednym elemencie lub obszarze,
- 3.2 Przewidywalność - interfejs powinien zachowywać się w sposób spójny i przewidywalny.
Czytnik ekranu - projektuj także to, czego nie widać
Użytkownik czytnika ekranu korzysta z logicznej struktury, nagłówków, etykiet i nazw elementów. Każdy designer powinien zadbać, aby przyciski, linki, formularze i komunikaty miały jasne opisy, a zmiany stanu interfejsu były możliwe do odczytania przez technologie asystujące (czytniki ekranu). Dotyczy to m.in. wytycznych WCAG: 1.3.1 Informacje i relacje, 2.4.6 Nagłówki i etykiety, 3.3.2 Etykiety lub instrukcje, 4.1.2 Nazwa, rola, wartość oraz 4.1.3 Komunikaty o statusie.
A co powinien wiedzieć deweloper?
Dostępność nie kończy się na etapie projektowania. Nawet poprawnie zaprojektowany interfejs może stracić swoją dostępność, jeśli zostanie niewłaściwie zaimplementowany.
Semantyczny HTML ma znaczenie
Jedną z podstaw dostępności jest korzystanie z właściwych elementów HTML. Jeśli dany element pełni konkretną funkcję, powinien być zaimplementowany za pomocą odpowiedniego znacznika: przycisk jako button, nagłówek jako h1, h6, element listy jako li, a link jako a. Dzięki temu struktura strony jest poprawnie rozpoznawana przez przeglądarki i technologie asystujące (czytniki ekranu).
Oczywiście w wielu produktach pojawiają się również komponenty tworzone całkowicie customowo. W takich przypadkach można wykorzystać np.
Dla programisty WCAG oznacza więc znacznie więcej niż znajomość listy kryteriów. To także umiejętność podejmowania właściwych decyzji podczas codziennej implementacji.
Osoby, które chcą przejść przez te zagadnienia praktycznie, od semantyki HTML i ARIA po testowanie dostępności - mogą sprawdzić szkolenie Sages Dostępność cyfrowa stron zgodnie z WCAG dla programistów. Jest ono skierowane do osób, które chcą nauczyć się projektować i wdrażać rozwiązania zgodne z WCAG w codziennej pracy deweloperskiej.
Obsługa interfejsu bez użycia myszy
Z perspektywy dewelopera ważne jest, aby cały interfejs dało się obsłużyć wyłącznie za pomocą klawiatury, bez używania myszy. Użytkownik powinien móc przechodzić między elementami w logicznej kolejności, zawsze widzieć aktualny focus i korzystać z przycisków, linków, formularzy, menu czy modali za pomocą klawiszy takich jak Tab, Shift+Tab, Enter, Spacja i Esc. Trzeba też unikać pułapek fokusu oraz zadbać, aby customowe komponenty zachowywały się tak samo jak ich natywne odpowiedniki. Dotyczy to m.in. wytycznych WCAG 2.1.1 Klawiatura, 2.1.2 Brak pułapki klawiatury, 2.4.3 Kolejność fokusu oraz 2.4.7 Widoczny fokus.
Teksty alternatywne - alt to nie wszystko
Dobrym przykładem pokazującym, że dostępność wymaga współpracy designu, dewelopmentu i contentu, są teksty alternatywne. Często temat jest upraszczany do zasady: „każdy obraz musi mieć alt”. Samo dodanie atrybutu nie oznacza jednak, że grafika stała się dostępna. Najpierw trzeba odpowiedzieć na pytanie: jaką funkcję pełni obraz w konkretnym kontekście?
Jeśli grafika jest wyłącznie dekoracyjna, niekoniecznie powinna być odczytywana przez czytnik ekranu. Jeśli przekazuje istotną informację, tekst alternatywny powinien przekazywać jej znaczenie. Jeśli obraz jest jednocześnie linkiem lub elementem interaktywnym, użytkownik powinien przede wszystkim dowiedzieć się, do czego dany element służy.
Dobry tekst alternatywny nie jest więc mechanicznym opisem wszystkiego, co znajduje się na zdjęciu. Wyobraźmy sobie fotografię osoby stojącej przy samochodzie elektrycznym. W artykule dotyczącym elektromobilności istotny może być model samochodu. W tekście opisującym wydarzenie ważniejsza może być osoba znajdująca się na zdjęciu. Ten sam obraz może więc wymagać zupełnie innych opisów w zależności od tego, gdzie zostanie wykorzystany.
Dlatego tworzenie opisów alternatywnych jest konkretną kompetencją. Temat ten można pogłębić podczas szkolenia Tworzenie opisów alternatywnych, które koncentruje się właśnie na prawidłowym przygotowywaniu opisów grafik dla osób korzystających z technologii asystujących (czytników ekranu).
Automatyczne testy nie wystarczą
Narzędzia automatycznie analizujące dostępność są bardzo przydatne. Pozwalają szybko wykryć część prostych problemów i mogą być elementem procesu developmentu czy CI/CD.
Nie są jednak w stanie zweryfikować wszystkiego.
Automat może wykryć brak atrybutu alt, ale znacznie trudniej będzie mu stwierdzić, czy konkretny opis rzeczywiście przekazuje użytkownikowi potrzebną informację. Podobnie jest z obsługą aplikacji. Narzędzie może wskazać część błędów technicznych, ale nie zastąpi manualnego przejścia całego procesu przy użyciu klawiatury czy sprawdzenia interfejsu z czytnikiem ekranu.
Dlatego dostępność warto testować na kilku poziomach - od etapu projektowania, przez implementację i testy automatyczne, aż po testy manualne oraz badania z prawdziwymi użytkownikami.
WCAG to proces, a nie ostatnia pozycja na checkliście
Najlepsze efekty osiąga się wtedy, gdy dostępność jest częścią całego procesu tworzenia produktu, a poszczególne osoby w zespole rozumieją, w jaki sposób ich decyzje wpływają na użytkownika.
Dlatego WCAG warto poznawać przede wszystkim w praktyce. Umiejętność stosowania wymagań już podczas projektowania i programowania sprawia, że dostępność staje się naturalną częścią produktu. Pomagają w tym również praktyczne szkolenia z dostępności i WCAG.
