Dostępność cyfrowa szkoleń e-learningowych w Articulate Storyline

Zapewnienie dostępności cyfrowej lub zgodności z WCAG 2.1 coraz częściej pojawia się w wymogach, szczególnie ze strony instytucji publicznych. Co może, a czego nie może Articulate Storyline w tym zakresie? Dzielimy się wrażeniami z projektu, który zrealizowaliśmy z Urzędem m.st. Warszawy(i).

Dostępność cyfrowa - dla kogo i po co

Wyobraź sobie, że masz przejść przez szkolenie e-learningowe z zamkniętymi oczami. Bez kursora, ale wyłącznie za pomocą klawiatury i czytnika ekranu. Ponadto musisz zakończyć je z wynikiem pozytywnym. Trudne? Dla niektórych użytkowników to konieczność. Mówisz dostępność (accessibility), myślisz – osoby z niepełnosprawnością wzroku, czyli niewidome, słabowidzące z zaburzeniami widzenia barw. Jednak szczególne potrzeby wobec szkoleń mają też osoby niesłyszące i z ograniczoną zdolnością słyszenia, osoby nie mówiące, osoby o ograniczonej sprawności manualnej, osoby o ograniczonych zdolnościach poznawczych, osoby narażone na padaczkę fotogenną czy osoby o ograniczonym zasięgu(ii).  

‍

Prawo wymaga od instytucji publicznych, aby dostępne cyfrowo były ich strony internetowe, również wewnętrzne, np. intranety czy szkolenia e-learningowe. Pisaliśmy o tym w poście „WCAG, dostępność cyfrowa i inne zmartwienia zamawiających szkolenia e-learningowe”. Mieliśmy okazję uczestniczyć w projekcie zapewnienia dostępności cyfrowej szkoleń e-learningowych realizowanym dla Urzędu m.st. Warszawy z udziałem niezależnego eksperta, pana Jacka Zadrożnego, autora bloga informaton.blog.  

‍

Jednym z efektów naszego przedsięwzięcia było pilotażowe szkolenie e-learningowe. Wykonaliśmy je w Articulate Storyline. Wybraliśmy to oprogramowanie ze względu na szeroki zakres jego funkcjonalności, popularność na rynku oraz deklarację producenta o zgodności z wymogami dostępności. Czego się nauczyliśmy?

Moc standardu, czyli samochód a rower

Pierwszą lekcją, którą wyciągnęliśmy, było to, że wymogi dostępności cyfrowej w wielu przypadkach opisują serwisy internetowe, których złożoność technologiczna w porównaniu do e-szkoleń jest jak skomplikowanie samochodu w stosunku do roweru. Wyciągnęliśmy więc z ogólnie napisanych standardów to, co ma zastosowanie do typowych szkoleń e-learningowych - złożonych z ekranów i publikowanych w standardzie SCORM. Wymogi dostępności cyfrowej wymienia załącznik do ustawy o dostępności cyfrowej(iii). Jego zawartość pokrywa się – choć nie całkowicie – z wytycznymi WCAG 2.1 na poziomie AA. Oba zbiory wytycznych, mimo pewnych różnic, będę dla uproszczenia nazywał standardami, wytycznymi lub wymogami dostępności. Część z nich nie ma zastosowania do kursów, a szczególnie:

• 1.2.4 Napisy rozszerzone (na żywo) – ponieważ szkolenia SCORM nie są transmisjami na żywo
• 1.3.5. Określenie pożądanej wartości – ponieważ zazwyczaj w szkoleniach SCORM nie stosuje się formularzy, które wymagają podawania danych osobowych ani technologii autouzupełniania
• 2.5.1. Gesty wskazujące – ponieważ, jak czytamy: ten wymóg dotyczy treści internetowych, które interpretują działania dotykowe (tj. nie dotyczy to działań wymaganych do obsługi programu użytkownika (przeglądarki internetowej) lub technologii wspomagającej)
• 2.5.4 Aktywowanie ruchem – ponieważ jest to funkcjonalność wcale lub rzadko stosowana w szkoleniach, dla których najczęstszymi urządzeniami odbiorczymi są komputery stacjonarne lub laptopy.

Oczywiście to tylko mały fragment wszystkich wymogów. Tych zaś, które mają zastosowanie, jest znacznie więcej – z obszarów postrzegalności, funkcjonalności, zrozumiałości i kompatybilności(iv). W projekcie musieliśmy je jednak odnieść do tych elementów interfejsu i typów interakcji, które są typowe dla szkoleń online. I tak, aby zaprojektować dostępne cyfrowo szkolenie e-learningowe, musimy zadbać o:

• przejście klawiaturą (co oznacza np. eliminację ćwiczeń typu przeciągnij i upuść),
• spójność nawigacji i punktów orientacyjnych,
• kontrastową widoczność i logiczną kolejność fokusu,
• personalizację w zakresie rozmiaru i formatowania tekstu,
• identyfikatory językowe dla czytników ekranu,
• odpowiednie kontrasty dla tekstów, grafik i elementów interfejsu,
• obsługę multimediów – wzmocnienie kontroli nad ich działaniem oraz transkrypcję lub audiodeskrypcję,
• opisy alternatywne lub usunięcie widoczności grafik.

