W stronę dostępności

Piątek to koniec dnia pracy. Złe wieści zawsze nadchodzą w piątek na koniec dnia roboczego.

Zaraz wychodzisz z biura, właśnie przyszło pocztą nowe pismo o kolejnej reorganizacji.

Dziękuję xxxx, yyy od dzisiaj będziesz zgłaszał zzzz
...
Zespół Hugh zadba o to, aby nasze produkty były dostępne dla osób niepełnosprawnych.

O nie! Dlaczego na to zasłużyłem? Czy chcą, żebym odszedł? Nastaw się na niewdzięczną, ciężką pracę i naprawianie błędów innych. To na pewno porażka...

Taka była dostępność kilka lat temu. Niektórym biednym duszom powierzono zadanie „oczyszczenia” interfejsu użytkownika, aby spróbować udostępnić go osobom niepełnosprawnym.

To, co to właściwie oznaczało, było dość niejasne - prawdopodobnie gdybyś mógł zobaczyć wskaźnik skupienia i tabulatory przechodzące przez pola, mieć tekst alternatywny i kilka opisów pól, można by uznać, że Twoja aplikacja jest dostępna...

Ale nagle „robaki” zaczęły się mnożyć z prędkością lawiny.

Różne czytniki ekranu (Inż. Czytniki ekranu) i przeglądarki zachowywały się zupełnie inaczej.

Użytkownicy skarżyli się, że aplikacja jest bezużyteczna.

Gdy tylko błąd został naprawiony w jednym miejscu, pojawiał się kolejny w innym.

A zwykła zmiana i poprawienie błędów interfejsu użytkownika wymagała herkulesowego wysiłku.

Byłem tam. Przeżyłem, ale nie „udało nam się” – technicznie sporo poprawiliśmy, dodaliśmy wiele opisów pól, ról i osiągnęliśmy pewien poziom zgodności, ale nikt nie był zadowolony. Użytkownicy w dalszym ciągu narzekali, że nie mogą poruszać się po aplikacji. Menedżer nadal narzekał na ciągły strumień błędów. Inżynierowie skarżyli się, że problem został postawiony nieprawidłowo i nie było jasno określonego „poprawnego” rozwiązania, które sprawdziłoby się we wszystkich przypadkach.

Na mojej drodze do zrozumienia dostępności było kilka momentów, które zdecydowanie otworzyły mi oczy.
Być może pierwszą z nich było uświadomienie sobie, że dodanie funkcji dostępności do gotowego produktu jest trudne. A jeszcze trudniej przekonać menedżerów, że jest to niezwykle trudne! Nie, nie wystarczy „dodać kilka tagów”, a interfejs użytkownika będzie działał dobrze. Nie, tego nie da się zrobić w trzy tygodnie, nawet trzy miesiące nie wystarczą.
Następna chwila prawdy nadeszła, gdy na własne oczy zobaczyłam, jak niewidomi użytkownicy faktycznie korzystają z naszej aplikacji. To zupełnie co innego niż przeglądanie komunikatów o błędach.

Będę do tego wracać wielokrotnie, ale prawie wszystkie nasze „założenia” dotyczące sposobu, w jaki ludzie korzystają z naszej aplikacji, były błędne.

Poruszanie się po złożonym interfejsie użytkownika za pomocą naciśnięć klawiszy Tab/Shift+Tab – to jest do bani! Potrzebujemy czegoś lepszego. Skróty klawiaturowe, nagłówki.

Utrata ostrości podczas zmiany interfejsu użytkownika nie jest dużym problemem, prawda? Zastanówmy się jeszcze raz – jest to niezwykle mylące.

Kontynuowałem, przez jakiś czas pracowałem nad różnymi projektami, a następnie rozpoczęliśmy nowy projekt ze złożonym interfejsem użytkownika i przejrzystą instalacją, aby w końcu tym razem uzyskać odpowiednią dostępność.

Cofnęliśmy się więc o krok i przyjrzeliśmy się, jak moglibyśmy wdrożyć to inaczej i odnieść sukces, a jednocześnie sprawić, że proces będzie mniej nudny!

Dość szybko doszliśmy do kilku wniosków:

