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
-
25.10.2024Dostępność cyfrowa
Cześć… do niedawna byłem ignorantem
Cześć. Mam na imię Andrzej i do niedawna byłem ignorantem. Udawałem, że świat osób dotkniętych „niepełnosprawnościami” (jak to oficjalnie nazywamy),…
-
29.01.2024Akademia WCAG
WCAG 2.1 – kryterium 2.4.10 – Nagłówki sekcji (Poziom AAA)
Dziś kryterium WCAG 2.4.10 nagłówki sekcji. Zapraszamy! Kryterium 2.4.10 nagłówki sekcji kryterium objęte poziomem AAA Duża część kryterium dotycząca nagłówków…
-
09.02.2023Akademia WCAG
WCAG 2.1. – kryterium 1.2.4 – Napisy (na żywo) (poziom AA)
Kryterium 1.2.4 (poziom AA) dotyczy napisów, które powinny zostać dodawane do multimediów nadawanych na żywo, takich jak wywiady, podcasty, wiadomości…