Test dostępności aplikacji z użytkownikami: jak przygotować zadania i zebrać uwagi

Zespół sprawdził formularz automatycznym narzędziem i nie zobaczył błędów. Podczas próby z użytkowniczką czytnika ekranu okazuje się jednak, że po wysłaniu formularza trudno odnaleźć komunikat o brakującym polu. Narzędzie mogło poprawnie ocenić wybrane elementy kodu. Nie pokazało całej drogi osoby wykonującej zadanie.

Test dostępności aplikacji z użytkownikami pomaga zrozumieć, gdzie interfejs utrudnia pracę osobom korzystającym z różnych sposobów obsługi. Nie zastępuje oceny zgodności z wymaganiami ani innych testów technicznych. Najwięcej daje wtedy, gdy uczestnicy wykonują rzeczywiste zadania, a zespół obserwuje przebieg, słucha uwag i przekłada je na konkretne poprawki.

Jeśli planujesz taki przegląd, wyślij brief z opisem aplikacji, jej użytkowników i zadań, które mają zostać sprawdzone. Nie przesyłaj haseł ani rzeczywistych danych klientów. Na początek wystarczy przykładowa ścieżka oraz informacja o urządzeniach i sposobach obsługi ważnych dla projektu.

Wybierz zadania, które mają znaczenie

Wyobraźmy sobie portal, w którym klient zgłasza problem i sprawdza jego status. Zespół chce wiedzieć, czy osoba korzystająca z klawiatury potrafi odnaleźć formularz, uzupełnić go i rozpoznać potwierdzenie. To przykład projektowy, nie opis przeprowadzonego badania. Przed zaproszeniem uczestników warto ustalić, co dokładnie ma zostać sprawdzone i dlaczego ta ścieżka jest ważna.

Zadanie powinno mieć cel zrozumiały bez znajomości struktury aplikacji. Zamiast prosić o kliknięcie konkretnego przycisku, można poprosić o zgłoszenie problemu z zamówieniem i sprawdzenie, czy zgłoszenie zostało przyjęte. Uczestnik wybiera wtedy własną drogę. Zespół może zobaczyć, czy nazwy, kolejność i komunikaty pomagają dotrzeć do wyniku.

Wybierzcie kilka etapów, które użytkownik wykonuje samodzielnie. Może to być odnalezienie sprawy, poprawienie błędnego pola, pobranie dokumentu lub zmiana ustawienia. Liczba zadań powinna pasować do czasu spotkania oraz potrzeb uczestnika. Zbyt długa próba może utrudnić skupienie, a zespół otrzyma mniej użytecznych informacji.

O sprawdzaniu funkcji z przyszłymi użytkownikami piszemy w artykule o testowaniu prototypu. Badanie dostępności wymaga dodatkowego uwzględnienia sposobów obsługi i technologii używanych przez uczestników, ale nadal zaczyna się od zadania, które ma sens w ich pracy.

Zaproś osoby odpowiadające zakresowi badania

Osoby z niepełnosprawnościami korzystają z aplikacji na różne sposoby. Jedna używa czytnika ekranu, inna powiększenia, klawiatury lub innej technologii wspomagającej. Potrzeby i doświadczenie uczestników mogą się różnić także przy korzystaniu z tego samego narzędzia. Zespół powinien dobrać uczestników do badanych zadań oraz jasno opisać ograniczenia próby.

Zapytajcie przed spotkaniem, z jakiego urządzenia i oprogramowania dana osoba chce korzystać oraz jakie warunki pomogą jej uczestniczyć w badaniu. Nie zakładajcie, że wszyscy używają identycznej konfiguracji. Jeśli planujecie zdalne spotkanie, sprawdźcie także dostępność narzędzia do rozmowy i sposób przekazania materiałów.

Udział powinien być świadomy i dobrowolny. Przedstawcie cel, sposób wykorzystania uwag oraz to, czy spotkanie będzie nagrywane. Ustalcie warunki organizacyjne i wynagrodzenie odpowiednie do współpracy. Nie proście o informacje zdrowotne, które nie są potrzebne do przygotowania badania. Zespół potrzebuje wiedzieć, jak umożliwić udział i przeprowadzić zadania, a nie znać całą historię uczestnika.

Materiały W3C o udziale użytkowników w ocenie dostępności opisują korzyści z obserwacji osób korzystających z różnych technologii oraz potrzebę łączenia takich badań z oceną wymagań. Jedna osoba nie reprezentuje wszystkich użytkowników. Wynik należy opisać w granicach przeprowadzonej próby.

Przygotuj środowisko i dane

