AI ogłosiła, że strona jest dostępna. Czego jej raport w ogóle nie sprawdził?

Raport ma zielony nagłówek: „Nie znaleziono problemów z dostępnością”. Pod spodem znajduje się zrzut strony z przyciskiem „Zarezerwuj termin”. Narzędzie nie otworzyło formularza, nie wywołało błędu i nie sprawdziło okna potwierdzenia. Dalsza droga klienta do rezerwacji została poza tym zdjęciem grupowym.

To hipotetyczny raport, nie wynik przeprowadzonego tu skanu. Jego wada nie polega na tym, że narzędzie niczego nie znalazło. Problemem jest przypisanie szerokiego znaczenia wąskiej próbie. „Brak usterek wykrytych w odwiedzonym stanie” i „strona jest dostępna” wymagają różnych dowodów.

AI może pomagać w uruchamianiu sprawdzeń, porządkowaniu wyników i pisaniu raportu. Przy odbiorze ustal jednak, które czynności rzeczywiście wykonano, czego dotyczyły oraz jak powstał końcowy wniosek. Płynne uzasadnienie nie rozszerza zakresu testu.

Jeden adres, kilka odmiennych stanów

Przyjmijmy serwis rezerwacji napraw rowerów. Użytkownik wybiera rodzaj naprawy, termin i lokalizację. Po naciśnięciu przycisku otwiera się okno, a po wysłaniu niepełnego formularza pojawia się informacja o brakującym numerze telefonu. Żaden z tych kroków nie musi tworzyć nowego adresu strony. Lista sprawdzonych URL nie opisuje więc całej drogi.

Przed odczytem wyniku przygotuj krótką mapę stanów istotnych dla zadania. Dla naszego serwisu obejmuje ona wejście do rezerwacji, otwarte okno, wybór terminu, błąd formularza i potwierdzenie. Do każdego stanu dopisz sposób jego osiągnięcia. „Błąd formularza” bez wskazania, co wysłano, może prowadzić do innego komunikatu podczas powtarzania próby.

W zapisie próby oddziel na przykład: stronę po wejściu, okno wyboru terminu otwarte przyciskiem oraz to samo okno z komunikatem „wybierz termin”. Zachowaj odsyłacz do dowodu przy każdym stanie. Jeśli raport zawiera tylko zrzut strony początkowej, poproś o materiał z pozostałych. Trzy pozycje o tym samym adresie mogą tu nieść więcej informacji niż długa lista adresów, pod którymi sprawdzono wyłącznie podobne nagłówki.

Zapisz też warunki: rodzaj urządzenia lub rozmiar widoku, stan zalogowania i wybrany wariant usługi. Formularz dla firmy może zawierać pola nieobecne przy kliencie indywidualnym. Raport dotyczący jednej wersji nie powinien automatycznie obejmować drugiej. Nie trzeba badać każdej kombinacji bez końca; trzeba uzasadnić, które objęto zakresem i które pozostały do sprawdzenia.

Przy narzędziu samodzielnie przechodzącym stronę poproś o ślad wykonanej drogi. Lista kliknięć jest przydatna, ale sprawdź też, czy po działaniu rzeczywiście pojawił się oczekiwany stan. Przycisk może nie zadziałać, strona może ładować dane, a okno nie otworzyć się z powodu błędu. Skan uruchomiony w tym momencie oceni inny materiał niż planowano.

Szczególnie sprawdź widoki zależne od danych. Kalendarz podczas ładowania i kalendarz z dostępnymi terminami mogą zawierać inne elementy. Ustal, po czym wykonawca rozpoznaje gotowy stan, i zapisz tę przesłankę. Przy braku wolnych terminów pojawi się jeszcze inna treść. Jeśli taka sytuacja należy do zwykłego działania serwisu, powinna otrzymać własne miejsce w zakresie, a nie zostać pominięta jako przypadek, w którym „nic się nie wyświetla”.

Jeżeli część procesu wymaga danych testowych lub dostępu, uzgodnij je przed próbą. Brak możliwości wejścia do obszaru nie jest jego pomyślnym sprawdzeniem. W raporcie wpisz „nieobjęte — brak dostępu” i wskaż, jak uzupełnić kontrolę. To konkretna luka w zakresie, nie usterka dostępności tego obszaru.

Co narzędzie może powiedzieć o badanym stanie

W3C wyjaśnia, że narzędzia nie sprawdzają automatycznie wszystkich aspektów dostępności i potrzebny jest ludzki osąd. Materiał o wyborze narzędzi oceny dostępności opisuje je jako pomoc w ocenie. Obecność AI w procesie nie usuwa potrzeby wykazania, co faktycznie sprawdzono.

