Testowanie dostępności cyfrowej aplikacji

08.01.2024 | Marta Bobowska-Michalik

Testy Moje ING

O potrzebnie dostępności słyszeliście pewnie już nie raz. Jest ważna nie tylko ze względu na użytkowników z niepełnosprawnościami. Każdy z nas może zderzyć się z chwilowymi utrudnieniami w korzystaniu z treści cyfrowych – brak okularów, awaria myszki, potrzeba obejrzenia materiału wideo bez włączania dźwięku. Poradzimy sobie z nimi, jeśli materiał, który nas interesuje, będzie przygotowany zgodnie z zasadami dostępności cyfrowej. W tym wpisie znajdziecie garść informacji, jak tę dostępność możemy przetestować.

 

 

Czym jest dostępność i po co ją testować? 

Dostępność cyfrowa (accessibility) to, w uproszczeniu, takie tworzenie produktów i usług cyfrowych, by mógł z nich korzystać każdy, bez względu na niepełnosprawność czy problemy poznawcze (np. wynikające z wieku czy chorób).

Najważniejszy obecnie obowiązujący dokument związany z dostępnością to Web Content Accessibility Guidelines (WCAG) 2.1. Została niedawno wydana wersja 2.2, jednak akty prawne póki co odwołują się do wersji 2.1. To obszerna specyfikacja, opisująca dokładne wytyczne do tworzenia dostępnych produktów cyfrowych. Jako bank mamy ustawowy obowiązek implementacji standardów WCAG na swoich stronach internetowych i w udostępnianych klientom aplikacjach na poziomie nie niższym niż AA.

Linki do dokumentu:


Mamy cztery zasady WCAG 2.1, spełnienie każdej z nich sprawdzane jest na trzech poziomach zgodności.

Zasady WCAG 2.1:

  1. Postrzegalność - spraw by użytkownicy mogli korzystać ze strony internetowej lub aplikacji za pomocą dostępnych dla nich zmysłów.
  2. Funkcjonalność - spraw by użytkownicy mogli znajdować i używać treści oraz funkcji, niezależnie od tego, jak nawigują (np. za pomocą samej klawiatury, samej myszy oraz urządzeń dotykowych np. smartfonu).
  3. Zrozumiałość - spraw by użytkownicy rozumieli treści i sposób działania strony lub aplikacji.
  4. Solidność (w polskim i unijnym prawie określana jako kompatybilność) - spraw by treści i funkcje działały poprawnie w wielu różnych programach użytkowników (np. przeglądarkach internetowych oraz czytnikach ekranu osób niewidomych).

Poziomy dostępności:

  • A — poziom podstawowy, który musi zostać spełniony, aby większość użytkowników z niepełnosprawnościami mogła korzystać z najważniejszych użyteczności serwisu, ale nie zapewnia komfortu użytkowania i dostępu do wszystkich opcji
  • AA — poziom średni, który powinien zostać spełniony, aby większość użytkowników z niepełnosprawnościami mogła korzystać z serwisu bez większych problemów, ale nie uwzględnia wszystkich możliwych scenariuszy i preferencji
  • AAA — poziom zaawansowany, który gwarantuje użytkownikom z niepełnosprawnościami najwyższy komfort korzystania z serwisu i pełną dostępność do dostarczanej zawartości

Podmioty publiczne są zobowiązane do zapewnienia dostępności na poziomie AA.
 

Jak testować dostępność?

Weryfikacja pod kątem dostępności obejmuje testowanie:

  1. Na komputerach stacjonarnych i urządzeniach mobilnych za pomocą narzędzi online.
  2. Za pomocą nawigacji klawiaturowej.
  3. Za pomocą czytnika ekranu.
  4. Przy użyciu narzędzi kontrastu kolorów

 

Narzędzia online

Najczęściej korzystam z:

  • Rozszerzenia axe DevTools - Web Accessibility Testing, dostępnego w przeglądarce Chrome. To szybkie, lekkie narzędzie do testowania ułatwień dostępu - analizuje witrynę, ujawniając większość typowych problemów z dostępnością. Więcej informacji: https://www.deque.com/axe/
  • WAVE - narzędzia online, które analizuje strony pod kątem zgodności z WCAG. Wykryte na stronie komponenty dostępności oraz błędy i miejsca, które wymagają weryfikacji człowieka, WAVE oznacza różnobarwnymi ikonami z informacją o błędach oraz o zgodnościach w wymogami.

