Czy Twoja aplikacja stworzona przez AI jest dostępna dla każdego? Prosty przewodnik po dostępności
Dostępność aplikacji oznacza, że każdy — osoba powiększająca ekran, dotykająca jednym kciukiem czy niewidząca różnicy między czerwonym a zielonym — może faktycznie z niej korzystać, nie tylko Ty. Trzy szybkie testy ujawniają większość luk — powiększenie, kolor i czytnik ekranu.
Kiedy budujesz aplikację z AI, testujesz ją tak, jak sam jej używasz: na swoim ekranie, swoimi oczami, pewnym, dwuręcznym chwytem na laptopie. Problem w tym, że spora część osób, które otworzą Twoją aplikację, nie korzysta z niej w ten sposób. Ktoś powiększa tekst na telefonie do dwukrotności normalnego rozmiaru. Ktoś nie odróżnia Twojego czerwonego komunikatu o błędzie od czarnego tekstu wokół niego. Ktoś trzyma dziecko na rękach i stuka jednym kciukiem. Dostępność aplikacji to po prostu pytanie, czy te osoby wciąż mogą przez nią przejść — a to pytanie, którego większość aplikacji stworzonych przez AI nigdy nie otrzymuje.
Nie potrzebujesz do tego dyplomu ani zespołu ds. zgodności. Musisz wiedzieć, w których czterech czy pięciu miejscach aplikacje zwykle wykluczają ludzi, i jak poprosić swój builder o naprawę. Pokażę Ci te najczęstsze na przykładach — łatwiej je dostrzec, gdy raz się je zobaczyło.
Dlaczego układ mojej aplikacji się psuje, gdy ktoś powiększa ekran?
Ponieważ większość aplikacji stworzonych przez AI jest zaprojektowana z myślą o jednym, stałym rozmiarze tekstu — więc gdy ktoś powiększa tekst w telefonie czy przeglądarce (a robi to wiele osób, zwłaszcza po sześćdziesiątce), przyciski zaczynają na siebie zachodzić, kolumny zapadają się w poplątany stos, a elementy sterujące wsuwają się jeden pod drugi.
Znajoma twórczyni zbudowała schludną aplikację do umawiania wizyt dla salonu fryzjerskiego swojej mamy. Wyglądała świetnie. Potem mama ją otworzyła i pierwsze, co zrobiła — jak wiele osób po sześćdziesiątce — to powiększyła tekst gestem uszczypnięcia. Układ się rozpadł. Przyciski zaczęły na siebie zachodzić, przycisk „Zarezerwuj” wsunął się pod menu, a kolumna godzin zamieniła się w poplątany stos, którego nie dało się odczytać.
To najczęstszy błąd dostępności w aplikacjach stworzonych przez AI — i jest niewidoczny, dopóki ktoś nie powiększy ekranu. Poproś swój builder: „Upewnij się, że układ nadal działa, gdy tekst jest powiększony do 200%. Nic nie powinno na siebie zachodzić ani się obcinać”. Potem przetestuj to sam — na telefonie zwiększ rozmiar systemowej czcionki do maksimum i otwórz swoją aplikację. Jeśli się rozpada, to Twoja pierwsza poprawka.
Dlaczego moja aplikacja nie powinna pokazywać statusu wyłącznie za pomocą koloru?
Ponieważ mniej więcej co dwunasty mężczyzna widzi kolory inaczej niż większość — najczęściej czerwony i zielony — więc status pokazany wyłącznie jako czerwona lub zielona kropka wygląda dla nich tak samo, i naprawdę nie potrafią odróżnić „opłacone” od „zaległe”.
Freelancer zbudował narzędzie do śledzenia faktur, które pokazywało status wyłącznie za pomocą koloru — zielona kropka, czerwona kropka. Jeden z jego klientów, który akurat nie odróżniał czerwieni od zieleni, wciąż płacił faktury, które już były opłacone, bo obie kropki wyglądały dla niego identycznie. Informacja była dostępna. Po prostu nie dla niego.
Rozwiązaniem jest nawyk, nie funkcja: nigdy nie używaj koloru jako jedynego sposobu przekazania czegoś. Dodaj obok niego słowo, ikonę albo kształt. „Zaległe” obok czerwieni. Ptaszek obok zieleni. Gwiazdka i słowo „wymagane”, a nie tylko czerwona obwódka. Kolor może zostać — po prostu nie może sam dźwigać całego przekazu.
Dlaczego czytnik ekranu mówi po prostu „przycisk” zamiast go nazwać?
Ponieważ nieopisany przycisk-ikona — kosz na śmieci, ołówek, lupa bez żadnych słów — nie ma tekstu, który czytnik ekranu (oprogramowanie, którego osoby niewidome i słabowidzące używają do odczytywania ekranu na głos) mógłby ogłosić, więc odczytuje dosłownie: „przycisk”. Nie „usuń”. Nie „edytuj”. Po prostu „przycisk”.
Buildery oparte na AI uwielbiają czyste przyciski-ikony, bo wyglądają nowocześnie. Ale wyobraź sobie aplikację, w której każdy element sterujący nazywa się „przycisk” i musisz zgadywać. Nie musisz dodawać widocznego tekstu do każdej ikony — musisz upewnić się, że każdy element ma nazwę pod spodem, nawet niewidoczną, którą czytnik ekranu może ogłosić. Poproś swój builder: „Nadaj każdemu przyciskowi-ikonie dostępną etykietę — ikona kosza powinna być odczytywana jako »Usuń«, a ołówek jako »Edytuj«”. To drobna zmiana, a jednak stanowi różnicę między aplikacją, po której osoba niewidoma może się poruszać, a ścianą anonimowych przycisków.
Jak duże powinny być obszary dotykowe w aplikacji mobilnej?
Ogólna zasada, którą kierują się projektanci, mówi, że każdy element dotykowy powinien mieć około 44 pikseli — mniej więcej rozmiar opuszka palca — z realnym odstępem, żeby dwa dotykowe elementy nie stykały się krawędziami.
Popatrz, jak ktoś korzysta z Twojej aplikacji jedną ręką w autobusie. Kciuki są szerokie i niedokładne, autobus się trzęsie, a Twój „X” zamykający okno to 16-pikselowa kropka w rogu. Chybia dwa razy, raz trafia w coś innego, i się poddaje. Małe, stłoczone obszary dotykowe to problem dostępności, nie tylko irytacja — najbardziej uderzają w osoby z drżeniem rąk, większymi palcami albo w ruchomym otoczeniu. Poproś swój builder: „Zrób obszary dotykowe o wielkości co najmniej 44 pikseli i dodaj między nimi odstępy, żeby ludzie nie trafiali w niewłaściwy element”. Potem przetestuj: otwórz aplikację na telefonie i spróbuj wykonać główną akcję jedną ręką, chodząc. Jeśli sam ciągle chybiasz, inni też będą.
Jak przetestować dostępność mojej aplikacji w pięć minut?
Większość z tego możesz sprawdzić sam, bez żadnych narzędzi — wystarczą trzy szybkie testy na ekranie, z którego ludzie korzystają najczęściej:
- Powiększ go. Zwiększ tekst w telefonie lub przeglądarce do maksymalnego rozmiaru i otwórz główny ekran. Czy coś na siebie zachodzi, znika albo się obcina?
- Odbierz kolor. Przyjrzyj się każdemu miejscu, w którym aplikacja używa koloru, by coś oznaczać — status, błędy, pola wymagane. Jeśli wyobrazisz sobie to wszystko w szarości, czy nadal wiesz, co się dzieje? Jeśli nie, dodaj słowo albo ikonę.
- Włącz czytnik ekranu na dwie minuty. Zarówno iPhone (VoiceOver), jak i Android (TalkBack) mają wbudowany. Włącz go, zamknij oczy i spróbuj zrobić to, do czego służy Twoja aplikacja. Od razu usłyszysz, które przyciski są bezimienne.
Nic z tego nie wymaga bycia programistą. Wymaga tylko, żebyś na pięć minut przestał testować jako Ty sam, a zaczął testować jako ktoś, czyje ręce, oczy albo ekran różnią się od Twoich.
Nie musisz naprawić wszystkiego naraz. Wybierz jeden ekran, z którego ludzie korzystają najczęściej — formularz rezerwacji, rejestrację, główną listę — i spraw, żeby działał, gdy jest powiększony, pozbawiony koloru i odczytywany na głos. Ten jeden dobrze zrobiony ekran obejmie więcej osób niż cały audyt dostępności zakamarków, do których nikt nie zagląda. Zacznij od tego, a następna osoba, która otworzy Twoją aplikację jednym kciukiem i powiększonym ekranem, będzie mogła być użytkownikiem, a nie kimś, kto od razu wyjdzie.