Przed spotkaniem sprawdźcie, czy uczestnik może bezpiecznie wejść do aplikacji i wykonać zadanie. Jeśli używacie kont testowych, przygotujcie dane, które nie ujawniają informacji klientów ani innych pracowników. Zadania powinny prowadzić do przewidywalnego stanu, ale nie mogą podpowiadać całej sekwencji kroków.

Warto przeprowadzić próbę organizacyjną przed pierwszym badaniem. Sprawdźcie zaproszenie, logowanie, dostęp do materiałów i sposób kontaktu w razie problemu. Jeśli uczestnik korzysta z własnego urządzenia, uzgodnijcie, czy będzie potrzebował pomocy przy uruchomieniu środowiska. Celem jest usunięcie niepotrzebnych przeszkód organizacyjnych, a nie dopasowanie użytkownika do wygodnej dla zespołu konfiguracji.

Przy formularzu uwzględnijcie również sytuację błędu. Uczestnik może celowo pominąć pole, aby sprawdzić, czy potrafi odnaleźć komunikat i wrócić do właściwego miejsca. W artykule o dostępnym formularzu firmowym opisujemy etykiety, błędy i obsługę klawiaturą. Badanie z użytkownikiem może pokazać, jak te elementy współpracują podczas rzeczywistego zadania.

Zadbajcie o dostęp do osoby, która potrafi wyjaśnić cel funkcji, ale nie będzie natychmiast podpowiadać każdego kroku. Jeśli uczestnik utknie, prowadzący może zapytać, czego szuka lub jak rozumie komunikat. Pomoc powinna umożliwić dalszy udział, a zespół powinien zapisać, że była potrzebna. Nie chodzi o egzaminowanie użytkownika.

Obserwuj przebieg, nie tylko wynik

Uczestnik może ukończyć zadanie po kilku próbach, korzystając z obejścia, którego zespół nie przewidział. Sam wynik „ukończone” nie pokaże, że odnalezienie przycisku wymagało powrotu do początku albo że komunikat o błędzie nie był powiązany z polem. Zapisujcie kroki, moment trudności oraz to, jak osoba próbowała ją rozwiązać.

Warto oddzielić obserwację od interpretacji. „Uczestniczka wróciła do poprzedniego ekranu i ponownie szukała statusu” jest opisem zdarzenia. „Nie zrozumiała aplikacji” jest już wnioskiem, który może wymagać doprecyzowania. Rozmowa po zadaniu pomaga ustalić, czego osoba oczekiwała i jak odebrała komunikat.

Nie każda różnica w sposobie pracy jest błędem. Użytkownik może wybrać inną drogę niż zaplanował projektant i nadal skutecznie wykonać zadanie. Problemem jest sytuacja, w której ważna informacja lub działanie nie są dostępne albo wymagają nieuzasadnionego obejścia. Zespół powinien porównywać obserwacje z celem badania oraz odpowiednimi wymaganiami.

Przy testowaniu raportu lub panelu warto sprawdzić, czy użytkownik potrafi nie tylko znaleźć liczbę, lecz także zrozumieć jej kontekst i przejść do potrzebnej sprawy. O znaczeniu definicji piszemy w artykule o wskaźnikach na dashboardzie. Dostęp do wartości nie wystarczy, jeśli nie wiadomo, czego ona dotyczy.

Zadbaj o komunikację podczas spotkania

Prowadzący powinien wyjaśnić, że badana jest aplikacja, a nie umiejętności uczestnika. Warto poinformować, że można poprosić o przerwę, zmienić tempo lub zrezygnować z zadania. Sposób prowadzenia powinien umożliwiać swobodne zgłaszanie trudności bez sugerowania, że istnieje jedna właściwa droga.

Niektóre osoby wolą opisywać działanie na bieżąco, inne potrzebują ciszy podczas korzystania z czytnika ekranu. Uzgodnijcie sposób rozmowy przed zadaniem i dostosujcie go w trakcie spotkania. Jeżeli trzeba zadać pytanie, wybierzcie moment, który nie przerywa istotnego komunikatu lub koncentracji uczestnika.

Po zadaniu zapytajcie o wrażenia i znaczenie napotkanych komunikatów. Unikajcie sugerowania odpowiedzi w rodzaju „ten przycisk był chyba niewidoczny?”. Lepiej poprosić o opis miejsca, w którym osoba spodziewała się znaleźć działanie, oraz o informację, co pomogłoby jej kontynuować. Nie każda propozycja uczestnika musi od razu stać się projektem rozwiązania, ale powinna zostać uczciwie zapisana.

Przy pracy z danymi z badania ustalcie, kto może otworzyć nagranie lub notatki oraz jak długo są potrzebne. Do opisu problemu technicznego nie zawsze potrzebne są dane identyfikujące uczestnika. Zakres przechowywania i dostęp powinny wynikać z celu badania oraz ustaleń przekazanych przed spotkaniem.

