Nie ma ustalonego terminu, który obowiązywałby dla każdej aplikacji. Mała aplikacja z ograniczoną liczbą ekranów i porządną bazą kodu może osiągnąć pożądany poziom w kilka tygodni; aplikacja z wieloma niestandardowymi komponentami, wieloma platformami i długą historią długów technicznych zajmie raczej miesiące. Największą zmienną nie jest liczba ekranów, ale ile z funkcjonalności zbudowano poza standardowymi komponentami iOS lub Android.
Jako wskazówka przybliżona: aplikacja składająca się głównie z standardowych elementów interfejsu i której zespół jest już zaznajomiony z dostępnością, w praktyce często daje się dostosować w ciągu sześciu do dziesięciu tygodni. Aplikacja z dużą ilością niestandardowej funkcjonalności, animacji, gestów niestandardowych lub osadzonych SDK stron trzecich szybko wydłuża się do trzech do sześciu miesięcy, po prostu dlatego, że każdy komponent musi być zbadany oddzielnie, a czasem przebudowany. Nie są to sztywne granice, ale wrażenie, gdzie w praktyce kończy się większość projektów.
Co naprawdę określa czas realizacji
Czas, jaki zajmuje projekt, zależy mniej od samego prawa, a bardziej od trzech praktycznych czynników. Po pierwsze: czy funkcjonalność jest zbudowana ze standardowych komponentów systemu operacyjnego, czy głównie niestandardowo? Komponenty standardowe często zapewniają dostępność w dużej mierze z góry; komponenty niestandardowe muszą być wyposażone jeden po drugim w prawidłowe etykiety, kolejność skupienia i ogłoszenia dla czytników ekranu. Po drugie: ile zewnętrznych komponentów znajduje się w aplikacji, takich jak moduły płatności, wyświetlacze map lub okna czatu stron trzecich? Te często pozostają poza bezpośrednią kontrolą własnego zespołu, a pytanie dostawcy zajmuje zwykle więcej czasu niż samo testowanie. Po trzecie: czy istnieje już procedura testowania z czytnikiem ekranu na prawdziwym urządzeniu, czy musi być jeszcze ustanowiona? Ta ostatnia opcja kosztuje w pierwszej rundzie najwięcej czasu, ale zwraca się w kolejnych aktualizacjach.
Gdzie planowanie w praktyce się zatrzymuje
Większość opóźnień nie wynika z dostosowywania tekstu lub kontrastu koloru, ale z interakcji, która okazuje się nieosiągalna za pomocą klawiatury lub czytnika ekranu: gest przeciągnięcia bez alternatywy, modalne okno, które nie utrzymuje fokusu, lub formularz, którego komunikaty o błędach nie są ogłaszane. Tego rodzaju problemy zwykle stają się widoczne tylko przy ręcznym testowaniu z czytnikiem ekranu, czego automatyczne skanowanie nie może w pełni zastąpić. Osoby polegające wyłącznie na automatycznej kontroli zazwyczaj odkrywają te wąskie gardła zbyt późno w projekcie, co i tak wydłuża jego czas realizacji. Dobrym punktem wyjścia jest zatem w kilka pytań uzyskać wstępne pojęcie gdzie aplikacja aktualnie się znajduje, tak aby czasochłonne elementy pojawiły się wcześnie zamiast tuż przed dostarczeniem.
Cykle przeglądu sklepu aplikacji również odgrywają rolę: dostosowanie, które poprawia dostępność, musi przejść przez zwykły okres przeglądu danego sklepu, zanim użytkownicy go zauważą. To leży poza wpływem zespołu programistów i powinno być stałą wartością buforową w każdym planie.
Pozostanie dostępnym po dostarczeniu
Aplikacja, która dziś spełnia wymagania, może tego nie robić po następnej aktualizacji. Każda nowa funkcja, każdy nowy ekran i każdy zmieniony przepływ zasługuje na taką samą uwagę jak pierwsze podejście, w innym wypadku problem się powróci. Dlatego też obowiązek nie kończy się na jednym testowaniu: własna ocena musi być aktualna, a to wymaga cyklicznego rytmu zamiast jednorazowego projektu. Aby uzyskać tło do tego, co dokładnie wymaga się od Ciebie w tej sytuacji, zróżnicowane opracowanie dla Twojej sytuacji jest odpowiednim punktem wyjścia.
Co axessia.eu robi i czego nie robi w tym projekcie
Axessia testuje, priorytetyzuje, dokumentuje i monitoruje: skan pokazuje bieżący stan aplikacji, raport przedstawia ustalenia w zrozumiałym języku na liście priorytetowej, a oświadczenie i plan naprawy dokumentują, co zostało zrobione i co jeszcze należy zrobić. Audyty ręczne i prace naprawcze samej aplikacji nie są częścią tego zakresu; pozostają w gestii zespołu deweloperskiego lub strony, która aplikację tworzy. Wyjaśnienie, jak dokładnie przebiegał skan i jakie źródła przy tym wykorzystywano, znajduje się na stronie dotyczącej sposobu opracowania informacji. Cenę pełnego cyklu pracy, w tym raportu i oświadczenia, można znaleźć na przeglądzie subskrypcji.
Jeśli chcesz wiedzieć, w jakim stanie znajduje się konkretna aplikacja, najlepiej zacząć od bezpłatnego quick-scanu axessia.eu. Daje on pierwsze wyobrażenie w ciągu kilku minut, bez potrzeby posiadania konta.