Szereg technik, które sugeruje konsorcjum W3C, trudno wdrożyć w narzędziach autorskich takich jak Storyline. Co innego, gdy tworzymy serwis i mamy większą kontrolę nad kodem i technologią. Co innego natomiast, gdy korzystamy z edytora - zaawansowanego, ale nie tak elastycznego, jak webowe frameworki czy czysty HTML.

‍

I oto druga rzecz, której się nauczyliśmy – dostępność cyfrowa szkoleń e-learningowych nie jest jednoznaczna z tym, że chodzi tylko o WCAG. Gdyby tak było, to groziłby nam wysyp e-szkoleń, które – owszem, są zgodne ze standardami – ale ich wygląd i poziom złożoności przypomina strony www z początków internetu. Od samego początku projektu zależało nam na tym, aby:

1. projektować uniwersalnie, czyli tak, aby ten sam produkt cyfrowy był dostępny i atrakcyjny w takim samym stopniu dla wszystkich użytkowników – niezależnie od stopnia ich sprawności wzrokowej, ruchowej czy umysłowej,

2. projektować optymalnie, czyli tak, aby praca nad każdym szkoleniem, które ma być dostępne cyfrowo, nie trwała i nie kosztowała znacznie więcej niż nad standardowym kursem. W praktyce oznaczało to korzystanie z dobrodziejstwa narzędzi autorskich ze wszystkimi ich ograniczeniami.

Nie wierz producentom

Gdy przeczytaliśmy deklarację Articulate o zapewnieniu zgodności z WCAG(v), wydawało się nam, że opracowanie dostępnych ekranów pójdzie sprawnie. Okazało się jednak – głównie w trakcie testów z ekspertami – że nie wszystko, co wydaje się służyć dostępności w istocie takim jest. Oto kilka najpoważniejszych przeszkód, na które natrafiliśmy.

‍

Powiększenie tekstu do 200%

Zgodnie ze standardami użytkownik powinien mieć możliwość powiększenia tekstu do 200% bez narzędzi asystujących. Niestety ta funkcjonalność nie działa prawidłowo. Po włączeniu opcji „Powiększ, aby dopasować” (Fit to zoom) zawartość tekstowa jest częściowo ukrywana, a dotarcie do niej wymaga przewijania w dwóch wymiarach:

Gdy zaś zresetujemy widok do domyślnych 100%, widok wraca do wartości 125%.

Kłopotliwe skróty

Jedną z cech dostępnego szkolenia jest możliwość przejścia go za pomocą klawiatury. W Storyline mamy szereg wbudowanych skrótów klawiaturowych.

‍

W trakcie testów okazało się, że nie ma potrzeby pokazywać ich wszystkich.  

• Niektóre da się zastąpić bardziej intuicyjnymi, np. Enter zamiast Ctrl+Alt+s do zatwierdzania odpowiedzi na ekranach quizowych.  

• Niektóre wprowadziły testerów w zakłopotanie, np. Ctrl+Alt+r związany z przewijaniem multimediów nie działał poprawnie wobec klipów z video lub narracją.
• Niektóre skróty pokrywają się z takimi, które mają już inne zastosowanie, np. Ctrl+Alt+z czy Ctrl+Alt+s wywołują polskie znaki diakrytyczne.  

Brak edycji elementów stanowiących barierę

Articulate zapewnia, że gdy użyjemy playera w wersji modern, to spełnimy wymagania dostępności. Częściowo to prawda, ponieważ jest responsywny. Niestety nie wszystkie jego elementy zachowują współczynnik kontrastu 3:1, który jest wymagany dla elementów interfejsu. Przykładem jest przycisk OK, który pojawia się, gdy użytkownik nie udzieli odpowiedzi w quizie. Niestety deweloper nie ma wpływu na wygląd tego przycisku.

‍

Podobnie ma się sprawa z angielskimi nazwami elementów playera – „sidebar”, „slide” czy „top bar” – które nie pojawiają się na liście etykiet do przetłumaczenia. W efekcie, użytkownicy, którzy korzystają z czytników ekranu, otrzymują polsko-angielską mieszankę nazw punktów orientacyjnych.

‍

Inne drobiazgi i odpowiedź na ryzyko

To nie wszystkie problemy, jakie napotkaliśmy. Wspomnę jeszcze, że mimo wymogów nie da się np. oznaczyć fragmentu tekstu w innym języku, a formularze w quizach nie mogą być oznaczone za pomocą zestawu pól (parametr fieldset). Bardzo niewygodne jest korzystanie z wbudowanego słownika, choć w playerze classic mogliśmy nawigować po hasłach i rozwijać wybrane z nich. Musieliśmy też zrezygnować z niektórych popularnych interakcji, np. markerów, lightboxów czy stanów (state), ponieważ ich dostępność – przynajmniej na razie - pozostawia wiele do życzenia.  