1. Nie chcieliśmy, żeby ludzie tworzący interfejs użytkownika bawili się etykietami/rolami arii i oczywiście strukturą HTML komponentów. Musieliśmy zapewnić im odpowiednie komponenty, które zapewnią dostępność od razu po wyjęciu z pudełka.
2. Dostępność == Łatwość obsługi – tj. To nie tylko wyzwanie techniczne. Musieliśmy zmienić cały proces projektowania i upewnić się, że dostępność została wzięta pod uwagę i omówiona przed rozpoczęciem projektowania interfejsu użytkownika. Należy wcześnie zastanowić się, w jaki sposób użytkownicy odkryją jakąkolwiek funkcjonalność, jak będą się poruszać i jak będzie działać kliknięcie prawym przyciskiem myszy na klawiaturze. Dostępność powinna być integralną częścią procesu projektowania – dla niektórych użytkowników to znacznie więcej niż tylko wygląd aplikacji.
3. Od samego początku zależało nam na uzyskaniu opinii od niewidomych i innych niepełnosprawnych użytkowników na temat łatwości obsługi aplikacji.
4. Potrzebowaliśmy naprawdę dobrych sposobów na wychwytywanie regresji dostępności.

Cóż, z inżynierskiego punktu widzenia, pierwsza część brzmiała całkiem zabawnie – opracowanie architektury i wdrożenie biblioteki komponentów. I rzeczywiście tak było.

Cofam się o krok, patrzę Przykłady ARII i myśląc o tym raczej jako o problemie projektowym niż o problemie „dopasowania”, wprowadziliśmy pewne abstrakcje. Komponent ma „Strukturę” (składa się z elementów HTML) i „Zachowanie” (sposób interakcji z użytkownikiem). Na przykład w poniższych fragmentach mamy prostą listę nieuporządkowaną. Dodając „zachowania”, do listy dodawane są odpowiednie role, dzięki czemu działa ona jak lista. To samo robimy z menu.

W rzeczywistości dodawane są tutaj nie tylko role, ale także procedury obsługi zdarzeń do nawigacji za pomocą klawiatury.

To wygląda bardziej schludnie. Gdybyśmy mogli uzyskać między nimi czystą separację, nie miałoby znaczenia, w jaki sposób struktura została utworzona, moglibyśmy zastosować do niej zachowania i zapewnić odpowiednią dostępność.

Można to zobaczyć w akcji pod adresem https://stardust-ui.github.io/react/ – Biblioteka UX React, który został zaprojektowany i wdrożony od początku z myślą o dostępności.

Część druga – zmiana podejścia i procesów wokół projektowania początkowo mnie przeraziła: próby przeforsowania zmian organizacyjnych przez skromnych inżynierów nie zawsze kończą się dobrze, ale okazało się, że był to jeden z najciekawszych obszarów, w którym wnieśliśmy znaczący wkład w proces . W skrócie nasz proces wyglądał następująco: nowa funkcjonalność była opracowywana przez jeden zespół, następnie nasz zespół kierowniczy przeglądał/powtarzał propozycję, a następnie, po zatwierdzeniu, projekt był zazwyczaj przekazywany zespołowi inżynieryjnemu. W tym przypadku zespół inżynierów faktycznie „był właścicielem” funkcjonalności dostępności, ponieważ do jego obowiązków należało naprawienie wszelkich problemów z nią związanych.

Na początku dość trudnym zadaniem było wyjaśnienie, że dostępność i użyteczność są ze sobą nierozerwalnie powiązane i że trzeba to zrobić na etapie projektowania, w przeciwnym razie doprowadziłoby to do dużych zmian i przedefiniowania niektórych ról. Jednak przy wsparciu kierownictwa i kluczowych graczy przyjęliśmy ten pomysł i wprowadziliśmy go w życie, tak aby projekty zostały przetestowane pod kątem dostępności i użyteczności, zanim zostały zaprezentowane kierownictwu.

Ta opinia była niezwykle cenna dla wszystkich — była fantastyczna jako ćwiczenie w dzieleniu się wiedzą/komunikacją na temat interakcji użytkowników z aplikacjami internetowymi. Zidentyfikowaliśmy wiele obszarów problematycznych w interfejsie użytkownika przed ich zbudowaniem, zespoły programistów w firmie mają teraz znacznie lepsze specyfikacje nie tylko wizualne, ale także behawioralne aspekty projektowania. Prawdziwe dyskusje to zabawne, pełne energii i pełne pasji dyskusje na temat aspektów technicznych i interakcji.