Oczywiście narzędzi online jest znacznie więcej – warto je przejrzeć i dobrać optymalne do swoich potrzeb. Narzędzia online są bardzo pomocne, ale nie są w stanie wykryć wszystkich niezgodności, dlatego ważne jest wykonanie również pozostałych testów, o których piszę poniżej.

 

Nawigacja przy użyciu klawiatury

Każdy „klikalny” element, który wchodzi w interakcję z użytkownikiem i wykonuje jakąś akcję, musi być obsługiwany klawiaturą. Dotyczy to również nagłówka i stopki, jeśli zawierają „klikalne” treści.

Najprościej przetestować ten wymóg przechodząc przez całą stronę przy użyciu klawisza TAB. Każdy element powinien mieć fokus (domyślne oznaczenie aktywnego linka czy pola formularza) widoczny podczas nawigacji, aby ułatwić zlokalizowanie punktu, w którym się znajdujemy. Powinniśmy dotrzeć do każdego linku, przycisku czy pola formularza. Aby powrócić do poprzedniego elementu należy użyć kombinacji SHIFT + TAB. Do poruszania się wewnątrz elementu używamy strzałek klawiatury. Niektóre komponenty wymagają obsługi innymi klawiszami jak np.: checkbox/radio oznaczane spacją, zakładki obsługiwane strzałkami, zamykanie okienek dialogowych oprócz przycisków X również poprzez klawisz ESC, listy rozwijane strzałkami. Bloki tekstu i grafiki same w sobie nie powinny być dostępne przy pomocy klawisza TAB, gdyż nie są to elementy interaktywne.

Lista kontrolna do wykonania na różnych urządzeniach stacjonarnych/mobilnych podczas korzystania z klawiatur zewnętrznych

Fokus klawiatury - sprawdź, czy:

  • kolejność fokusa na witrynie jest intuicyjna i zgodna z porządkiem wizualnym strony internetowej, łatwa w użyciu,
  • wszystkie funkcje są łatwe w użyciu i dostępne wyłącznie za pomocą klawiatury,
  • fokus nigdy nie zostanie pominięty w elemencie i nie będzie można go uniknąć za pomocą samej klawiatury,
  • fokus jest zawsze widoczny dla wszystkich przeglądarek/urządzeń w sposób dostępny dla użytkowników słabowidzących lub daltonistów,
  • za każdym razem, gdy użytkownik przechodzi między elementami (zmienia fokus) na stronie internetowej, nie następuje zmiana kontekstu,
  • przestrzegane są Praktyki Autorskie WAI - ARIA 1.1. https://www.w3.org/WAI/ARIA/apg/, czyli wykorzystywane są znaczniki uzupełniające html o znaki odczytywane przez czytniki ekranu,
  • unikasz jednoznakowych skrótów klawiaturowych – jeśli są, nie powinny zakłócać działania żadnych skrótów przeglądarki ani innych czytników ekranu i można je wyłączyć,
  • łącze Pomiń nawigację do głównej zawartości powinno znajdować się na górze strony (może być ukryte, ale widoczne, gdy zostanie aktywowane za pomocą klawiatury).

Kolejność zakładek:

  • przejdź TAB przez stronę, aby sprawdzić, czy kolejność jest logiczna (od lewej do prawej i od góry do dołu),
  • sprawdź, czy możesz aktywować wszystkie elementy interaktywne za pomocą klawiszy Enter lub Spacji, w zależności od elementu,
  • zbadaj, czy do wszystkich elementów strony można dotrzeć za pomocą klawiatury (menu rozwijane, elementy menu, przyciski i inne elementy interaktywne) i za jej pomocą wybierać pozycje menu lub rozwijane pozycje.

