Przejdź do treści
Tyler Franta z Unsplash

W pierwszym artykule z tej serii zgłębiliśmy istotę weryfikacji stanu dostępności cyfrowej. Zidentyfikowaliśmy ją jako potrzebę wyszczególnienia barier, które mogą napotykać użytkownicy, zwłaszcza osoby z niepełnosprawnościami, kiedy mają do czynienia z naszym serwisem, stroną internetową czy też aplikacją mobilną. Przejdźmy do kolejnego etapu: przygotowania się do audytu.

W jaki sposób przygotować się do audytu?

To z pozoru proste pytanie nie ma wcale prostej odpowiedzi. Można by przecież powiedzieć: To banalne! Otwórzmy plik z szablonem raportu z audytu i zacznijmy spisywać napotkane błędy. Przecież każda niezgodność z WCAG musi zostać zgłoszona i natychmiast naprawiona. I tutaj pojawia się pierwsze pytanie pomocnicze: Czy każdy błąd da się naprawić tak, żeby nie wprowadzić ograniczenia z innego powodu, dla innej grupy osób? Czasem musimy zaproponować więcej niż jedno rozwiązanie, aby w zależności od kontekstu, deweloper, projektant czy też redaktor naprawili defekt w prawidłowy sposób, w odpowiednim miejscu, z prawidłowego powodu, za pierwszym razem 🙂 Słowo klucz to kontekst. Już na etapie przygotowań powinniśmy poznać, dla kogo jest przygotowywany przedmiot audytu.W tym celu musimy się zastanowić (lub dowiedzieć od interesariuszy) jak najwięcej na temat:

  • procesów biznesowych;
  • grup docelowych produktu cyfrowego;
  • docelowego poziomu dostępności.

Czy to koniec przygotowań? Oczywiście, że nie. Teraz czas na dostosowanie środowiska do testów dostępności. Oprócz wspomnianego szablonu raportu z audytu dostępności cyfrowej niezbędne będzie wybranie narzędzi wspomagających testy dostępności. W Kinaole każdy z nas ma inny zestaw narzędzi, z których korzysta. Aczkolwiek pewnych narzędzi używają wszyscy. Są nimi zarówno dodatki do przeglądarki, jak i zewnętrzne aplikacje:

Oprócz tego korzystamy również z symulatorów wad wzroku, narzędzi wyświetlających porządek tabulacji czy też skryptozakładek wpływających na kod HTML strony.

Z czego składa się audyt dostępności cyfrowej

Skoro mamy już określone, po co robimy audyt, a także przygotowane środowisko testowe, to czas przejść do samej weryfikacji. W zależności od potrzeb, czasu i budżetu analiza składać się może nawet z 4 etapów. Każdy z nich ma inny wkład w wyszczególnienie barier i przeszkód, z jakimi może spotkać się użytkownik końcowy.

Najszybszą oceną są testy automatyczne przy użyciu narzędzi ogólnodostępnych. Mówimy tutaj o rozszerzeniach przeglądarek, które pozwalają nam wylistować niektóre problemy. Najczęściej używane są:

Taka weryfikacja pozwala na szybkie zorientowanie się, gdzie najlepiej rozpocząć dokładniejsze poszukiwania. Przy użyciu narzędzi automatycznych nie jesteśmy wstanie znaleźć wszystkiego, ale jest to świetny punkt wyjścia do analizy manualnej, czyli tak zwanej metodzie eksperckiej polegającej na weryfikacji kryteriów WCAG zgodnie z technikami przypisanymi do danego kryterium. Sporą część opisaliśmy w serii #AkademiaWCAG. Podczas tego etapu niejednokrotnie możemy wesprzeć się testowaniem z użyciem technologii wspomagających, takich jak czytniki ekranu (NVDA, VoiceOver, JAWS). Pozwala to jeszcze lepiej zrozumieć osoby korzystające na co dzień z czytników ekranu. O tym i nie tylko można usłyszeć na jednym ze szkoleń, które prowadzimy. Poruszany jest tam również temat dużo szerszy, jakim są badania z Osobami z Niepełnosprawnościami.

Za każdym razem staramy się przeprowadzić takie badanie choćby z jedną osobą niewidomą, g/Głuchą, korzystającą tylko z klawiatury oraz trudnościami poznawczymi (w tym z osobami neuroróżnorodnymi). Umożliwia to znalezienie realnych barier, z jakimi użytkownicy się spotykają.

Podsumowanie

Dzisiaj postawiliśmy dwa pytania: w jaki sposób przygotować się do audytu i jak go przeprowadzić. Przygotowujemy się do weryfikacji uszczegóławiając potrzeby i możliwości, a sam audyt dzielimy na cztery podstawowe części:

  • testy automatyczne,
  • testy manualne,
  • testy z użyciem technologii asystujących,
  • testy z Osobami z Niepełnosprawnościami.

W kolejnej odsłonie ustalimy, co jeszcze jest potrzebne do audytu oraz w jaki sposób możemy oceniać napotkane rozwiązania w kodzie HTML.

Radosław Stachurski

Radosław Stachurski

Accessibility Specialist & WCAG 2.1 Auditor & Quality Assurance