Po dość ogólnym wprowadzeniu do tematu dostępności, mówiącego o tym po co w ogóle nam to potrzebne (pod tym adresem poprzedni artykuł) czas przejść do konkretów, czyli tego, co może nam pomóc tę dostępność testować – poniżej opowiem o kilku używanych na co dzień narzędziach, z odniesieniem do tego dlaczego nie jest to skończona lista i dlaczego nie możemy tych narzędzi traktować jako wyroczni.
Ale przedtem – historia z życia wzięta, która dała mi motywację do napisania tego artykułu szybciej, niż się spodziewałam (ale przez cały czas później, niż planowałam).
Jedno proste zadanie
Jednym z zadań jakimi mam przyjemność zajmować się na co dzień jest dbanie o to, żeby produkty firmy w której pracuję były jak najbardziej dostępne. Póki co jest to przede wszystkim testowanie gotowych rozwiązań pod kątem dostępności, identyfikowanie elementów które trzeba/można/warto poprawić (wbrew pozorom są to często zupełnie różne elementy i obszary) oraz proponowanie i wdrażanie poprawionych rozwiązań. Ukoronowaniem jednego z takich większych działań miało być sporządzenie krótkiego filmu obrazującego, jak dzięki działaniom naszego zespołu zmienia się nasza aplikacja. Zmienia się oczywiście na lepsze, bardziej dostępne i bardziej inkluzywne. Czy tak jest? Mam nadzieję, ale tym razem nie o tym.
Do zaprezentowania tego w sposób najszybszy i najbardziej obrazowy, szczególnie dla osób które wcześniej nie miały doświadczeń z dostępnością cyfrową, wybraliśmy przejście przez pewien proces z wykorzystaniem czytnika ekranu. O nim bardziej szczegółowo będzie poniżej, w tej chwili, na potrzeby historii warto wiedzieć, iż jest to program, który na bieżąco odczytuje i prezentuje w formie głosowej wszystko to co dzieje się na ekranie. Koniec końców otrzymujemy więc swego rodzaju opowieść, która w teorii płynnie i jak najszybciej powinna nas prowadzić przez rozpoczęcie (np. wybór produktu) rozwinięcie (jego zakup) i zakończenie (informację zwrotną o tym, iż się udało). W moim przypadku opowieść była jednak tą z gatunku kryminał noir: jest ciemno, nikt nie wie o co chodzi a zakończenia możemy się jedynie domyślać. W tle myśli o morderstwie i wołanie o pomoc.
Krótki, bo mniej więcej trzyminutowy film nagrywałam kilkanaście razy. W między czasie zaliczyłam wszystkie fazy żałoby, od niedowierzania, poprzez gniew (ta trwała akurat dosyć długo) aż do ponurej akceptacji. Na szczęście aplikacja, na którą miałam osobisty wpływ przeszła test dobrze, co było jedynym jasnym punktem na ponurym tle całego procesu.
Po próbie zakupu dowolnej rzeczy w 3 dość losowo wybranych sklepach miałam ochotę wzniecić około-internetowe powstanie na rzecz grzecznego i uprzejmego (w końcu jesteśmy cywilizowanymi ludźmi) zlikwidowania wszystkich serwisów, które:
- oznaczają swoje przyciski jako, w najlepszym wypadku, linki, w najgorszym jako zwykłe divy nie pozwalając mi nigdy dojść do nich jakimkolwiek skrótem klawiszowym,
- o hierarchii nagłówków słyszały ostatnio jakoś tak nigdy,
- witają nas na dzień dobry pop-upem z dużą ilością bardzo interesujących informacji, z którymi mam szansę zapoznać się wyjątkowo wnikliwie, bo utknę z nimi na zawsze, nie mogąc przejść do adekwatnej treści strony. Albo odwrotnie, nigdy się nie dowiem, iż w ogóle się pojawiły ,
- Beztrosko wrzucają na stronę nierealne timery, w zakresie czasu zakupu czy płatności, które mijają podczas gdy czytnik zdąży przeczytać nam co najwyżej coś w stylu “Dziękujemy za wykonan…zajęty…przekierowanie…zajęty”
Najgorsza była konstatacja, iż to wszystko było jednym z działań, które dobrowolnie wykonuję w ramach swojej pracy, jako osoba okazjonalnie posługująca się czytnikiem ekranu. Jestem na tyle uprzywilejowana, iż mogę w takiej sytuacji po prostu wzruszyć ramionami i wesoło przeklikać się przez cały proces przy użyciu myszki. Ba! Mogę choćby nie mieć pojęcia, iż strona, przez którą regularnie robię zakupy, płacę rachunki czy oglądam seriale jest stroną, do której osoba korzystająca z innych technik niż ja nie ma szans dotrzeć. I właśnie dlatego ważne jest, żeby o dostępności mówić, dostępność testować i dostępność zapewniać: bo nie każdy ma tak łatwo jak my. A teraz, po tym bardzo długim wstępie przejdźmy do konkretów.
Co może pomóc?
Poniżej kilka narzędzi/programów/technik, które stosuję na co dzień, aby pracować nad dostępnością cyfrową. Posługuję się nimi najczęściej na początku, żeby zidentyfikować z czym mamy problem, w trakcie wprowadzania konkretnych rozwiązań oraz na końcu, żeby później móc powiedzieć, iż u mnie działa.
Klawiatura
Na pierwszym miejscu pojawi się narzędzie, które praktycznie każdy z nas ma w domu, a które zawiera w sobie (oprócz przeważnie dużej ilości okruszków) masę możliwości – czyli klawiatura. Ta skromna bohaterka życia naszego programistycznego jest absolutnie pierwszym narzędziem, do którego powinniśmy sięgnąć myśląc o testowaniu dostępności. Spróbujmy w tym momencie przestać scrollować i klikać, a kolejną zaplanowaną przez nas czynność (wysłanie maila, otwarcie youtuba w drugiej karcie, szybkie zakupy internetowej drogerii) wykonać tylko i wyłącznie przy użyciu klawiatury. Stawiam dolary przeciwko orzechom (ciekawe, iż w wersji angielskiej brzmi to cokolwiek smakowiciej), iż każdy z Was napotka w tym procesie większe lub mniejsze trudności. A wtedy już nigdy nie spojrzyjcie na przycisk “TAB” tak jak do tej pory.
Czytnik ekranu
Na drugim miejscu czytnik ekranu – czyli oprogramowanie, które w dużym skrócie przetwarza tekst na mowę a następnie odczytuje go użytkownikowi dzięki syntezatora mowy. Używane są nie tylko w połączeniu z klawiaturą, ale także systemem gestów na ekranie dotykowym. Jest kilka najpopularniejszych czytników, w tym pierwsza trójka czyli Jaws, VoiceOver (dla posiadaczy produktów od Apple) oraz NVDA. Ja ze względu na system Windows do sprawdzania aplikacji używam tego ostatniego, przeważnie w połączeniu z klawiaturą.
Używanie czytników ekranu przez osoby widzące wydaje się być sprawą cokolwiek kontrowersyjną. Przede wszystkim dlatego, iż osoba widząca, cóż, widzi, nie jest więc w stanie siłą rzeczy korzystać z czytnika tak sprawnie i kompetentnie jak osoba która czytnikiem posługuje się ze względu na swoje potrzeby. Co za tym idzie osoba testująca często używa go nieprawidłowo lub w bardzo ograniczonym zakresie. Ponadto kombinacji różnego rodzaju technologii wspomagających jest bardzo wiele, nie można więc przejść przez stronę czytnikiem a następnie odtrąbić sukcesu o tym, iż o to stworzyliśmy skończony i całkowicie dostępny produkt. Kuszące, owszem, ale mało uczciwe.
Ja sama takiego czytnika w pracy używam i uważam, iż zaznajomienie się z tym narzędziem i próby skorzystania z różnych stron przy jego wykorzystaniu przede wszystkim uświadamiają nam skalę potrzeb. A po jakimś czasie (np. kilku godzinach spędzonych na próbach wykonania dość prostych czynności w stylu zakupu krzesła) sprawiają, iż zaczynamy cieplej myśleć o prawidłowej strukturze semantycznej a wizja dodania przez nas kilku etykiet do pól naszego formularza wywołuje w nas ekscytację i prawdziwą radość. Chociażby dlatego warto.
Wtyczki, narzędzia
Osobne miejsce zajmują wszelkiego rodzaju analizatory kontrastu: online lub lokalne, proste lub bardziej skomplikowane. Z takiego absolutnego minimum mamy m.in. wtyczki do przeglądarek w stylu Contrast Color Checker czy Color Constrast Analyzer, który możemy sobie zainstalować i odpalać zawsze, gdy mamy wątpliwości co do kolorów użytych przez nas na naszej stronie. Dzięki zaznajomieniu się z tymi narzędziami na etapie projektowania i planowania naszych aplikacji a także rozmów z klientami jesteśmy w stanie wdrożyć rozwiązania, które przez cały czas będą estetyczne i być może choćby zgodne z naszym gustem, ale przede wszystkim pozwolą uniknąć nam wroga numer jeden tej serii, czyli umieszczenia na stronie wtyczki “Zmień kontrast”.
Dlaczego tak bardzo odrzucam ideę takiej wtyczki? Bo jeżeli komuś wybrana przez nas paleta kolorów nie pozwoli zapoznać się z naszą aplikacją to przede wszystkim sobie od nas pójdzie. Ostatecznie, jeżeli już będzie mu wyjątkowo zależało (bo na przykład jesteśmy stroną należącą do administracji rządowej), to sam zmieni sobie kontrast dzięki narzędzi, które ma na swoim komputerze/telefonie (osoby zmuszone zwracać na to uwagę dość gwałtownie uczą się liczyć przede wszystkim na siebie w tej kwestii). A często zainstalowanie tego rodzaju wtyczki wyzwala myślenie, iż skoro mamy ją na swojej stronie to zrobiliśmy już absolutnie wszystko co się dało w zakresie dostępności. Co za tym idzie nie weryfikujemy naszych treści pod innym, znacznie ważniejszym kątem.
Innym bardzo przydatnym narzędziem jest wtyczka Wave, która pozwalana na zbiorczą analizę różnego rodzaju czynników w sposób kompleksowy: mamy tu nie tylko informacje o wielu różnego rodzaju błędach ale również alerty dotyczące potencjalnych problemów czy wskazówki dotyczące rozumienia konkretnych zasad WCAG.
Co jeszcze? Bardziej wyspecjalizowane narzędzia, które pozwalają nam zwrócić uwagę chociażby na hierarchię nagłówków (HeadingsMap) czy poprawność użytego przez nas kodu HTML (walidatory, takie jak chociażby Markup Validation Service).
Uwaga, to tylko narzędzia!
Co ważne i warte ponownego podkreślenia: wszystkie wymienione wyżej narzędzia to narzędzia automatyczne, czyli zaprogramowane na wykrycie bardzo ograniczonych i dość oczywistych błędów związanych z dostępnością. Nie możemy uznawać ich za wyrocznię w zakresie WCAG i na ich podstawie wyrokować czy nasza strona jest, czy nie jest w faktycznie dostępna cyfrowo – tutaj ostateczną opinię może i powinien wydać doświadczony audytor, który podda stronę manualnemu, dużo bardziej rozbudowanemu audytowi.
Ale czy w takim razie powinniśmy odpuścić używanie jakichkolwiek tego typu rozwiązań? Absolutnie nie, w końcu kilka małych kroków jest znacznie lepsze niż taktyczny odwrót (od dostępności).
Jeśli analizujemy jakieś istniejące rozwiązanie a następnie wprowadzamy do niego poprawki związane z dostępnością cyfrową warto wykonać takie testy zarówno na początku procesu jak i po wprowadzeniu zmian. Dlaczego? Ze względu na to, iż taki powtórny “audyt” (cudzysłów bardziej niż konieczny, bo przeważnie jest to jedynie nasza bardziej lub mniej subiektywna opinia) jest często sposobem na znalezienie pominiętych czy zapomnianych błędów. Pozwala on również zweryfikować czy to, co pięknie wygląda na papierze (albo w projekcie, albo w kodzie) faktycznie ma sens.
I o ile podczas naszych testów nigdy nie będziemy w stanie przyjąć w pełni perspektywy osoby ze szczególnymi potrzebami (o ile rzecz jasna nie jesteśmy takimi osobami) to mając już pewną wiedzę i doświadczenia w używaniu wymienionych wyżej narzędzi będziemy mogli odpowiedzieć na pytanie czy to, co zrobiliśmy jest faktycznie użyteczne i może komuś ułatwić życie. A może po prostu dorzuciliśmy garść znaczników aria i jakiś opis do obrazka na stronie, na której bez myszki i kilkuletniego doświadczenia w Internecie nie jesteśmy w stanie kupić wspomnianego gdzieś wyżej krzesła?
Podsumowując
Testowanie naszych aplikacji/stron/pomysłów dzięki wskazanych wyżej narzędzi i technik jest (szczególnie na początku naszej drogi w tej dziedzinie) pracochłonne, często męczące i mylące a dla osób mniej cierpliwych może być źródłem prawdziwej frustracji.
I dobrze.
Obraz zupełnie niepowiązany.Może dzięki temu za którymś razem jako programiści/projektanci/managerzy dojdziemy do wniosku, iż warto te nasze strony/projekty/pomysły tworzyć od razu w sposób dostępny i (co naprawdę ważne) przy aktywnym zaangażowaniu osób, które takie trudności spotykają niemalże codziennie i są najlepszymi ekspertami w swojej dziedzinie, którą możemy nazwać na potrzeby tego artykułu tytułową “codzienną walką o zakup krzesła”. Dopiero wtedy uda się tą walkę zamienić w normalny proces biznesowy, który przecież nie powinien wywoływać w porządnym człowieku morderczych żądzy.
