Redakcja testerzy.pl
Oliwia Selewoniuk
Aby to sprawdzić, przeprowadziliśmy audyt funkcjonalny narzędzia z perspektywy użytkownika niewidomego, korzystającego wyłącznie z klawiatury oraz czytnika ekranu NVDA. Poniższy raport, przygotowany przez naszą testerkę Oliwię, analizuje najważniejszą ścieżkę użytkownika – od logowania po proces raportowania defektu. Wyniki pokazują, że diabeł tkwi w szczegółach, a drobne niedociągnięcia w etykietowaniu mogą decydować o komforcie pracy z systemem. Zapraszamy do lektury pełnej analizy zgodnej z wytycznymi WCAG 2.1.
Audyt dostępności MantisBT
1. Informacje ogólne
Zakres audytu
Audyt obejmował sprawdzenie dostępności narzędzia MantisBT z perspektywy użytkownika niewidomego korzystającego z czytnika ekranu.
Obszar testów
Proces uwierzytelniania oraz ścieżka raportowania zgłoszeń w systemie MantisBT
Środowisko testowe
Sprzęt / System: Laptop, system operacyjny Windows.
Technologia asystująca: czytnik ekranu NVDA.
Nawigacja: obsługa wyłącznie z poziomu klawiatury.
Wersja testowana
Oficjalna wersja demo udostępniona do celów audytowych.
Perspektywa audytu
Audyt wykonano z perspektywy użytkownika niewidomego korzystającego z technologii asystującej.
Metoda badania
Badanie miało charakter funkcjonalny. Najważniejsze było sprawdzenie, czy użytkownik może samodzielnie wykonać kluczowe zadania:
- zalogować się,
- przejść proces rejestracji (założyć konto),
- skutecznie zgłosić defekt w MantisBT.
Skala ocen
1–5, gdzie:
- 1 – bardzo niska dostępność
- 5 – bardzo wysoka dostępność
2. Ocena obszaru logowanie i raportowanie defektów
Ocena ogólna: 4+/5
Opis i przebieg testu
Logowanie do MantisBT było proste i dostępne. Interfejs logowania nie zawierał zbędnych przycisków ani linków. Pola formularza były czytelne dla NVDA, a proces logowania przebiegł poprawnie.
Po zalogowaniu możliwe było odnalezienie funkcji dodania zgłoszenia. Funkcja znajdowała się wysoko na stronie, co ułatwiało jej znalezienie. Formularz zgłoszenia był dobrze obsługiwany z klawiatury. Kategorie, ważność, priorytet, temat, opis problemu, kroki do reprodukcji oraz dodatkowe informacje były możliwe do uzupełnienia.
Menu rozwijane reagowało poprawnie po aktywowaniu klawiszem Enter. Możliwe było także ustawienie zgłoszenia jako publicznego lub prywatnego. Wysłanie zgłoszenia również było dostępne.
Co działa poprawnie
Formularz zgłoszenia problemu jest czytelny i możliwy do samodzielnej obsługi z NVDA. Pola opisu problemu i kroków reprodukcji są dobrze dostępne. Można wybrać kategorię, priorytet i inne parametry zgłoszenia.
3. Zidentyfikowane defekty i podatności
Problem 1: Nieprecyzyjna etykieta „Dodaj”
Opis problemu
Element prowadzący do dodania zgłoszenia był opisany tylko jako „Dodaj”. Sama etykieta nie informowała jednoznacznie, że chodzi o dodanie zgłoszenia problemu.
Wpływ na użytkownika
Problem nie blokuje pracy, ale może chwilowo mylić użytkownika korzystającego z czytnika ekranu. Użytkownik słyszy „Dodaj”, ale nie wie od razu, co zostanie dodane.
Priorytet
Niski
Interpretacja i rekomendacja rozwiązania
Etykieta elementu powinna jasno wskazywać cel działania. Lepszą nazwą byłoby „Dodaj zgłoszenie” albo „Dodaj problem”. Obecna nazwa jest zbyt ogólna i wymaga od użytkownika domyślenia się funkcji elementu.
Odniesienia do WCAG 2.1
Zasada 2 Funkcjonalność
Wytyczna 2.4 Możliwość nawigacji
Kryterium sukcesu 2.4.6 Nagłówki i etykiety
Problem 2: Brak jednoznacznego komunikatu po wysłaniu zgłoszenia
Opis problemu
Po aktywowaniu przycisku wysłania zgłoszenia system nie przekazuje jednoznacznego komunikatu, że zgłoszenie zostało wysłane. Użytkownik domyśla się zakończenia procesu po tym, że pola formularza są puste. Dodatkowo sprawdza, czy zgłoszenie zostało wysłane wchodząc do listy wcześniej wysłanych zgłoszeń i patrząc, czy to nowe tam figuruje.
Wpływ na użytkownika
Problem nie blokuje wysłania zgłoszenia, ale powoduje niepewność. Użytkownik korzystający z czytnika ekranu nie otrzymuje jasnego potwierdzenia, że akcja została wykonana poprawnie. Może nie wiedzieć, czy zgłoszenie zostało zapisane, czy formularz został tylko wyczyszczony, czy wystąpił błąd.
Priorytet
Niski
Interpretacja i rekomendacja rozwiązania
Po wykonaniu ważnej akcji, takiej jak wysłanie zgłoszenia, użytkownik powinien otrzymać jasne potwierdzenie. Informacja o zapisaniu lub wysłaniu zgłoszenia powinna być odczytana przez NVDA bez konieczności domyślania się na podstawie pustych pól formularza albo ręcznego sprawdzania listy zgłoszeń.
Odniesienia do WCAG 2.1
Zasada 4 Kompatybilność
Wytyczna 4.1 Kompatybilność
Kryterium sukcesu 4.1.3 Komunikaty o stanie
4. Wnioski i podsumowanie
Większość elementów formularza raportowania w systemie MantisBT została zaprojektowana w sposób logiczny i dostępny dla technologii asystujących. Zidentyfikowane dwie podatności (nieprecyzyjna etykieta „Dodaj” oraz brak jednoznacznego komunikatu statusowego) nie stanowią barier krytycznych (blokujących). Wpływają one jednak negatywnie na komfort użytkowania aplikacji i mogą powodować u użytkowników dezorientację
Podsumowanie końcowe
Platforma MantisBT w testowanym obszarze w dużej mierze spełnia wymagania dostępności dla osób niewidomych korzystających z czytnika NVDA i nawigacji klawiaturowej, umożliwiając im w pełni samodzielną pracę z systemem.
