6 rzeczy, które nie zrobią z Ciebie audytora dostępności

Poleganie tylko na checklistach

Listy kontrolne są dobre na start, ale nie na dłuższą metę.

Przykład. Jeden z menadżerów testów nie obeznany jeszcze wtedy z dostępnością, zapytał mnie kiedyś: „Słuchaj, mamy gdzieś jakąś checklistę jak to (czyt. dostępność) sprawdzać?”

Odpowiedziałem mu wtedy: Słuchaj, tak mamy i to nawet kilka, ale są one tylko pewną ściągą/wyznacznikiem kierunku, w którym należy iść, a nie kompletną bazą wiedzy, jak należy to przetestować.

Jeżeli chcesz mieć „jakąś” checklistę, to stwórz swoją własną, gdzie będziesz miał/a własne procedury i dobrze opisane punkty. Możesz też użyć heurystyk od Stefana Wajdy.

Jeśli nadal chcesz skorzystać z mniej sformalizowanych gotowców, to zebrałem ich sporą listę w artykule Checklisty dostępności / accessibility checkilist. Używaj do woli, ale uważaj, aby nie wpaść na minę w postaci niedotestowanych wymagań.

Poleganie tylko na narzędziach i automatyzacji

Nawet narzędzia wolne od błędów typu false positive, nie dadzą Ci całościowego obrazu dostępności.

Audyt bazujący tylko na narzędziach jest audytem niepełnym i niedokładnym. Właściwie nie powinien się nazwać audytem. Bliżej mu do testów atomowych z nowej wersji WC Silver Accessibility

Poza tym każde narzędzie ma swoje ograniczenia, o których audytor powinien wiedzieć, co może nimi sprawdzić, a czego nie.

Poleganie tylko na wykrywaniu błędów (bug hunting)

„Zgłosiliśmy x błędów i wiemy, że strona jest niedostępna”.

Znów ilość błędów nie oznacza od razu, że strona nie jest dostępna.

Owszem duża liczba błędów może świadczyć, o potencjalnie mało dostępnej witrynie lub aplikacji, ale to nie oznacza od razu, że znalezione tam błędy sprawiają, że nagle aplikacja nie jest używalna przez osoby niepełnosprawne. Możliwe, że jest mniej użyteczna lub niedostępna dla określonej grupy osób.

Przykład. Spotkałem się z sytuacją u jednego z menadżerów, że jakiś element na stronie nie był dostępny pod czytnikiem ekranowym. W raporcie błąd zduplikowano 3 razy i przypisano mu wysoki priorytet, gdyż występuje pod trzema czytnikami więc 3 razy się powtarza. Po co było duplikować błąd kilka razy…? Nie wiem, skoro wystąpił na jednym z czytników, to z dużym prawdopodobieństwem wystąpi także na pozostałych. Zamiast zwiększyć priorytet błędu, najprawdopodobniej dla wywołania poczucia „jak bardzo lipna jest Wasza aplikacja pod kątem dostępności”, zduplikowano ten sam błąd 2 razy.

Analizując wyniki z audytu lub po prostu opisując poziom dostępności patrz na to:

• Jaki priorytet mają te błędy?
• Czy są zawsze powtarzalne czy występują tylko w jednym miejscu lub w jednym narzędziu?
• Czy są to błędy reprodukowane na jednej przeglądarce czy może na wielu?
• Ilu wymagań WCAG ten błąd dotyczy? (Czasami jeden błąd łamie kilka kryteriów)

Przykład. Podczas wykonywania jednego z audytów, tylko do jednego z wymagań WCAG zgłosiłem 5 błędów, który występowały na wszystkich testowanych podstronach. Czy to oznacza, że te 5 błędów mają zaraz podważać dostępność całego serwisu?

Obniżać owszem, ale podważać… no niekoniecznie.

Trzymanie klienta za ogon

Zadaj sobie pytanie: Czy jesteś dla klienta partnerem i traktujecie się jak partnerzy czy jesteś dla niego tylko siłą roboczą, która ma jak najszybciej wykonać swoje zadanie.

Czy Wasza współpraca opiera się na wspólnym zrozumieniu i słuchaniu siebie nawzajem, czy klient wyłącznie narzuca Ci swoje "ale"?