Formularze:

  • kolejność zakładek w formularzach powinna być logiczna,
  • użytkownik powinien mieć wystarczająco dużo czasu na wypełnienie formularza – jeśli po określonym czasie bezczynności ważność formularza mija, to użytkownik powinien być o tym poinformowany i mieć możliwość przedłużenia jego ważności,
  • komunikaty walidacyjne pól formularza powinny być zrozumiałe i anonsowane przez aplikacje asystujące,

Okno dialogowe i wyskakujące okienka:

  • gdy tylko okno dialogowe się otworzy, fokus klawiatury powinien być ustawiony w oknie dialogowym, np. na przycisku zamknięcia, potwierdzenia, albo pierwszym polu formularza jeśli takie jest,
  • okno dialogowe można zamknąć za pomocą klawiatury – przyciskiem oraz klawiszem ESC,
  • po zamknięciu okna dialogowego fokus powinien ustawiać się na elemencie, który aktywował okno dialogowe na stronie nadrzędnej, a jeśli już go nie ma, to na następnym naturalnym w kolejności nawigacji elemencie.

Sterowanie multimediami: w przypadku karuzel wideo, audio i animowanych:

  • można ręcznie sterować odtwarzaniem/pauzą,
  • elementy sterujące można przełączać kartami,
  • sterowanie można aktywować za pomocą klawiatury.

Pomijanie linków nawigacyjnych (skip links):

  • linki do pomijania nawigacji są widoczne po zaznaczeniu klawiatury.

 

Czytniki ekranu

Treści powinny być dostosowane do czytników ekranu (screen reader), dzięki czemu mogą z nich korzystać osoby niewidome i niedowidzące.
Podczas testowania przy użyciu czytników łatwo też wykryć przeoczone w tekście literówki.

Zazwyczaj używane kombinacje czytników ekranu z przeglądarkami:

Mobile:

  • Android + Talkback - wbudowany czytnik
  • iOS + VoiceOver - wbudowany czytnik

Desktop

  • Chrome i Firefox + NVDA – do pobrania z centrum oprogramowania
  • Safari + VoiceOver

Skróty klawiszowe i podręczniki obsługi czytników:

  • VoiceOver: https://www.applevis.com/guides/macos-voiceover/complete-list-voiceover-keyboard-shortcuts-available-macos
  • NVDA: https://webaim.org/resources/shortcuts/nvda
  • Podręcznik: https://www.nvda.pl/podrecznik-uzytkownika
  • Lista kontrolna dotycząca testowania przy użyciu czytnika ekranu