‍

Kompletną porażką pod względem dostępności cyfrowej są publikacje z Articulate Rise.

Wiele problemów zgłosiliśmy do Articulate jako błąd lub propozycję dodania funkcjonalności (feature request). Na razie bez odpowiedzi, ale pokładamy nadzieję w częstych aktualizacjach. W przypadku innych obmyśliliśmy i zaimplementowaliśmy własne rozwiązania, np. sterowanie narracją na ekranach.  

Co działa dobrze i z czego warto korzystać

Uczciwie trzeba jednak dodać, że w Storyline znajdziemy takie funkcje lub możliwości edycji, które ułatwią nam zapewnienie dostępności. Są to na przykład:

• Opcja Accesibility dla obiektów, którą wyłączymy widoczność elementów dekoracyjnych oraz dodamy opisy alternatywne.
• Focus order, dzięki któremu ustawimy różne elementy w takiej hierarchii, która będzie sensowna dla użytkowników czytników ekranowych.
• Opcja Accesibility Text, która renderuje teksty jako HTML, a nie grafiki SVG i można na nie wpływać, np. zmieniać odstępy między słowami, za pomocą wtyczek takich jak Helperbird.
• Edytor napisów (CC) do multimediów i możliwość zmiany rozmiaru ich fontu w ustawieniach playera.
• Możliwość ręcznej edycji zmiennych systemowych (szczególnie Player.AccesibleText czy Player.ZoomToFit) oraz etykiet, aby sprecyzować lub ujednolicić ich brzmienie w języku polskim.

Z pewnością nauczyliśmy się więc w tym projekcie korzystać z takich funkcjonalności Storyline, których w wielu projektach nie używaliśmy. Nauczyliśmy się przy tym, że nie wszystko, co producent opatrzył etykietą związaną z dostępnością, należy brać z całym dobrodziejstwem inwentarza.  

Wzbogać swoje oprzyrządowanie

Następną lekcją, którą wyciągnęliśmy z tego projektu, było korzystanie z nowych narzędzi, które umożliwiają lub ułatwiają testowanie. Znajdziemy ich sporo, a większość (w tym wszystkie poniższe) są darmowe. W doborze skorzystaliśmy z rekomendacji ekspertów, z którymi współpracowaliśmy. Oto kilka z nich:

• NVDA – czytnik ekranowy (screen reader), który pozwalał nam sprawdzić, na ile dostępne i zrozumiałe są elementy szkolenia – nawigacja, teksty i grafiki. Chwilę czasu zajęła nam nauka nawigowania po tym narzędziu, np. przełączanie się między trybem odczytu a trybem formularzy.
• WebAIM Contrast Checker – narzędzie internetowe, które pozwala dobrać kolorystykę o właściwym kontraście.
• WAVE i ANDI – dodatki do przeglądarki, która pomagają namierzyć problemy związane z dostępnością, np. brakujące opisy alternatywne czy identyfikatory językowe.

Podsumowanie

Za pomocą Articulate Storyline da się zbudować dostępne cyfrowo szkolenie, ale:

• nie będzie ono w pełni zgodne z wymogami WCAG 2.1 AA,
• należy ostrożnie korzystać z funkcjonalności teoretycznie przygotowanych pod dostępność,
• musimy się pogodzić z tym, że z pewnych typów interakcji musimy zrezygnować lub zastąpić je własnymi
• trzeba uwzględnić, że czas implementacji i testowania będzie dłuższy niż w standardowym projekcie.

Mimo wszystko warto. To w końcu nasz wkład w to, aby uczynić ten świat lepszym – dostępnym dla każdego na równych zasadach.  

‍

(i) Zadanie zrealizowano w ramach projektu „Equal chances – equal work” (Równe szanse - równa praca), współfinansowanego z Norweskiego Mechanizmu Finansowego na lata 2014 – 2021 w ramach programu “Social Dialogue - Decent Work”. Projekt był prowadzony przez UMW oraz Fundację Aktywizacja. Jego celem jest tworzenie lepszych warunków pracy dla osób z niepełnosprawnościami. Jednym z elementów projektu jest stworzenie przyjaznych szkoleń e-learningowych.

(ii) Listę opracowaliśmy na podstawie sekcji VII Dyrektywy Parlamentu Europejskiego i Rady (UE) 2019/882 z dnia 17 kwietnia 2019 r. w sprawie wymogów dostępności produktów i usług

(iii) Ustawa z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych [PDF]

(iv) To cztery zasady, które stanowią fundament dostępności internetowej – zarówno w WCAG 2.1., jak i ustawie o dostępności cyfrowej. Z nich wynikają wytyczne i kryteria sukcesu oraz techniki.

(v) Articulate Storyline 360 Accessibility Conformance Report (stan na 15 września 2021 r.)