Jak audytować i tworzyć raport z audytu dostępności cyfrowej. Część druga.
- Przejdź do artykułów z tagiem A11Y
- Przejdź do artykułów z tagiem accessibility
- Przejdź do artykułów z tagiem audytDostepnosciCyfrowej
- Przejdź do artykułów z tagiem dostepnoscCyfrowa
- Przejdź do artykułów z tagiem niepełnosprawni
- Przejdź do artykułów z tagiem WCAG21
- Przejdź do artykułów z tagiem WCAG22
- Przejdź do artykułów z tagiem Web Content Accessibility Guidelines
Treść artykułu
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:
- HeadingsMap – rozszerzenie pozwalające sprawdzić strukturę nagłówków;
- Landmark Navigation via Keyboard or Pop-up – identyfikuje punkty orientacyjne;
- Colour Contrast Analyser – aplikacja do weryfikacji kontrastu.
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
Accessibility Specialist & WCAG 2.1 Auditor & Quality Assurance
Polecane artykuły
-
07.05.2023Dostępność cyfrowa
Recenzja książki Anny Goc „Głusza”
Książka Anny Goc „Głusza” to poruszający reportaż, który z wielką wrażliwością przedstawia życie osób Głuchych. Autorka nie tylko opowiada o…
-
23.06.2023Akademia WCAG
WCAG 2.1. – kryterium 1.4.5 – Tekst w postaci grafiki (2.1) (poziom AA)
O co chodzi w kryterium 1.4.5 WCAG – tekst w postaci grafiki (poziom AA)? Główną zasadą jest to, by przedstawiać…
-
07.07.2023Akademia WCAG
WCAG 2.1. – kryterium 1.4.7 – Niska głośność lub bez dźwięków w tle (poziom AAA)
Dzisiaj przychodzimy do Was z kryterium 1.4.7 – niska głośność lub bez dźwięków w tle. Ma ono wspomóc osoby niedosłyszące,…