Upewnij się, że:

  • strona ma odpowiedni tytuł, aby użytkownicy czytników ekranu wiedzieli, na jakiej stronie się znajdują - zazwyczaj powinna to być nazwa podstrony/widoku + nazwa serwisu/firmy/usługi
  • obrazy, które nie mają charakteru dekoracyjnego, są odczytywane przez czytnik ekranu i mają odpowiedni tekst alternatywny,
  • obrazy dekoracyjne nie są odczytywane przez czytnik ekranu,
  • wszystkie elementy interaktywne (przyciski, checkboxy, linki, przyciski radio, pola edycji zawierają informację o tym, jaką pełnią rolę (np. są linkiem, przyciskiem),
  • wszystkie elementy interaktywne mają etykiety (np. „Prześlij” w przypadku przycisku/łącza Prześlij),
  • pola błędów zawierają odpowiedni komunikat o błędzie,
  • komunikaty o błędach są odczytywane przez czytnik natychmiast po ich pojawieniu się na stronie,
  • powtarzające się elementy funkcjonalne na stronie jak np.: link do strony głównej, przycisk wyszukiwarki, pozycje głównej nawigacji mają tą samą etykietę tekstową,
  • powtarzające się elementy na stronie występują w tej samej kolejności np.: po logo jest menu, potem wyszukiwarka, główna treść, stopka i tak na każdej podstronie/widoku chyba, że wejdziemy w osobny proces w którym będzie tylko jakiś formularz bez pozostałych elementów.

Linki

  • jeśli są tekstowe to czytnik zawsze na początku musi odczytać widoczną etykietę a dopiero potem dalszą np. niewidoczną część,
  • mają charakter opisowy i nie zawierają tekstu ogólnego, takiego jak „kliknij tutaj”, „czytaj więcej”, „więcej”, „sprawdź”, „tu”, „tutaj”, „pobierz”; link może wyglądać na ogólny, np. „czytaj więcej” ale czytnik powinien doczytać dalszą, niewidoczną  część np. „Czytaj więcej o kredycie mieszkaniowym”,
  • rola przypisana do linka jest ogłaszana przez czytnik ekranu.

Nagłówki:

  • powinny być logiczne, aby zapewnić strukturę i wskazać znaczenie treści,
  • nie należy pomijać poziomów nagłówków,
  • na stronie powinien znajdować się tylko jeden H1,
  • użytkownicy powinni mieć możliwość poruszania się po stronach za pomocą nagłówków - w czytnikach na desktopie przy pomocy klawisza „H”.

Pomiń linki nawigacyjne:

  • linki do pomijania nawigacji („skip linki”) powinny być obecne i odczytywane przez czytnik ekranu,
  • linki pomijające powinny działać zgodnie z przeznaczeniem z czytnikiem ekranu, przeskakując do głównej zawartości strony i innych wskazanych miejsc (np. do dodatkowego menu, kluczowego obszaru lub wyszukiwarki).

Obrazy:

  • obrazy czysto dekoracyjne w formie <img> powinny mieć ALT="" (czytnik powinien je pomijać),
  • wszystkie znaczące obrazy powinny mieć opisowy tekst alternatywny,
  • wszystkie przyciski obrazów nawigacyjnych powinny mieć opisowy tekst alternatywny.

Multimedia:

  • elementy sterujące multimediami powinny mieć tekst alternatywny,
  • obraz lub dźwięk nie powinien uruchamiać się automatycznie,
  • kontrole powinny być odpowiednio oznakowane.

Formularze:

  • pola formularza powinny mieć etykiety opisowe, odczytywane przez czytnik ekranu,
  • etykiety nie powinny być odczytywane kilkukrotnie np. „Imię pole podaj imię”,
  • jeśli oprócz etykiet są dodatkowe informacje np. pod/obok pola formularza to one również powinny być odczytywane,
  • użytkownicy powinni móc wypełnić formularz i przesłać go,
  • przyciski powinny być opisane i poprawnie odczytane przez czytnik ekranu,
  • pola wymagane/opcjonalne powinny być właściwie odczytane przez czytnik ekranu, tak by było jasne, które są obowiązkowe a które opcjonalne,
  • błędy w polu formularza powinny być sygnalizowane przez czytnik ekranu niezwłocznie po ich pojawieniu się.

Tabele danych:

  • powinny mieć wyznaczone wiersze nagłówka i/lub kolumny,
  • powinny mieć tytuły,
  • nie powinny być zagnieżdżane,
  • nagłówki wierszy i kolumn należy powiązać z odpowiednim atrybutem zakresu.

 

Testowanie kontrastu kolorów i powiększenia (zoom)

Powiększenie i kontrast:

  • tekst to rzeczywisty tekst, a nie obraz tekstu,
  • rozmiar czcionki zwiększa się w miarę powiększania strony,
  • strona jest responsywna przy skalowaniu do 400 procent przy startowej szerokości 1280 px,
  • elementy nie są pomieszane po powiększeniu,
  • kontrast dla tekstu powinien być na poziomie 4,5:1 a dla elementów graficznych (jak np. ikony informacyjne, funkcjonalne, obramowanie pól formularzy, fokus) 3:1 – kontrast można sprawdzić np. przy pomocy narzędzia WAVE.

Testowanie bez dźwięku:

  • użytkownicy mają kontrolę nad odtwarzaniem/wstrzymywaniem wideo lub audio,
  • wszystkie filmy mają napisy.

 

Podsumowanie

Testowanie zgodnie z opisanymi tu praktykami nie jest audytem strony/aplikacji i nie wyczerpuje wszystkich zagadnień związanych z dostępnością cyfrową, ale pozwala na wykrycie większości niezgodności z wymogami WCAG. Mam nadzieję, że informacje tu zawarte ułatwią Wam pracę i pomogą w dostarczaniu użytkownikom optymalnie dla nich przygotowanych treści.