Oddziel skaner reguł od modelu opisującego jego wynik. Pierwszy może wskazać element i konkretną regułę, drugi formułuje wyjaśnienie lub zalecenie. Jeśli model sam ocenia zrzut ekranu, ma inny dostęp do informacji niż narzędzie analizujące strukturę dokumentu. Raport powinien nazywać metodę przy ustaleniu, zamiast podpisywać całość jednym ogólnym „audyt AI”.

Sprawdź, czy zalecenie dotyczy tego samego elementu co wynik. Model może poprawnie objaśnić problem etykiety pola, lecz przypisać go przyciskowi obok. Osoba wdrażająca potrzebuje wskazania miejsca, reguły i warunku odtworzenia. Ładny opis ogólnego znaczenia dostępności nie zastępuje tych trzech informacji.

Dokumentacja axe-core rozdziela między innymi wyniki incomplete, wymagające ręcznej weryfikacji, oraz inapplicable, gdy dla reguły nie znaleziono pasujących elementów. Definicje w opisie wyniku axe-core nie pozwalają traktować tych kategorii jak pomyślnego potwierdzenia. W raporcie zachowaj je osobno.

Poproś o wyjaśnienie pominiętych reguł i obszarów. Jeżeli z próby wyłączono osadzony kalendarz zewnętrznego dostawcy, wynik nie obejmuje całej rezerwacji. Powód wyłączenia może być uzasadniony technicznie, lecz klient nadal korzysta z tego kalendarza. W podsumowaniu wskaż jego właściciela i sposób dalszego sprawdzenia. Ta sama zasada dotyczy elementów celowo ukrytych podczas testu, aby uzyskać spokojniejszy ekran. Zmiana materiału badania zmienia zakres wniosku.

Jeżeli model streszcza surowy wynik, porównaj oba materiały. Czy pozycja „wymaga sprawdzenia” pozostała w podsumowaniu? Czy brak pasujących elementów nie zmienił się w „spełniono”? Czy błąd wykonania narzędzia nie został opisany jako brak błędów strony? Zmieniony ton raportu może ukryć właśnie to, co trzeba przekazać człowiekowi.

Automatyczny wynik bywa też mylnie poszerzany przez liczbę sprawdzeń. Sto uruchomionych reguł nie oznacza stu sprawdzonych ekranów ani stu wymagań potwierdzonych w całości. Ustal, co liczy wskaźnik w nagłówku. Jeśli wykonawca nie potrafi objaśnić mianownika, procent jest dekoracją z pozorem dokładności.

Rozróżnij także poziomy raportu. Ustalenie może dotyczyć jednego przycisku, całego otwartego okna albo przebiegu zadania przez kilka ekranów. Połączenie takich pozycji w jedną liczbę wymaga opisanej reguły. Dwa błędy tej samej etykiety nie zawsze oznaczają dwa różne problemy użytkownika, a jeden problem z powrotem do okna może blokować całą drogę. Priorytety powinny odnosić się do skutku, nie tylko liczby znaczników.

Czego nie potwierdzi samo zielone podsumowanie

Obecność tekstu przy elemencie nie dowodzi, że człowiek rozumie jego cel. W naszym formularzu przycisk „Dalej” może być poprawnie nazwany w kodzie, a nadal nie wyjaśniać, czy kolejny krok zatwierdzi rezerwację. Rozróżnij ustalenie techniczne od oceny sensu komunikatu w zadaniu.

Podobnie zdjęcie może mieć opis alternatywny, który nie odpowiada jego funkcji. Jeżeli pokazuje miejsce odbioru roweru, sam opis „budynek” niewiele wnosi. Do oceny potrzebny jest kontekst strony. Nie dopisuj z tego powodu automatycznie długiej historii obrazu; ustal, jaką informację ma przekazać użytkownikowi.

Przy obsłudze klawiaturą sprawdź drogę przez otwarte okno, wybór i zamknięcie. Sam odczyt strony w stanie początkowym nie potwierdzi, że aktywny element pozostaje widoczny w późniejszym kroku albo wraca we właściwe miejsce po zamknięciu okna. Te zadania trzeba rzeczywiście wykonać w uzgodnionej konfiguracji.

Zrzut ekranu nie zapisuje kolejności przejść klawiaturą. W dowodzie ręcznej próby wskaż czynności i to, co działo się po każdej z nich. „Trzy naciśnięcia Tab, potem Enter” ma znaczenie tylko wraz ze stanem początkowym i rozpoznawalnym celem. Przy ponowieniu inna liczba pól może zmienić kolejność. Zapisuj więc również nazwę elementu, do którego prowadziło działanie, aby dało się zrozumieć próbę po drobnej zmianie treści.