Moglibyśmy to zrobić jeszcze lepiej, gdybyśmy na tych (lub kolejnych) spotkaniach uczestniczyli niewidomi i niepełnosprawni użytkownicy – ​​było to trudne do zorganizowania, ale obecnie współpracujemy zarówno z lokalnymi organizacjami niewidomymi, jak i firmami, które zapewniają zewnętrzne testy w celu sprawdzenia przepływu realizacji na wczesnym etapie rozwoju — zarówno na poziomie przepływu komponentów, jak i wykonania.

Inżynierowie mają teraz dość szczegółowe specyfikacje, dostępne komponenty, których mogą użyć do wdrożenia, oraz sposób na sprawdzenie przepływu wykonania. Częścią tego, czego nauczyło nas doświadczenie, jest to, czego przez cały czas nam brakowało – tego, jak możemy zatrzymać regresję. Podobnie ludzie mogą używać testów integracyjnych lub kompleksowych do testowania funkcjonalności, których potrzebujemy do wykrywania zmian w interakcjach i przepływach wykonywania – zarówno wizualnych, jak i behawioralnych.

Określenie regresji wizualnej jest zadaniem dość zdefiniowanym, niewiele można do tego procesu dodać poza być może sprawdzeniem, czy fokus jest widoczny podczas nawigacji za pomocą klawiatury. Bardziej interesujące są dwie stosunkowo nowe technologie pracy z dostępnością.

1. Informacje o dostępności to zestaw narzędzi, które można uruchomić zarówno w przeglądarce, jak i w ramach cyklu kompilacji/testowania w celu identyfikacji problemów.
2. Sprawdzenie, czy czytniki ekranu działają poprawnie, było szczególnie trudnym zadaniem. Wraz z wprowadzeniem dostępu do Dostępność DOM, w końcu możemy wykonać migawki dostępności aplikacji, podobnie jak w przypadku testów wizualnych, i przetestować je pod kątem regresji.

Zatem w drugiej części historii przeszliśmy od edycji kodu HTML do pracy na wyższym poziomie abstrakcji, zmieniliśmy proces tworzenia projektu i wprowadziliśmy dokładne testowanie. Nowe procesy, nowe technologie i nowe poziomy abstrakcji całkowicie zmieniły krajobraz dostępności i znaczenie pracy w tej przestrzeni.
Ale to dopiero początek.

Kolejne „zrozumienie” jest takie, że niewidomi użytkownicy napędzają najnowocześniejsze technologie – to oni czerpią najwięcej nie tylko ze zmian, które opisaliśmy wcześniej, ale także z tego, że dzięki ML/AI możliwe jest nowe podejście i pomysły. Na przykład technologia Immersive Reader umożliwia użytkownikom łatwiejsze i wyraźniejsze prezentowanie tekstu. Można go czytać na głos, struktura zdań jest rozkładana gramatycznie, a nawet znaczenia słów są wyświetlane graficznie. To w ogóle nie pasuje do starej mentalności „uczyń to dostępnym” – to funkcja użyteczności, która pomoże każdemu.

ML/AI umożliwia zupełnie nowe sposoby interakcji i pracy, dlatego cieszymy się, że możemy być częścią kolejnych etapów tej nowatorskiej podróży. Innowacje napędzane są zmianą myślenia – ludzkość istnieje od tysiącleci, maszyny od setek lat, strony internetowe od kilkudziesięciu lat, a smartfony jeszcze mniej, technologia musi dostosowywać się do ludzi, a nie odwrotnie.

PS Artykuł został przetłumaczony z niewielkimi odchyleniami od oryginału. Jako współautor tego artykułu zgodziłem się na te dygresje z Hugh.

W ankiecie mogą brać udział tylko zarejestrowani użytkownicy. Zaloguj się, Proszę.

Czy zwracasz uwagę na dostępność swoich aplikacji?

• Tak

• Nie

• Pierwszy raz słyszę o dostępności aplikacji.

Głosowało 17 użytkowników. 5 użytkowników wstrzymało się od głosu.

Źródło: www.habr.com