Sprawdzamy nie tylko stronę, ale to, czy użytkownik może rzeczywiście skorzystać z usługi.
Audyt może dotyczyć strony internetowej, sklepu, aplikacji, systemu, dokumentów albo konkretnego procesu, takiego jak zakup, rezerwacja czy złożenie formularza. Zakres badania dobieramy do funkcji rozwiązania i najważniejszych zadań użytkownika.
Łączymy analizę techniczną, testy praktyczne i ocenę treści. Wyniki przekładamy na konkretne problemy, priorytety i zalecenia dla zespołu odpowiedzialnego za produkt.
Co chcesz sprawdzić?
Nie każdy projekt potrzebuje takiego samego zakresu. Inaczej bada się stronę informacyjną, inaczej sklep internetowy, BIP, aplikację czy dokumenty. Dlatego audyt zaczynamy od ustalenia, co użytkownik powinien móc zrobić i które elementy mają największe znaczenie.
Audyt strony internetowej
Sprawdzamy serwisy informacyjne, strony firmowe, portale i serwisy instytucji. Analizujemy strukturę, nawigację, formularze, komponenty interaktywne, treści oraz współpracę z technologiami asystującymi.
Audyt sklepu internetowego
Badamy cały proces zakupowy: wyszukiwanie produktu, warianty, koszyk, formularze, dostawę, płatność, konto klienta i komunikaty. Nie ograniczamy się do pojedynczych podstron.
Audyt aplikacji i systemu
Sprawdzamy aplikacje webowe i mobilne, systemy rezerwacyjne, panele klienta, platformy usługowe i inne rozwiązania cyfrowe. Zakres audytu opieramy na kluczowych zadaniach użytkownika.
Audyt dokumentów
Analizujemy dokumenty PDF, Word i materiały biurowe pod kątem struktury, kolejności czytania, nagłówków, tabel, formularzy, opisów grafik i możliwości obsługi z technologiami asystującymi.
Audyt BIP
Sprawdzamy Biuletyn Informacji Publicznej zarówno jako serwis internetowy, jak i miejsce publikacji informacji publicznej. Analizujemy dostępność, strukturę, dokumenty, metryki i sposób publikacji treści.
Audyt przed odbiorem
Sprawdzamy stronę, sklep, aplikację lub system przed zakończeniem projektu i formalnym odbiorem. Dzięki temu bariery można usunąć jeszcze po stronie wykonawcy.
Co sprawdzamy podczas audytu?
Zakres zależy od rodzaju produktu, ale zwykle obejmuje kilka warstw jednocześnie. Sam wynik automatycznego skanera nie wystarcza do oceny rzeczywistej dostępności.
Struktura i kod
- semantyka HTML,
- nagłówki i regiony,
- role, nazwy i stany komponentów,
- formularze i etykiety,
- komunikaty dynamiczne.
Obsługa
- nawigacja klawiaturą,
- kolejność fokusu,
- widoczność fokusu,
- obsługa bez myszy,
- zachowanie na urządzeniach mobilnych.
Treść i komunikacja
- czytelność treści,
- teksty linków i przycisków,
- opisy alternatywne,
- komunikaty błędów,
- instrukcje i informacje dla użytkownika.
W zależności od projektu wykorzystujemy również technologie asystujące i testy praktyczne najważniejszych zadań użytkownika.
Audytujemy proces, nie tylko ekran
Można mieć poprawną stronę główną i jednocześnie niedostępny kluczowy proces. Dlatego w projektach sprzedażowych, usługowych i transakcyjnych sprawdzamy całe ścieżki użytkownika.
Przykładowe procesy
- zakup produktu,
- rezerwacja usługi,
- rejestracja konta,
- logowanie,
- złożenie formularza,
- płatność,
- pobranie dokumentu.
Dlaczego to ważne?
Pojedyncze komponenty mogą wyglądać poprawnie, a mimo to użytkownik nie będzie w stanie ukończyć całego zadania. Problem może pojawić się dopiero przy walidacji formularza, zmianie kroku, płatności albo obsłudze elementu dynamicznego.
Co otrzymujesz po audycie?
Raport ma pomóc w naprawie produktu. Nie ograniczamy się do podania numeru kryterium WCAG i informacji, że wystąpił błąd.
- opis problemu,
- miejsce występowania,
- sposób odtworzenia,
- wpływ na użytkownika,
- odniesienie do wymagania.
- rekomendowany sposób poprawy,
- priorytet wdrożenia,
- informacje dla programisty lub redaktora,
- materiał do przekazania wykonawcy,
- podsumowanie zakresu badania.
Retest po wprowadzeniu poprawek
Sam fakt, że problem został oznaczony jako poprawiony, nie oznacza jeszcze, że rzeczywiście zniknął. Zdarza się też, że naprawa jednego elementu powoduje nowy problem w innym miejscu.
Po wdrożeniu zmian możemy ponownie sprawdzić zgłoszone bariery i potwierdzić, które zostały usunięte, a które nadal wymagają pracy.
Kiedy warto zrobić audyt?
Przed wdrożeniem
Gdy produkt jest jeszcze w budowie, błędy często można poprawić szybciej i taniej niż po uruchomieniu.
Przed odbiorem
Jeżeli system wykonuje zewnętrzny dostawca, audyt może pomóc zweryfikować rezultat przed formalnym zakończeniem projektu.
Po zgłoszeniu problemów
Gdy użytkownicy zgłaszają bariery, audyt pozwala określić ich skalę i ustalić kolejność poprawek.
Nie wiesz, jaki zakres audytu wybrać?
Opisz stronę, sklep, aplikację, dokument albo proces, który chcesz sprawdzić. Na tej podstawie pomożemy ustalić sensowny zakres badania.
Nie każdy projekt potrzebuje pełnego audytu całego serwisu.