OXARI to system ITSM do zarządzania usługami IT: zgłoszenia, zasoby, zależności. Zbadaliśmy dostępność tego narzędzia pracy. W takich systemach bariera rzadko jest na stronie marketingowej. Siedzi w widokach, w których specjalista spędza cały dzień.
Wyzwanie
Service desk żyje z tabel, filtrów, kart zgłoszeń i akcji zebranych na jednym ekranie. Jeśli fokus gubi się między setką kontrolek albo nazwa przycisku nic nie mówi poza ikoną, osoba korzystająca z klawiatury lub czytnika ekranu nie obsłuży kolejki. To nie jest błąd „na stronie głównej”. To błąd w narzędziu, od którego zależy praca zespołu.
Zakres i metoda
- Złożone widoki aplikacji webowej, nie tylko ekran powitalny.
- Interakcje, które w ITSM powtarzają się setki razy: otwarcie zgłoszenia, zmiana statusu, filtr listy.
- Badanie zgodności z WCAG.
Nie mieszamy tego badania z audytem bezpieczeństwa OXARI, o którym firma pisze osobno. Tutaj chodzi o to, czy z interfejsu da się skorzystać.
Co pokazało badanie
W gęstym interfejsie automatyczna lista błędów nie wystarcza. Trzeba przejść stany: lista zamknięta, lista po filtrze, karta zgłoszenia, okno akcji. Dopiero wtedy widać, czy nazwy kontrolek i kolejność fokusu wytrzymują prawdziwą pracę, a nie tylko pierwszy ekran po zalogowaniu.
Jednorazowy skan strony logowania nic nie mówi o kolejce zgłoszeń. Błąd, który wychodzi po ustawieniu filtra albo po otwarciu karty, na pierwszym ekranie w ogóle nie istnieje. Dlatego stan widoku jest częścią badania, nie dodatkiem.
Wojciech Waluś, programista i tester dostępności
Efekt
Zespół OXARI dostał raport z opisem problemów i rekomendacjami. Taki dokument da się przełożyć na poprawki w komponentach, z których składa się wiele widoków naraz, a nie na jednorazowe łatanie pojedynczego ekranu.
Powiązane: czego automat nie sprawdzi.
Masz aplikację, w której ludzie pracują cały dzień? Trop Audyt obejmuje do 15 widoków i 3 ścieżki.
Drużyna Dostępności