Co powinien zawierać raport z audytu dostępności cyfrowej?

Typowy audyt dostępności aplikacji zakończony jest wysłaniem czterech typów dokumentów do zamawiającego:

1. Raport podsumowujący audyt – dokument ten podsumowuje wszystkie działania, które zostały podjęte w ramach audytowania aplikacji. Z tego raportu można dowiedzieć się jaki był cel oraz zakres testów, konfiguracja sprzętu testerów, jakiej metodyki użyto podczas badań dostępności. W tym dokumencie ogólnie podsumowana jest także liczba spełnionych i niespełnionych kryteriów WCAG oraz liczba znalezionych problemów z podziałem na wagi. Jest to dokument zalecany do zapoznania się przez managerów odpowiedzialnych za poprawianie dostępności oraz osoby zlecające przeprowadzenie audytu. 

1. Lista kontrolna zgodności aplikacji z wytycznymi WCAG – lista ta przedstawia, które kryteria sukcesu WCAG są spełnione, niespełnione lub też nie były testowane w aplikacji. Każde z niespełnionych kryteriów ma także przypisany do siebie przynajmniej jeden problem. Problemy opisane w tym dokumencie są zarówno wynikające z testów manualnych jak i automatycznego skanu dostępności. Każdy problem jest dokładnie opisany, posiada rekomendacje poprawy często wzbogacone o przykładowy kod rozwiązania, ma przypisaną wagę oraz w wielu przypadkach także informację o zrzucie ekranu przedstawiającego problematyczny element. Ten dokument rekomendowany jest do zapoznania się przez developerów i   UI designerów wprowadzających poprawki do aplikacji oraz testerów odpowiedzialnych za późniejsze retesty poprawionej wersji aplikacji. 

1. Lista problemów znalezionych przez użytkownika z niepełnosprawnościami – w zależności od wymagań projektu różna ilość użytkowników z różnymi rodzajami niepełnosprawnościami może przeprowadzać testy w ramach audytu. W zależności od tego może powstać więcej lub mniej raportów, jednak wszystkie co do swojej struktury są takie same. Jest to lista problematycznych z punktu widzenia użytkownika elementów, gdzie każdy problem jest opisany, posiada rekomendacje konsultowaną z ekspertem dostępności cyfrowej. Część problemów znalezionych przez użytkowników pokrywa się z problemami mającymi wpływ na niespełnienie WCAG i w raporcie użytkownika z niepełnosprawnością są one odpowiednio oznaczone i posiadają informację o tym jakie ID ma ten problem w Liście kontrolnej zgodności aplikacji z wytycznymi WCAG oraz jakie kryterium sukcesu jest przez ten problem niespełnione. 

1. Skompresowany plik ze zrzutami ekranu – jest to zbiór zrzutów ekranu, które powiązane są z odpowiednimi zgłoszeniami z raportów. Na poszczególnych zrzutach oznaczone są elementy, które stanowią problem z punktu widzenia danego zgłoszenia.

Raport z audytu dostępności to nie koniec pracy, ale początek.

Co dzieje się po zakończeniu testów dostępności serwisu? Czy wysłanie plików z raportami to już całkowity koniec takiego projektu?

Najczęściej nie. Zdajemy sobie sprawę z tego, że samo znalezienie błędów i wskazanie rekomendacji nie zawsze jest wystarczające do tego, aby klient mógł od razu zacząć poprawiać dostępność aplikacji. A ponieważ bardzo zależy nam na czynieniu świata bardziej dostępnym jako dodatkowe usługi do audytu oferujemy także:

• Dodanie wszystkich naszych zgłoszeń do Twojego systemu obsługi zgłoszeń takiego jak JIRA, Trello czy ClickUp, dzięki czemu Twój zespół będzie mógł łatwiej zapoznać się ze znalezionymi problemami i zaoszczędzicie czas potrzebny na własnoręczne przeklejanie zgłoszeń z raportu do systemu. 

• Konsultacje dotyczące przeprowadzonego audytu. Konsultacje mogą być wykorzystane: 

• przez UX i UI designerów jako np. konsultacje design systemu lub nowych, dostępnych widoków aplikacji w Figmie lub innym tego typu narzędziu,  

• testerów na np. omówienie scenariuszy testów, oczekiwanych zachowań elementów oraz baz zawierających przykłady dostępnych komponentów, 

• developerów na np. omówienie przykładów działającego i nie działającego kodu, bibliotek dobrych przykładów czy standardów takich jak ARIA 

• menegerów odpowiedzianych za zapewnienie dostępności na omówienie strategii podejścia do procesu zapewniania i poprawy dostępności w długofalowej perspektywie. 

Jeśli po przeprowadzonym audycie w trakcie konsultacji okaże się, że potrzebna jest ich większa ilość zawsze oferujemy możliwość dokupienia dodatkowego czasu lub jeżeli będzie to bardziej efektywne przeprowadzenia szkolenia dla zespołu lub warsztatów adresujących konkretną potrzebę.

• Retesty wprowadzonych poprawek. Retesty mają na celu sprawdzenie, czy poprawione przez Was problemy, zarówno związane z WCAG jak i te z testów z użytkownikiem, zostały usunięte poprawnie i czy poprawione elementy zachowują się zgodnie z wymaganiami dostępności. Podczas retestów sprawdzamy jedynie wcześniejsze zgłoszenia przypisując im status „Poprawione” lub „Niepoprawione” i dodając do tego komentarz lub rekomendacje dalszej poprawy. 

• Reaudyt po wprowadzeniu wszystkich poprawek. Podczas reaudytu oprócz ponownego testowania wcześniejszych zgłoszeń, aby sprawdzić czy zostały one wyeliminowane sprawdzamy ponownie też wszystkie inne elementy w aplikacji. Dzięki temu możemy upewnić się, że do serwisu nie zostały wprowadzone żadne nowe błędy i że po poprawkach serwis jest zgodny z wymaganiami WCAG oraz jest użyteczny dla osób z niepełnosprawnościami. 

• JEŚLI MIELIBYŚMY ZDEFINIOWANĄ USŁUGĘ DOSTĘPNOŚC W ABONAMENCIE TO MOŻNA TU TEŻ O NIEJ NAPISAĆ I JĄ PODLINKOWAĆ.