Table of Contents
Testowanie dostępności cyfrowej w aplikacjach mobilnych.
Na ten moment wytycznymi, które określają zasady dostępności jest WCAG. O WCAG możesz przeczytać więcej w poprzednim materiale. Nie ma dedykowanego zbioru kryteriów napisanego pod kątem aplikacji mobilnej. Dlatego wdrażanie dostępności mobilnej zawiera pewną dozę eksperymentowania i dostosowywania do możliwości i ograniczeń każdej z technologii, np. ograniczenia w stosowaniu znaczników ARIA, które mają zastosowanie w strukturze html.
Ze względu na natywne wsparcie dla funkcji ułatwień dostępu, iOS jest często preferowaną platformą wśród osób z niepełnosprawnościami. Aby jednak zapewnić, że aplikacja rzeczywiście spełnia ich potrzeby, testy akceptacyjne powinny być przeprowadzane przez użytkowników z tej grupy — to oni najlepiej ocenią jej użyteczność w praktyce.
Automatyczne testowanie dostępności mobilnej oraz narzędzia automatyczne.
Podobnie jak w przypadku testów dostępności w aplikacjach webowych, tak i w aplikacjach mobilnych warto zacząć od skanowania strony za pomocą automatycznych narzędzi, które wychwycą część większych błędów. Do tego posłużą nam:
a) Accessibility Scanner dla Androida.
Narzędzie jest łatwe w obsłudze i intuicyjne. Wystarczy pobrać z Google Play aplikację, włączyć ją w ustawieniach systemowych, a następnie zeskanować ekran aplikacji, którą chcemy testować. Narzędzie automatycznie przeskanuje ekran w poszukiwaniu niespójności z wytycznymi WCAG.
W celu analizy błędów możemy kliknąć w ikonę obok sugestii, aby pojawiła się nam lista elementów wymagających uwagi. Możemy również kliknąć na konkretny podświetlony element i poznać jego szczegóły. Przejście do „więcej informacji” da nam więcej szczegółów odnośnie samej implementacji, projektowania, a także testowania danego elementu pod kątem dostępności.
Do najczęstszych błędów wykrywanych przez automatyczne narzędzia należą:
- docelowy element dotykowy- zwykle są to zbyt małe elementy klikane. Zaleceniem jest, aby zwiększyć ich rozmiar
- nieudostępniony tekst– należy zadbać, aby element miał przypisaną etykietę, dzięki której screen reader będzie mógł prawidłowo odczytać element
- opisy elementów- każdy element na stronie powinien być unikalny, aby użytkownicy korzystający z czytników mogli łatwo nawigować po aplikacji. Dlatego ważne jest określanie roli, celu i tego, co się stanie, kiedy użytkownik kliknie na dany element.
- skalowanie tekstu– tekst powinien poprawnie się wyświetlać przy zoomowaniu, a jego czytelność nie powinna ulec pogorszeniu
- kontrast tekstu- kontrast kolorów pomiędzy pierwszym, a drugim planem, zalecenia WCAG co do kontrastów w linku
b) Accessibility Inspektor dla iOS.
aby używać tego narzędzia należy pobrać i skonfigurować xCode.
Następnie z poziomu narzędzi deweloperskich wybrać Accessibility Inspektor.
Aby móc z niego skorzystać należy uruchomić na symulatorze aplikację. W celach testowych można pobrać dowolny udostępniony kod na GitHubie i zaciągnąć aplikację do xCoda, a następnie uruchomić ją w symulatorze. Będąc na pierwszej zakładce możemy zrobić inspekcje ekranu. Ikonka „celownika” – „target an element” pozwala na wybranie konkretnego elementu na stronie, a strzałki lewo/prawo pozwalają na nawigację po kolejnych elementach ekranu. W kolejnych sekcjach, tj. basic/actions dostajemy informacje o wybranym elemencie. Po naciśnięciu na <play> możemy uaktywnić screen reader. Niemniej jednak testy screen readerem polecam przeprowadzać na fizycznym urządzeniu, gdyż ten na xCodzie nie jest miarodajny.
Druga ikonka na pasku symulatora pozwala na przeprowadzenie audytu. Logika jest podobna do Androida- elementy wymagające uwagi zostają wylistowane.
Dodatkowo można podejrzeć którego konkretnie elementu na ekranie dotyczą uwagi oraz jakie sugestie naprawy narzędzie proponuje. Dodatkowo przy problemach z kontrastem kolorów przy sugestiach mamy wbudowany kalkulator kontrastu kolorów, na którym można eksperymentować i sprawdzić jakie kolory spełniają wymagany kontrast.
Więcej o audycie i więcej screenshotow znajdziesz <tu>.
Trzecia ikonka na pasku symulatora pozwala na przejrzenie różnych opcji ułatwiających dostępność w aplikacji, którą testujesz.
Jednak większy wachlarz możliwości masz na urządzeniu fizycznym. W ustawieniach systemowych-> dostępność możesz wypróbować, jak aplikacja reaguje chociażby na powiększenie tekstu czy sterowanie przełącznikami. Warto przejść każdą opcję dostępności, które na iPhonie zostały pogrupowane na wzrok, ruch, mowę itp.
Aplikacje wspomagające testowanie mobilne.
Możesz również pobrać z Apple Storę aplikację z checklistą ułatwień, które mogą być pomocne na etapie zapoznawania się z dostępnością cyfrową.
Poniżej rzykład wybranych funkcji dostępności, z krótkim wyjaśnieniem działania, które możemy włączyć z poziomu ustawień systemowych. Włączone funkcje zaznaczone są na zielono. Możemy przetestować jak wybrana dostępność działa na natywnych aplikacjach iOSa. Dodatkowo można ściągnąć inne aplikacje i sprawdzić, jak reagują na ustawione ułatwienia dostępu.
Na AppStore dostępna jest również aplikacja zawierająca zbiór dobrych praktyk dostępności. Wypisane są różne komponenty z opisem jak dostępny powinien być dany element. Poniżej podane są również dobre i złe przykłady jak tworzyć dostępny komponent.
Wsparcie systemowe dla manualnych testów dostępności cyfrowej mobilnej.
a) zawartość mówiona/ słuchowa
W testach dostępności aplikacji mobilnych, tak jak webowych, pomocne są czytniki ekranu wspierające testy manualne. Dla iOS będzie to VoiceOver, dla Androida TalkBack. Warto przejść czytnikiem ekranu natywne aplikacje dla obu platform, żeby zaobserwować działanie czytnika dla każdej z technologii. Tak jak wcześniej wspomniane, iOS jest lepiej zaopiekowany pod kątem dostępności niż android. Przekłada się to na większą chęć użytkowania iPhonów przez osoby z ograniczeniami. Dlatego warto zacząć zapoznawać się z dostępnością zaczynając od iOSa. Co konkretnie można nim sprawdzić? Zobacz tutaj
Jako uzupełnienie screen readera warto skorzystać z zawartości mówionej dostępnej na iOS. Zawartość mówiona wspiera również czytanie ekranu i zaznaczonego tekstu, a także informuje o wpisywanych przez użytkownika znakach.
Dodatkowo wsparciem dla zawartości słuchowo-mówionej może być użycie sterowania głosowego dostępnego z poziomu ustawień systemowych dla iOSa.
Na Androidzie zaś znajdziemy Voice Access, który pozwala na sterowanie głosem. Logika sterowania głosem jest analogiczna do gestów. Należy wymawiać to co jest napisane na ekranie i w zależności od tego czy jest to przycisk, link, lista, wymówione słowo „kliknie” i zostanie wykonana akcja odpowiednia dla elementu. Czyli w skrócie, jeśli mamy przycisk send wymówienie send wykona akcję na przycisku i przejdziemy do kolejnego ekranu/ strony (w zależności od zaimplementowanej na ekranie nawigacji).
b) zawartość wzrokowa
Dobrym narzędziem do badania kontrastu kolorów jest Color Contrast Analyser TPGI. Niemniej jednak automatyczne narzędzia typu Accessibility Scanner i Accessibility Inspektor powinny wykryć niewystarczający kontrast przy audycie strony. Rekomendacja WCAG dla kontrastu tekstu i obrazów tekstu to 4,5:1 przy czym dla obrazu i tekstu o dużej skali to 3:1 (kryterium 1.4.3 WCAG).
Kontrast 3:1 dotyczy również elementów nietekstowych (kryterium 1.4.11 WCAG).
Innym kryterium (1.4.4 WCAG) jest możliwość powiększenia rozmiaru tekstu do 200%. Wspomóc dostępność wzrokowa możemy z poziomu ustawień systemowych:
- ułatwienia dostępu-> wzrok dla Androida oraz
- dostępność -> zoom oraz dostępność-> ekran i wielkość tekstu dla iOSa,
gdzie możemy jeszcze bardziej zwiększać kontrasty i wielkości tekstu.
Zobacz czy Twoja aplikacja również reaguje na te zmiany.
c) ruch
Wykonywanie ruchów w celu dotarcia do zwartości ma być uproszczone.
Poruszanie się po czytniku ekranu wymaga „swipowania” zawartości, czyli przeciągania palcem w lewo/ w prawo w zależności od kierunku, w którym chcemy się poruszać. Jest to prosty gest. Po każdym przeciągnięciu fokus przechodzi nam na kolejny dostępny element. Dwukrotne kliknięcie potwierdza nam wybór elementu, na którym aktualnie znajduje się fokus.
Poza czytnikiem ekranu możesz również dobrać gesty, którymi chcesz się posługiwać w telefonie i aplikacjach.
Dostępność -> Dotyk-> AssistiveTouch (iOS) pozwoli Ci na utworzenie własnych gestów. Ponadto w AssistiveTouch możesz podpiąć urządzenia wspomagające, które umożliwią Ci nawigację. W Androidzie możesz z tego skorzystać z poziomu Dostępność-> Interakcje i możliwości manualne-> Przełącznik uniwersalny.
Na iOS poruszanie po aplikacjach wspiera sterowanie przełącznikami z poziomu dostępności. Włączona opcja będzie skutkowała możliwością poruszania przechodzącym fokusem za pomocą podwójnego tapnięcia w plecki iPhona. Zgodnie z natywnym działaniem iOSa fokus nie będzie się zatrzymywał na tymczasowo nieaktywnych elementach, np. nieaktywnym przycisku wyślij.
Śledzenie oczu również dostępne z poziomu dostępności pozwala na nawigację po aplikacjach za pomocą wzroku. Po wstępnej kalibracji wskaźnik pokaże Ci na co patrzysz, a dłuższe zatrzymanie wzroku na elemencie wykona akcję jego kliknięcia. Zasady funkcjonowania można dostosować w ustawieniach sterowania wzrokiem.
Co sprawdzamy w mobilnych testach dostępności mobilnej?
Część testów pokryje się z testowaniem manualnym dostępności w aplikacjach webowych, gdyż kierujemy się podobnymi założeniami dostępności.
Zbiorczo dla testów dostępności mobilnej możemy wyróżnić kilka aspektów i obszarów opisanych poniżej, a o których już była mowa.
- Elementy z zafokusowanego obszaru/grupy powinny być ze sobą logicznie powiązane, aby użytkownik wiedział, które elementy mają ze sobą relacje, a nie musiał zapamiętywać do której pozycji odnosi się kolejny element. Np. zaznaczanie checkboxu przy opcji.
- Dla wartości liczbowych, salda konta, temperatury, nr telefonu powinny być przypisane etykiety, które wyjaśniają daną liczbę (np. aktualna temperatura 24 stopnie dla 24 °; zysk 25 procent dla +25%).
- Skróty, jeśli występują w aplikacji powinny być rozwinięte, wg 3.1.4 WCAG.
- Powinniśmy dostawać informacje o stanie, roli i co się zmieni, jeśli wykonamy daną akcje (np. przełącznik. Wyłączone. Stuknij dwukrotnie, aby przełączyć ustawienie). Skoro już wiemy co możemy zrobić i decydujemy się na przełączenie ustawień to ta nasza wykonana akcja i jej skutek również powinna zostać zakomunikowana przez czytnik.
Fokus
- Czy swipowanie przenosi fokus na kolejny element. Jeśli klikamy w link, otwieramy button sheet, pop- up, okno modalne sprawdzamy czy fokus poprawnie przechodzi na pierwszy element na nowej zakładce/nowym oknie/ekranie. W trakcie przechodzenia po nowo otwartym oknie należy sprawdzić czy fokus nie pozostał na ekranie pod spodem i nie czyta elementów z poprzedniego ekranu. Przy testach fokusu należy również zwrócić uwagę czy fokus się nie zapętla wokół kilku elementów i nie może przejść dalej albo czy nie został zablokowany na konkretnym elemencie. Inną ważną rzeczą jest upewnienie się, ze przenoszenie fokusu na element nie spowoduje nieprzewidzianego zachowania, np. przeniesienie fokusu na link automatycznie go otworzy zamiast w pierwszej kolejności poinformowania o możliwości aktywowania linku i przejścia do np.webview. Przykład zachowania możecie znaleźć w kryterium 3.2.1 WCAG
Nawigacja i nagłówki
- Co do samej nawigacji podstawowymi gestami jest swipowanie, czyli przeciąganie lewo/prawo po elementach i dwukrotne tapnięcia na zaznaczony element, czemu odpowiada enter. Więcej gestów możesz znaleźć przechodząc do Ustawień w Talk Backu lub zapoznając się z samouczkiem w VoiceOver. Na iPhonie możesz się także wspomóc pokrętłem do nawigacji na ekranach. Przyłożenie dwóch palców i obrót spowoduje pojawienie się pokrętła. Dalsze obracanie spowoduje wybór opcji po których chcesz się poruszać, np. po nagłówkach. Po dokonaniu wyboru, przesuniecie palcem w górę/ dół nawiguje Cię po wybranych elementach. W sekcji VoiceOver znajdziesz opcję „pokrętło” z poziomu której możesz, m.in. edytować zawartość pokrętła.
Jeśli chcesz dodatkowo wykorzystać udogodnienia systemowe możesz je wybrać w ustawieniach dostępności
- Wizualnie nagłówki są oznaczane hierarchicznie h1, h2 itd. I można je odróżnić od reszty strony po wielkości i pogrubionej czcionce. Dla czytnika treść nagłówka powinna być oznaczona słownie jako „nagłówek” i informować do której sekcji aplikacji nagłówek się odnosi. Odpowiednie oznaczenie nagłówków w kodzie pozwoli również na sprawniejsze poruszanie się po nich (przeciąganie palcem góra- dół) przykładowo w momencie wyboru na pokrętle nawigacji po nagłówkach.
Formularze
- Formularze wydają się najbardziej kompleksowym zagadnieniem do zaadresowania w aplikacji, gdyż mogą się składać z wielu elementów stanowiących jedną grupę, tj. pole edycji, opisy, dodatkowe informacje oraz linki.
Etykieta oraz pole do wpisania tekstu powinny być ze sobą logicznie powiązane. Struktura i relacje pomiędzy tymi elementami powinny być dostępne dla czytnika, który przekaże logiczną całość. Więcej o tym 1.3.1 WCAG.
Warto się zapoznać z tym kryterium, gdyż jest to jedno z podstawowych zasad (poziom A) w dostępności. Więcej o poziomach tutaj.
Dodatkowo pola mają zwykle placeholdery, które podpowiadają co trzeba w dane pole wpisać, np. imię. W trakcie wpisywania placeholder znika, a osoby z niepełnosprawnościami kognitywnymi mogą mieć problem z zapamiętaniem co trzeba było w dane pole wpisać. Warto zatem zawrzeć informacje dla czytnika, aby pamiętał co w to pole należało wpisywać, kiedy placeholder zniknie podczas edycji.
Podczas uzupełniania formularzy mogą pojawić się również błędy. W takim przypadku trzeba poinformować użytkownika na czym polega błąd i jak go poprawić. Z pomocą przychodzi walidacja zawartości, podawanie sugestii co do poprawnej wersji lub/i automatyczne uzupełnienie treści, aby uniknąć ponownego wpisywania tych samych treści (automatyczne zaciąganie).
Pozostałe elementy
- Linki powinny zawierać informacje, dokąd one kierują i czy po kliknięciu zostanie otwarte nowe okno/webview/przeglądarka. Szczegółowo opisuje to kryterium 2.4.9 WCAG. Innym kryterium określającym zachowanie linków w kontekście jest kryterium 2.4.4 WCAG.
Linki w aplikacji powinny mieć spójny tekst jednym z kryteriów WCAG jest m.in. spójność identyfikacji danego elementu, co z kolei zapewnia przewidywalność). Innymi słowy- jeśli w aplikacji są linki pełniące tę samą funkcję, to są oznaczone tak samo. Natomiast jeśli użyty jest taki sam tekst dla linków, ale każdy spełnia inną funkcję, to należy to zaadresować poprzez nadanie dodatkowych etykiet, aby takie elementy były samodzielne i same w sobie zrozumiałe.
Przykładowo FAQ użyty w różnych miejscach aplikacji: przy regulaminie, promocji, oferowanych usługach: <Łącze. Najczęściej zadawane pytania warunków promocji. Kliknij, aby otworzyć w nowym widoku.>
- Audio i wideo powinno mieć zapewniona alternatywę, np. transkrypcje, napisy.
- Opisy obrazów powinny mieć prawidłowe teksty alternatywne. Np. zębatka reprezentuje ustawienia, trzy kropki pionowe- menu itd.
- Elementy dekoracyjne aplikacji, jeśli nie niosą za sobą znaczenia nie muszą być czytane przez screen reader.
Natomiast jeśli informacja jest przekazywana za pomocą użycia konkretnego koloru to należy dostarczyć dodatkowe instrukcje w celu zrozumienia i obsługi treści. Np. dodatkowa treść podświetlająca się na czerwono przy formularzu wyboru informująca o konieczności zaznaczenia odpowiedzi, aby przejść dalej. W takim przypadku należy taką dodatkową informację zawrzeć w kodzie poprzez opisanie znaczenia, a nie koloru.
- Nie zapomnij również skorzystać z narzędzia do testów automatycznych, aby wyłapać błędy związane z kontrastami obrazów, tekstu i wielkościami oraz odstępami czcionek. Wesprzyj się narzędziami systemowymi do oceny widoczności tła i pierwszego planu wraz ze znajdującymi się na nim obrazami i tekstami. Z pomocą przychodzą nam tu wymagania 1.4.1 -1.4.13 WCAG