Połącz obserwacje z oceną wymagań

Badanie z ludźmi pozwala zobaczyć przebieg zadania i poznać różne strategie korzystania z aplikacji. Nie daje podstaw do stwierdzenia, że cała aplikacja spełnia każdy wymóg dostępności. Potrzebna jest również ocena właściwego zakresu względem odpowiednich kryteriów oraz testy techniczne. W3C wskazuje na wartość łączenia tych podejść.

Materiały W3C dotyczące WCAG pomagają znaleźć kryteria i techniki związane z dostępnością. Zespół powinien ustalić wymagania właściwe dla produktu i organizacji oraz sprawdzić je w rzeczywistym interfejsie. Sam zielony wynik automatycznego narzędzia nie oznacza, że każda osoba wykona każde zadanie bez przeszkód.

Przy dokumentowaniu problemu zapiszcie ekran, warunki próby, kroki oraz skutek dla uczestnika. Jeśli to możliwe, wskażcie również odpowiednie kryterium i proponowaną drogę sprawdzenia poprawki. Nie trzeba ujawniać danych osoby, aby zespół zrozumiał problem. Ważne, żeby programista lub projektant potrafił odtworzyć sytuację w uzgodnionym środowisku.

W artykule o kryteriach odbioru aplikacji opisujemy sposób przygotowania sprawdzalnych scenariuszy. Przy dostępności warto uzgodnić także, kto potwierdzi poprawkę i czy potrzebna będzie ponowna próba z użytkownikiem.

Ustal kolejność poprawek i wróć do uczestników

Po badaniu zespół może pogrupować uwagi według zadań i skutków. Problem uniemożliwiający wysłanie zgłoszenia wymaga innej reakcji niż niejasny opis, który użytkownik potrafił obejść. Priorytet powinien uwzględniać znaczenie funkcji, zakres użytkowników i dostępność obejścia. Warto wskazać właściciela poprawki oraz termin kolejnego przeglądu bez obiecywania czasu, którego zespół jeszcze nie ustalił.

Po zmianie sprawdźcie, czy poprawka rozwiązuje zgłoszony problem i nie utrudnia innych części ścieżki. Jeśli uczestnik zgodził się na dalszy kontakt, można uzgodnić ponowną próbę. Wynik należy opisać w granicach tego, co faktycznie sprawdzono: konkretnej wersji, zadań i użytych konfiguracji.

Przygotowując raport, rozróżnijcie problem występujący w samej aplikacji od trudności wynikającej z organizacji spotkania. Jeśli link do środowiska testowego nie działał, nie należy przypisywać tego automatycznie badanej funkcji. Jeśli z kolei uczestnik nie mógł znaleźć komunikatu po prawidłowym przesłaniu formularza, opis powinien prowadzić zespół do konkretnego miejsca w interfejsie.

Warto również sprawdzić, czy osoba może wrócić do rozpoczętego zadania po przerwie. Utrata wprowadzonych informacji może być szczególnie dotkliwa, gdy ich zapis wymagał wielu kroków. Przed próbą ustalcie bezpieczne dane testowe i oczekiwany rezultat. Po zakończeniu zapytajcie uczestnika, czy informacja o zapisanym stanie była zrozumiała oraz czy wiedział, jak kontynuować pracę.

Jeżeli badacie aplikację na kilku urządzeniach, zapiszcie użyte konfiguracje oraz różnice w przebiegu zadania. Wynik z jednego połączenia przeglądarki i technologii wspomagającej nie opisuje automatycznie wszystkich pozostałych. Taka informacja pomaga zaplanować kolejne próby i uniknąć zbyt szerokiego wniosku z ograniczonego badania.

Po ustaleniu poprawek poinformujcie osoby odpowiedzialne za produkt, jaki skutek ma każda przeszkoda i jak można sprawdzić zmianę. Warto zachować powiązanie między obserwacją, zadaniem i wersją aplikacji. Dzięki temu przy następnym wydaniu zespół będzie wiedział, czy ponownie sprawdza tę samą ścieżkę, czy już zmieniony proces.

Przed wyborem urządzeń do badania warto sprawdzić, jak odbiorcy korzystają z danej usługi w codziennej pracy. W artykule o aplikacji webowej, PWA i mobilnej opisujemy pytania o środowisko użytkownika i dostępny sprzęt.

W aplikacjach webowych i mobilnych dostępność warto uwzględnić od pierwszych decyzji projektowych. Badanie z użytkownikami pomaga zobaczyć, czy te decyzje działają podczas pracy i które przeszkody trzeba usunąć w kolejnej wersji.