Ważna jest polemika i konsultacje jak coś zrobić optymalnie, a nawet dobrze, a nie na zasadzie „nie, bo nie” i koniec argumentów. Ostatecznie jeśli klient lub właściciel produktu zadecyduje o wdrożeniu produktu niedostępnego, to ma Ci dać jasne i jawne potwierdzenie, że rezygnuje z twojej rekomendacji.

Musi być świadomy, że kiedy swoją decyzją w jakiś sposób odrzuca twój wysiłek, to jego produkt będzie niedostępny - czasami łamiąc nawet prawo, gromadzi przy tym kolejny dług technologiczny, a to w przyszłości na pewno będzie mieć swoje konsekwencje.

A ty... trzymasz klienta za ogon, czy podajecie sobie ręce?

Poleganie tylko na specyfikacji

Sprawdzasz stronę/aplikację z WCAG. Super! A co z weryfikacją designu i user experience?

Prawdziwy dostępnościowiec wykona także:

• weryfikację designu
• weryfikację użyteczności
• weryfikację czytelności

I to wszystko w połączeniu z przyzwyczajeniami użytkowników. Podkreślam słowo użytkowników, a nie właścicieli produktu, którzy często mają widzimisię dalekie od dostępnego produktu. Różnica między prawdziwym dostępnościowcem, a zwykłym testerem dostępności jest jeszcze taka, że często będziesz w konflikcie z przyzwyczajeniami/wizją klienta, marketingu, UX-a, a nawet dewelopera, który nie zna się na dostępności i nie powinieneś/aś bezkrytycznie akceptować ich postawy, albo stwierdzenia: „bo klient tak chce, za to zapłacił i kropka”.

Testerzy też mają problem z dostępnością, gdyżą często sztywno trzymają się wymagań i jak czegoś nie ma w specyfikacji, to oni się nie będą tym zajmować. To odpowiedzcie sobie teraz na pytanie: Po co robiliście kurs i certyfikat ISTQB? Chyba po to, żeby znać podstawy testowania i wiedzieć jak coś przetestować i robić to dobrze. Wyjść z pudełka i mieć oko na całość, projektu, a nie tylko mały kawałeczek podłogi. Nie wiedzieć, dlaczego nie chcecie poznać jak nauczyć się testować dostępność, z czego de facto też możecie otrzymać certyfikat, co za tym idzie pogłębić Wasze kompetencje i otworzyć sobie drogę na zachodnie rynki pracy.

Poleganie tylko na AI

Ludziom prowadzącym projekty, nie chce się bawić w audyty lub(i) płacić za godziny specjalistom od dostępności. Z jednej strony ja to rozumiem, ale z drugiej to niektórzy traktują osoby od dostępności, jak jakieś dziwolągi, które gdzieś nagle wychodzą pod koniec dewelopmentu i wywracają stolik do góry nogami. Niestety nie wiem, dlaczego wolą, aby problemy dostępności były rozwiązywane przez algorytmy zamiast ludzi.

Problemy, które sami popełnili lub pod ich nadzorem zrobili ich pracownicy i teraz gdy gów...no zaczęło śmierdzieć, chcą na szybko poprawić je łatką o nazwie AI.

Przykład Obecny hype na AI i rozmowy, które przeprowadzałem z niektórymi ludźmi budującymi procesy wytwórcze, dają do myślenia, że chcieli by mieć człowieka od dostępności, który raczej kontrolowałby w jakiś sposób AI, aby ta dbała o dostępność za nas.

Zanim położysz wszystko na szalę AI, sprawdź czy aby się nie przeliczysz:

• AI nie jest nieomylna i często halucynuje, co sprawia, że trzeba po niej coś poprawiać, a nawet posprzątać. Pisałem o tym w wypowiedzi: Dlaczego nie warto ufać SI w kwestii dostępności.
• AI nie zapewni wszystkich wymagań WCAG i nie sprawi, że błędy nagle same znikną. Ktoś będzie musiał do nich siąść i je poprawić, więc i tak trzeba się będzie tego nauczyć.
• Powoli inwestycje w AI zaczynają być kwestionowane w USA² i choć bańka jest wciąż pompowana pieniędzmi, to nie wiadomo jako to się skończy. Być może w niektórych dziedzinach, kompletnie nie będzie opłacalna.
• Nie ma jednolitego ogólnoświatowego standardu stosowania AI. Na przykład w UE choć jeszcze nie wdrożony już istnieje akt prawny postulujący, która AI jest etyczna, a której nie wolno / nie powinno się używać czy choćby opisuje zagrożenia ze strony używania AI w sposób niewłaściwy. Natomiast w innych krajach ta kwestia jest w powijakach. Zatem nigdy nie wiesz czy nie znajdziesz się na spornej ścieżce (może nawet sądowej), w której ktoś podważy działanie AI jako legalnego środka do zapewniania dostępności. No i co z certyfikatem Trusted Tester, który jest wymagany od ludzi w USA, podczas wykonywania audytów stron rządowych? Podobnie jest w UK, w ofertach pracy jasno się wymienia konieczność posiadania certyfikatów IAAP. Zatem od specjalistów ds. dostępności można, a nawet trzeba wymagać kwalifikacji, portfolio, certyfikatów, itp. Nawet jak ich nie mają, to generalnie wiemy, jak zweryfikować ludzkie umiejętności, chociażby w postaci przeprowadzenia miniaudytu. A czego należy wymagać od AI...?

