Tekst przygotowała:
Julia Dündar – Senior Product & Service Designer @ Capgemini
Dostępność cyfrowa nie jest dodatkiem czy “miłym gestem”. To fundament, który decyduje o tym, czy z naszego produktu może korzystać każdy . Z perspektywy projektantki mogę śmiało powiedzieć: bez niej nie da się zbudować naprawdę dobrych doświadczeń dla użytkowników.
Dlaczego jest to tak ważne? Jakie są podstawowe wymagania, związane z dostępnością produktów cyfrowych? Zapraszam do lektury!
Dostępność jest dla każdego – nawet jeśli myślisz, że Cię nie dotyczy
Często, gdy myślimy o dostępności cyfrowej, pierwszym skojarzeniem są osoby niewidome korzystające z czytników ekranu. Oczywiście to kluczowa grupa, ale spektrum jest znacznie szersze. Mówimy nie tylko o osobach z trwałymi niepełnosprawnościami wzroku, słuchu czy mobilności, ale też o tych z trudnościami poznawczymi, jak ADHD czy dysleksja.
Globalnie, według danych WHO, niepełnosprawności doświadcza aż 16% populacji. To 1 na 6 osób! Dla nich odpowiednie dostosowania są konieczne, by w ogóle mogły skorzystać z produktu, nad którym pracujesz.
Co więcej, rozwiązania projektowane z myślą o dostępności tak naprawdę służą nam wszystkim w codziennych sytuacjach. Korzystamy z nich, gdy:
- Oglądamy wideo z napisami w hałaśliwym autobusie.
- Próbujemy odczytać coś z ekranu telefonu w pełnym słońcu (dzięki wysokiemu kontrastowi).
- Mamy kontuzję, przez którą musimy obsługiwać komputer jedną ręką.
- Jesteśmy zmęczeni lub rozkojarzeni i potrzebujemy prostych, jasnych komunikatów w formularzu.
Argumentem ostatecznym stają się też wymagania prawne. Dzięki Europejskiemu Aktowi o Dostępności (EAA) wymogi te zostały rozszerzone na wiele firm prywatnych, w tym platformy e-commerce czy banki. To już nie jest kwestia dobrej woli, a realne ryzyko biznesowe. Ignorowanie tych zasad grozi nie tylko karami finansowymi – w niektórych krajach może oznaczać nawet czasowy zakaz sprzedaży produktów i usług. Dla biznesu e-commerce blokada na kilka miesięcy to potężny cios.
Kluczowe zasady dostępności
Skoro wiemy już, dlaczego dostępność jest tak ważna, pojawia się pytanie: jak w praktyce zabrać się za wdrażanie w życie zasad z nią związanych? Na szczęście nie musimy wymyślać koła na nowo.
Standardem, który porządkuje świat dostępności, jest WCAG (Web Content Accessibility Guidelines). Zamiast uczyć się go na pamięć, kluczowe jest zrozumienie jego czterech fundamentalnych zasad. To one stanowią kompas, który wyznacza kierunek działań dla osoby projektującej dany produkt. WCAG definiuje 3 poziomy zgodności – A (podstawowy), AA (rozszerzony), AAA (najwyższy). Celem dla większości projektów jest zgodność z poziomami A i AA, które są wymagane przez EAA.
Przyjrzyjmy się czterem zasadom zdefiniowanym przez standard.
1. Postrzegalność (Perceivable)
Zasada ta mówi, że użytkownik musi być w stanie odebrać wszystkie prezentowane mu informacje za pomocą zmysłów, którymi dysponuje. Jeśli coś jest czysto wizualne, musi mieć swoją alternatywę tekstową.
Co to oznacza w praktyce?
Odpowiedni kontrast kolorów: tekst musi wyraźnie odcinać się od tła. To kluczowe nie tylko dla osób słabowidzących, ale dla każdej osoby, która korzysta z urządzenia w słońcu. Proste narzędzia (np. wbudowane w przeglądarkę) pozwalają sprawdzić, czy kontrast jest wystarczający.
Ciekawostka: kolor pomarańczowy jest notorycznie trudny do uzyskania w dostępnej, estetycznej formie. Z kolei niebieski jest często bezpiecznym wyborem, który dobrze łączy design z czytelnością.
Teksty alternatywne dla obrazów: każda grafika, która niesie jakąś treść (np. ikona, wykres, zdjęcie produktu), musi mieć tzw. alt text, czyli krótki opis, który jest czytelny dla czytników ekranu.
Ważne: alt text to nie miejsce na marketing! Zamiast pisać o ciastku, że jest „przepyszne i na samą myśl cieknie ślinka”, po prostu opisz, co jest na zdjęciu. Widziałam strony, gdzie linkiem był sam obrazek bez alt textu – wtedy czytnik ekranu odczyta całą, bezużyteczną nazwę pliku.
Napisy dla materiałów wideo: każdy film czy nagranie audio musi mieć transkrypcję lub napisy, aby osoby niesłyszące mogły zrozumieć jego treść.
2. Funkcjonalność (Operable)
Wszystko, co da się kliknąć myszką, musi być też możliwe do obsłużenia przy pomocy klawiatury lub innych technologii asystujących.
Co to oznacza w praktyce?
Pełna obsługa z poziomu klawiatury: Osoba korzystająca z aplikacji musi mieć możliwość swobodnego poruszania się po stronie za pomocą klawiszy Tab, Enter i strzałek. Każdy element, z którym można wejść w interakcję, powinien być wyraźnie zaznaczony, gdy znajdzie się w stanie focus. Wyraźna ramka wokół elementu jest tu standardowym rozwiązaniem.
Brak pułapek klawiaturowych: Użytkownik musi mieć możliwość zmiany elementu, który aktualnie jest w stanie focus, przy pomocy klawiatury. Oznaczenie to nie może utknąć w żadnym elemencie (np. w oknie modalnym) bez możliwości jego opuszczenia.
Ważna uwaga dla osób kodujących strony: starajmy się nie zmieniać domyślnego zachowania klawiatury. Osoby korzystające z technologii asystujących polegają na tych standardach.
3. Zrozumiałość (Understandable)
Treść oraz sposób działania aplikacji muszą być jasne i przewidywalne. Technologia nie może stawiać przed ludźmi barier poznawczych.
Co to oznacza w praktyce?
Prosty i zrozumiały język: unikajmy skomplikowanego żargonu tam, gdzie to nie jest konieczne. Zwięzłe, jasne komunikaty ułatwiają życie każdemu, nie tylko osobom z trudnościami kognitywnymi, ale też osobom uczącym się języka czy po prostu rozkojarzonym.
Przewidywalna nawigacja: menu i kluczowe elementy interfejsu powinny znajdować się w tych samych miejscach na różnych podstronach.
Zrozumiałe formularze: pola obowiązkowe powinny być oznaczone gwiazdką.
Używanie atrybutu placeholder zamiast elementu label to zła praktyka. Tekst placeholdera znika, gdy tylko użytkownik zaczyna pisać, co może prowadzić do zdezorientowania. Element label jest zawsze widoczny i zapewnia potrzebny kontekst w każdej sytuacji.
Wszelkie komunikaty błędów i informacje zwrotne dla użytkowników muszą być bardzo jasne, czyli zamiast wyświetlać “Wystąpił błąd”, system, który zaprojektujemy, powinien wskazać problem i powiedzieć jak go naprawić np. „Wypełnij pole “Email” ” lub „Hasło musi zawierać co najmniej 8 znaków”.
4. Solidność (Robust)
Kod strony musi być zgodny ze standardami, dzięki czemu zarówno przeglądarki i technologie asystujące bez problemu odczytają treść.
Co to oznacza w praktyce?
Semantyka ponad wszystko: fundamentem jest czysty, semantyczny kod HTML. To on mówi czytnikowi ekranu, co jest przyciskiem, a co nagłówkiem.
Uważaj z ARIA: częstym błędem jest nadużywanie atrybutu aria-label. Jest to etykieta, która ma za zadanie opisać element tylko wtedy, gdy brakuje mu widocznego tekstu (np. przycisk z samą ikoną). Czasem w zespołach traktujemy ją jak magiczne zaklęcie na dostępność, dodając wszędzie, gdzie się da.
W rzeczywistości powinniśmy ich używać tylko w bardziej skomplikowanych komponentach, gdzie semantyczny HTML nie wystarczy. Źle użyta ARIA może przynieść więcej szkody niż pożytku, dlatego, że aria-label zastępuje tekst widoczny w elemencie. Wtedy treść w czytniku ekranu może być inna niż w przeglądarce.
Jak zacząć z dostępnością cyfrową?
Kiedy w projekcie po raz pierwszy pada hasło „musimy wdrożyć dostępność”, często spotykam się z oporem. Zwłaszcza w zespołach, które mają już gotowy, działający produkt.
Z mojego doświadczenia nie wynika to ze złej woli. Po prostu często zespół dostaje wymagania, ale nie dostaje wiedzy ani narzędzi, by je zrealizować.
A co na to biznes? Tu zwykle pojawia się argument o kosztach. Panuje mit, że „dostępność jest droga”. Klienci boją się rozpoczynać ten proces, bo kojarzy im się z niekończącymi się zmianami.
Prawda jest jednak taka, że znacznie droższe jest ignorowanie dostępności. Droższe są kary finansowe, utracona reputacja, a w skrajnych przypadkach, wynikających z European Accessibility Act, nawet czasowy zakaz sprzedaży produktów.
Dlatego wdrażanie dostępności trzeba zacząć nie od zmiany kodu, ale od zmiany perspektywy.
Pierwszym i najważniejszym krokiem jest edukacja zespołu. Zamiast rzucać ludzi na głęboką wodę, trzeba dać im przestrzeń, by zrozumieli, dlaczego to ważne. Kiedy osoby projektujące i tworzące aplikacje webowe zrozumieją problemy, z jakimi mierzą się użytkownicy, sami zaczną szukać lepszych, bardziej dostępnych rozwiązań.
Zanim zaczniecie wprowadzać jakiekolwiek zmiany, proponuję proste ćwiczenie, które otwiera oczy jak nic innego: spróbujcie sami_e przetestować swój własny produkt.
Odłóżcie myszkę i spróbujcie przejść przez kluczową ścieżkę użytkownika, korzystając wyłącznie z klawiatury. Następnie włączcie wbudowany czytnik ekranu (VoiceOver na macOS, NVDA na Windows, TalkBack na Androidzie) i posłuchajcie, jak dla osoby niewidomej brzmi Wasza aplikacja. Gwarantuję, że to doświadczenie powie Wam więcej niż jakikolwiek automatyczny raport.
Dopiero wtedy, gdy zespół zrozumie sedno problemu, można zacząć włączać dostępność w codzienne procesy. W idealnym świecie myślimy o niej od samego początku projektu. W rzeczywistości często musimy ją wprowadzać do istniejącego produktu. Wtedy kluczem jest, by stała się ona naturalną częścią cyklu życia produktu – elementem kryteriów akceptacji (Definition of Done), stałym punktem podczas code review i częścią testów QA.
Oczywiście, warto wspierać się automatycznymi narzędziami, takimi jak axe czy WAVE, ale z dużą dozą krytycyzmu. One wyłapią tylko część błędów – sprawdzą, czy obrazek ma atrybut alt, ale nie ocenią, czy jego treść jest sensowna. Nic nie zastąpi manualnych testów i ludzkiej empatii.
Przestawienie się na to, by nie zapominać o dostępności to proces. Warto więc patrzeć na to nie jak na koszt, ale jak na inwestycję w lepszy produkt. Taki, który oferuje lepsze doświadczenia każdej osobie i po prostu nikogo nie wyklucza.