Przy zmianie kolejności pozycji sprawdź alternatywny sposób działania. Interfejs może ładnie reagować na przeciągnięcie myszą, a pozostawiać inne osoby bez możliwości osiągnięcia tego samego skutku. Osobno opisujemy przeciąganie elementów i alternatywę zmiany kolejności. Dla raportu zasadnicze pytanie brzmi: czy oba sposoby rzeczywiście znalazły się w próbie?

Wynik techniczny uzupełnia się także odpowiednio zaplanowanym badaniem z osobami używającymi technologii asystujących. Taka obserwacja pokazuje wykonanie zadania w określonej konfiguracji i z doświadczeniem konkretnego uczestnika. Nie zastępuje automatycznie całej oceny zgodności, lecz wnosi materiał, którego zielony nagłówek skanu nie dostarcza.

Zakres ręcznej próby, kryteria i kompetencje osoby wykonującej ustal osobno. Tekst o dostępności strony firmowej rozwija odbiór samych funkcji. Tutaj oceniamy wiarygodność raportu narzędzia: czy jego wniosek ma odpowiednią podstawę i czy nierozstrzygnięte kwestie są widoczne.

Od ustalenia do poprawki, którą da się odebrać

Usterkę opisuj przez warunki i skutek. „Po otwarciu okna rezerwacji nie mogę przejść klawiaturą do wyboru terminu” pozwala przygotować próbę naprawy. Samo „problem z nawigacją” jest za szerokie. Jeśli wynik pochodzi z konkretnej reguły narzędzia, zachowaj jej identyfikator oraz wskazanie elementu w badanej wersji.

Do raportu dołącz wersję strony, narzędzia i konfigurację. Gdy kolejnego dnia zmieni się formularz, wcześniejszy wynik pozostaje informacją o wcześniejszym stanie. Nie przypisuj go automatycznie nowemu wdrożeniu. Tak samo nie łącz wyników różnych wariantów interfejsu pod jedną datą bez opisania, czego dotyczą.

Poprawkę sprawdź w tym samym zadaniu, w którym ujawniono problem, a potem obejrzyj powiązane kroki. Dodanie przycisku zamknięcia może rozwiązać jedną trudność i pozostawić niejasny powrót do formularza. Odbiór powinien pokazać efekt dla osoby wykonującej czynność, zamiast ograniczać się do zniknięcia pozycji z raportu.

Porównując raporty przed i po poprawce, sprawdź zgodność zakresu. Jeżeli drugi skan nie otworzył już okna, zniknięcie jego usterek nie potwierdza naprawy. Podobny problem powstaje, gdy po błędzie ładowania wyświetliła się uproszczona strona awaryjna. Najpierw potwierdź, że badano właściwy ekran i stan, dopiero potem porównuj wyniki reguł. Dzięki temu zmniejszenie liczby alarmów nie ukryje zmniejszenia liczby rzeczywiście sprawdzonych elementów.

Jeśli model proponuje fragment kodu, oddziel propozycję od wykonanej i przetestowanej zmiany. Nowy opis etykiety może pasować do przykładu, lecz nie do aktualnej funkcji przycisku. Poprawki przechodzą normalny odbiór wdrożenia. Pomocna jest tu checklista odbioru strony internetowej, zwłaszcza powiązanie poprawki z rzeczywistym przebiegiem zadania.

Gdy AI ocenia własną rekomendację, sprawdź podstawę tej drugiej oceny. Zdanie „po zmianie zgodność została zapewniona” nie jest zapisem ponownego testu. Problem niezależności takiego punktowania rozwija tekst o modelu AI jako sędzim. W tym przypadku wróć do konkretnego stanu strony i dowodu sprawdzenia.

W podsumowaniu mogą pozostać trzy uczciwe listy: potwierdzone usterki, sprawdzone właściwości w określonym zakresie i zadania wymagające dalszej pracy. Do każdej luki przypisz osobę oraz sposób jej uzupełnienia. Status „dalsze sprawdzenie” powinien prowadzić do konkretnego zadania, a nie znikać przy redagowaniu podsumowania.

Przegląd procesu raportowania i zasad użycia AI można omówić w Aeneia Audit. Przy zamknięciu pracy odpowiedź powinna brzmieć konkretnie: które stany i właściwości sprawdzono, co ustalono oraz czego nadal nie wiadomo. Zielony nagłówek może zostać, o ile przestanie mówić więcej niż dokument pod nim.