Piątek to koniec dnia roboczego. Złe wiadomości zawsze przychodzą w piątek pod koniec dnia roboczego.
Zamierzasz opuścić biuro, a tu „dźwięk” nowy e-mail w sprawie kolejnej reorganizacji właśnie dotarł.
Dziękuję xxxx, yyy od dzisiaj będziesz raportować zzzz.
…
I zespół Hugh zapewni dostępność naszych produktów dla osób z niepełnosprawnościami.
O nie! Za co zasłużyłem na to? Chcą, żebym odszedł? Nastaw się na niewdzięczną ciężką pracę i próbuj naprawić błędy innych ludzi. To na pewno będzie porażka...
Taka była dostępność kilka lat temu. Niektórzy nieszczęśnicy dostawali pracę polegającą na „oczyszczaniu” interfejsu użytkownika, aby spróbować uczynić go dostępnym dla osób z niepełnosprawnościami.
To, co to tak naprawdę oznaczało, było dość niejasne – prawdopodobnie, jeśli mogłeś zobaczyć wskaźnik fokusu i poruszać się po polach za pomocą klawisza tabulacji, mieć jakiś tekst alternatywny i kilka opisów pól, uznano by to za to, że twoja aplikacja jest dostępna...
Ale nagle „błędy” zaczęły mnożyć się jak lawina.
Różne ekranowe czytniki (ang. Screen Readers) i przeglądarki zachowywały się zupełnie inaczej.
Użytkownicy skarżyli się, że aplikacja nie nadaje się do użytku.
Gdy tylko błąd był naprawiany w jednym miejscu, pojawiał się inny w innym.
A po prostu zmiana i naprawianie błędów interfejsu użytkownika wymagało tytanicznych wysiłków.
Byłem tam. Przeżyłem, ale nie „odnieśliśmy sukcesu” – technicznie oczyściliśmy wiele, dodaliśmy wiele opisów pól, ról i osiągnęliśmy jakiś poziom zgodności z wymaganiami, ale nikt nie był zadowolony. Użytkownicy wciąż skarżyli się, że nie mogą się poruszać w aplikacji. Menedżer i tak narzekał na ciągły napływ błędów. Inżynierowie skarżyli się na niewłaściwe sformułowanie zadania, bez jasno określonego „właściwego” rozwiązania, które działałoby w każdych okolicznościach.
Na mojej drodze do zrozumienia dostępności napotykałem niektóre wyraźnie odkrywcze momenty.
Możliwe, że pierwszym krokiem było zrozumienie, że dodawanie funkcjonalności dostępności do gotowego produktu jest trudne. A jeszcze trudniej jest przekonać menedżerów, że jest to niezwykle skomplikowane! To nie polega tylko na dodaniu kilku znaczników, aby interfejs użytkownika działał doskonale. Nie, to niemożliwe zakończyć w trzy tygodnie, nawet trzy miesiące to za mało.
Mój kolejny moment prawdy nastał, gdy na własne oczy zobaczyłem, w jaki sposób niewidomi użytkownicy korzystają z naszej aplikacji. To TAK różni się od przeglądania komunikatów o błędach.
Będę do tego wracać wciąż i wciąż, ale prawie wszystkie nasze „założenia” dotyczące tego, jak ludzie korzystają z naszej aplikacji, były błędne.
Nawigacja po skomplikowanym interfejsie użytkownika przy użyciu klawiszy Tab/Shift+Tab – to fatalne! Potrzebujemy czegoś lepszego. Skróty klawiszowe, nagłówki.
Utrata fokusu przy zmianie UI to chyba nie duży problem? Pomyślmy jeszcze raz – to potwornie myli.
Kontynuowałem i przez jakiś czas pracowałem nad różnymi projektami, a następnie rozpoczęliśmy nowy projekt, ze skomplikowanym interfejsem użytkownika i wyraźnym zadaniem, aby tym razem zapewnić odpowiednią dostępność.
Zatem zrobiliśmy krok wstecz i zastanowiliśmy się, jak możemy to zrealizować inaczej i osiągnąć sukces, tak aby sam proces pracy był interesujący!
Dość szybko doszliśmy do kilku wniosków:
- Nie chcieliśmy, aby osoby opracowujące interfejs użytkownika zajmowały się oznaczeniami aria/rolami i oczywiście strukturą HTML komponentów. Musieliśmy zapewnić im odpowiednie komponenty, w których dostępność jest implementowana od razu.
- Dostępność == Użyteczność – czyli to nie tylko techniczne zadanie. Musieliśmy zmienić cały proces projektowania i upewnić się, że dostępność jest brana pod uwagę i omawiana przed rozpoczęciem projektowania interfejsu użytkownika. Należy z góry pomyśleć, jak użytkownicy mogą odkryć jakąkolwiek funkcjonalność, jak będą się poruszać i jak będzie działać „prawy przycisk myszy” z klawiatury. Dostępność powinna być integralną częścią procesu projektowania – dla niektórych użytkowników to coś znacznie więcej niż tylko wygląd aplikacji.
- Od samego początku chcieliśmy uzyskać opinie od osób niewidomych i innych użytkowników z ograniczeniami o prostocie korzystania z aplikacji.
- Potrzebowaliśmy naprawdę dobrych sposobów na wyłapywanie regresji dostępności.
Cóż, z inżynieryjnego punktu widzenia, pierwsza część brzmiała dość zabawnie – opracowywanie architektury i wdrażanie biblioteki komponentów. I rzeczywiście tak było.
Spoglądając wstecz, rozważając i myśląc o tym jak o problemie projektowym, a nie o problemie «dostosowania», wprowadziliśmy pewne abstrakcje. Komponent ma ‘Strukturę’ (składa się z elementów HTML) i ‘Zachowanie’ (jak oddziaływuje z użytkownikiem). Na przykład, w poniższych fragmentach mamy prostą, nieuporządkowaną listę. Po dodaniu „zachowania” do listy dodawane są odpowiednie role, aby działała jak lista. Podobnie robimy z menu.
Właściwie dodawane są tutaj nie tylko role, ale także obsługiwacze zdarzeń do nawigacji za pomocą klawiatury.
Wygląda to już znacznie lepiej. Gdybyśmy mogli uzyskać czyste rozdzielenie między nimi, nie byłoby ważne, jak została stworzona struktura, moglibyśmy zastosować do niej zachowania (Behaviours) i uzyskać odpowiednią dostępność.
W działaniu można to zobaczyć pod adresem – biblioteka UX , która jest projektowana i wdrażana z myślą o dostępności od samego początku.
Druga część – zmiana podejścia i procesów wokół projektowania początkowo mnie przerażała: skromni inżynierowie, próbujący wprowadzić zmiany organizacyjne, nie zawsze kończą się dobrze, ale okazało się to jedną z najbardziej interesujących dziedzin, w których wnieśliśmy znaczący wkład w proces. Krótko mówiąc, mieliśmy następujący proces: nowa funkcjonalność była rozwijana przez jeden zespół, następnie nasza grupa kierownicza analizowała/iterowała tę propozycję, a następnie, po zatwierdzeniu, zazwyczaj projekt był przekazywany zespołowi inżynierów. W tym przypadku zespół inżynierów faktycznie „właścicielem” funkcjonalności dostępności, ponieważ musiał rozwiązać wszystkie związane z tym problemy.
Na początku była to dość trudna praca – wyjaśnić, że dostępność i użyteczność są ze sobą nierozerwalnie związane i że trzeba to uwzględnić już na etapie projektowania, inaczej prowadziło to do dużych zmian i redefinicji niektórych ról. Niemniej jednak, przy wsparciu kierownictwa i kluczowych graczy, przekazaliśmy tę ideę i zaczęliśmy ją wprowadzać, aby projekty przechodziły kontrolę dostępności i użyteczności, zanim zostaną przedstawione kierownictwu.
Opinie te były niezwykle cenne dla wszystkich – to było fantastyczne, jako ćwiczenie w wymianie wiedzy/informacji na temat tego, jak użytkownicy wchodzą w interakcję z aplikacjami webowymi, identyfikowaliśmy liczne problemy interfejsu użytkownika, zanim zostały one zbudowane, zespoły deweloperskie mają obecnie znacznie lepsze specyfikacje nie tylko wizualnych, ale także behawioralnych aspektów projektu. Prawdziwe dyskusje to wesołe, energiczne, pasjonujące rozmowy na temat aspektów technicznych i interakcji.
Moglibyśmy wykonać tę pracę jeszcze lepiej, gdyby na tych (lub późniejszych) spotkaniach z nami byli niewidomi użytkownicy oraz osoby z niepełnosprawnościami – było to trudne do zorganizowania, ale teraz rzeczywiście współpracujemy zarówno z lokalnymi organizacjami dla niewidomych, jak i firmami, które oferują zewnętrzne testowanie w celu sprawdzenia przepływu realizacji na wczesnych etapach rozwoju – zarówno na poziomie komponentów, jak i na poziomie przepływu realizacji.
Teraz inżynierowie mają dość szczegółowe specyfikacje, dostępne komponenty, które mogą wykorzystać do wdrożenia, i sposób weryfikacji przepływu realizacji. Częściowo, doświadczenie nauczyło nas, czego ciągle pomijaliśmy – jak możemy zapobiegać regresji. Podobnie, ludzie mogą korzystać z testów integracyjnych lub end-to-end, aby sprawdzić funkcjonalności, które są nam potrzebne do wykrywania zmian w interakcjach i przepływach realizacji – zarówno wizualnych, jak i behawioralnych.
Definiowanie regresji wizualnej to dość określone zadanie, niewiele można dodać do tego procesu, z wyjątkiem może sprawdzenia, czy fokus jest widoczny podczas nawigacji za pomocą klawiatury. Bardziej interesujące są dwie stosunkowo nowe technologie dotyczące dostępności.
- to zestaw narzędzi, które mogą działać zarówno w przeglądarce, jak i w ramach cyklu kompilacji/testowania, w celu identyfikacji problemów.
- Sprawdzanie poprawności działania programów czytających z ekranu było szczególnie trudnym zadaniem. Wraz z wprowadzeniem dostępu do Accessibility DOM, w końcu uzyskaliśmy możliwość wykonywania zrzutów aplikacji z perspektywy dostępności, bardzo podobnych do tych, które wykonujemy dla testów wizualnych, i ich sprawdzania pod kątem regresji.
Zatem, w drugiej części historii – przeszliśmy od edytowania kodu HTML do pracy na wyższym poziomie abstrakcji, zmieniliśmy proces projektowania i wprowadziliśmy dokładne testowanie. Nowe procesy, nowe technologie i nowe poziomy abstrakcji całkowicie zmieniły wyobrażenie o dostępności i tym, co oznacza praca w tej dziedzinie.
Ale to dopiero początek.
Następne „zrozumienie” polega na tym, że niewidomi użytkownicy napędzają zaawansowane technologie – to oni czerpią największe korzyści nie tylko z zmian, które opisaliśmy wcześniej, ale także z tego, że nowe podejścia i pomysły stają się możliwe dzięki ML/AI. Na przykład technologia Immersive Reader umożliwia użytkownikom łatwiejsze i bardziej zrozumiałe przedstawianie tekstu. Może być czytana na głos, struktura zdania jest dzielona graficznie, a nawet znaczenia słów są wyświetlane graficznie. To całkowicie nie pasuje do starego rozumienia „uczynić to dostępnym” – to funkcjonalność użyteczności, która pomoże wszystkim.
Z ML/AI pojawiają się zupełnie nowe sposoby interakcji i pracy, i cieszymy się, że możemy być częścią następnych etapów tej nowatorskiej drogi. Innowacje są wynikiem zmiany myślenia – ludzkość istnieje od tysiącleci, maszyny od setek lat, strony internetowe kilka dziesiątek lat, a smartfony jeszcze krócej, technologia musi dostosować się do ludzi, a nie odwrotnie.
P.S. Artykuł został przetłumaczony z niewielkimi odchyleniami od oryginału. Jako współautor tego artykułu uzgodniłem te odchylenia z Hughem.
Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. , proszę.
Czy poświęcasz uwagę dostępności swoich aplikacji?
Tak
Nie
Po raz pierwszy słyszę o dostępności aplikacji
Głosowało 17 użytkowników. Wstrzymało się 5 użytkowników.
Źródło: habr.com