Mój pro-tip: Jako audytor nie polegaj tylko na AI, bo nie wiedząc co dzieje się pod spodem, może Cię to wyprowadzić w pole.

Kwestionowanie

Tak na koniec zostawiłem coś co może nie tyle jest złą praktyką, ale sposób wyrażania tego owszem.

Krytykowanie innych. O patrzcie jaki to zły audyt zrobili Ci lub tamci... Ten audyt jest do bani i generalnie jest źle zrobiony. Taka postawa nie przynosi nic dobrego. Ludzie nie lubią, jak się ich punktuje za błędy.

Jeśli wydaje Ci się, że audyt nie został zrobiony poprawne, porównaj go do swojego i wykaż różnice przemawiające na Twoją korzyść - mówiąc np. językiem korzyści i przede wszystkim nie uważaj się za lepszego.

Za gorszego w sumie również, gdy ktoś wytknie Ci błędy tylko dlatego, że używał innych narzędzi lub innego zestawu podstron. Audyt robiony jest na próbkach i w innej próbce ktoś inny może znaleźć jakieś błędy.

Nie oznacza to od razu, że audyt był zrobiony źle, po prostu był robiony w pewnym obszarze, którego akurat inny audytor nie dotykał.

Problem też wynika z faktu, że audyty robione w Polsce nie są porównywalne, a właściwie ich wyniki.

Sam też byłem ździwiony, ale jeśli zestawisz audyt wykonany przez firmę x i y, to może się okazać, że w ogóle nie da się ich porównać. Poprawność opisania audytu ma ogromne znaczenie przy ocenie audytora. Niby mówią, żeby nie oceniać książki po okładce, ale to ostatecznie raport z audytu jest tym dokumentem, który trafia do wielu osób, które później zwyczajnie „wyrabiają” sobie o Tobie zdanie.

Nie daj się też zwieźć opinii projekt menadżera lub właściciela produktu, że przetestowana musi być każda strona i każda funkcjonalność i najlepiej w ciągu tygodnia lub dwóch, bo inaczej coś tam… Tu przytacza się przeróżne argumenty.

Krytykowanie Ciebie i twojej opinii jako specjalisty, tylko dlatego, że komuś się wydaje, że rozumie to lepiej od Ciebie.

Audytor ma być niezawisły. Każdy może mieć inne zdanie, ale nikt nie powinien kwestionować Twojej wiedzy i doświadczenia, jeżeli nie robił tego wcześniej i wydaje mu się, że rozumie problem zapewniania dostęności.

Podsumowując

W kwestii bycia dobrym audytorem nie jest wcale ważne, aby na swoim koncie było przeprowadzenie 100 audytów i wykazanie w nich nie wiadomo ilu błędów. Jak zawsze ważny jest zdrowy rozsądek i balansowanie między tym co konieczne, a tym co możemy zostawić na później. To „później” z reguły nigdy nie nadchodzi i na produkcję zazwyczaj wychodzi nie w pełni dostępny produkt. Ale czy ktoś widział w pełni dostępny lub bezbłędny produkt cyfrowy?

Mimo tego; nie warto iść na skróty w postaci ogólnikowych checklist, skupianiu się tylko na błędach lub samym standardzie WCAG, a także nie należy do końca polegać na przekonaniach innych wydawać by się mogło, bardziej doświadczonych osób.

Do rozwiązania wielu problemów z dostępnością wymagana jest tak naprawdę chęć i dialog, a nie od razu AI lub inne grube działa.