Nu există o perioadă fixă valabilă pentru fiecare aplicație. O aplicație mică cu un număr limitat de ecrane și o bază de cod bine organizată poate fi ajustată la nivelul dorit în câteva săptămâni; o aplicație cu o mulțime de componente personalizate, mai multe platforme și un lung istoric de datorii tehnice durează mai degrabă luni. Cea mai mare variabilă nu este numărul de ecrane, ci cât din interacțiune este construită în afara componentelor standard ale iOS sau Android.
Ca indicație aproxmativă: o aplicație care constă în mare parte din elemente UI standard și al cărei echip este deja familiarizat cu accesibilitatea se poate adapta în practică adesea în șase până la zece săptămâni. O aplicație cu multă interacțiune personalizată, animații, gesturi personalizate sau SDK-uri încorporate de terți durează ușor trei până la șase luni, pur și simplu pentru că fiecare componentă trebuie examinată separat și uneori reconstruită. Acestea nu sunt limite stricte ci o indicație a locului în care majoritatea traiectoriilor se termină în practică.
Ceea ce determină cu adevărat durata
Durata unui traject depinde mai puțin de lege în sine și mai mult de trei factori practici. În primul rând: interacțiunea este construită din componente standard ale sistemului de operare sau în mare parte personalizată? Componentele standard oferă adesea accesibilitate în mare parte din capă; componentele personalizate trebuie să fie prevăzute una câte una cu etichetele corecte, ordinea de focus și anunțuri pentru cititoarele de ecran. În al doilea rând: câte componente externe sunt în aplicație, cum ar fi module de plată, afișări de hărți sau ferestre de chat de la terți? Acestea cad adesea în afara controlului direct al propriului echip, iar obținerea de clarități de la un furnizor durează de obicei mai mult timp decât testarea însăși. În al treilea rând: există deja o rutină de testare cu o cititor de ecran pe dispozitivul real, sau trebuie să fie configurată mai întâi? Aceasta din urmă costă cel mai mult timp în prima rundă, dar se amortizează la actualizările viitoare.
Unde se blochează planificările în practică
Cea mai mare parte a întârzierii nu apare atunci când se ajustează textul sau contrastul culorilor, ci atunci când interacțiunea se dovedește a nu putea fi utilizată cu tastatura sau cititorul de ecran: o mișcare de tragere fără alternativă, o fereastră modală care nu ține focusul, sau un formular al cărui mesaje de eroare nu sunt anunțate. Acest tip de probleme devine adesea vizibil doar la testarea manuală cu un cititor de ecran, ceva pe care o scanare automată nu poate înlocui complet. Cine se bazează doar pe o verificare automată descoperă de obicei aceste blocaje prea târziu în traject, ceea ce prelungește din nou durata. Un bun punct de plecare este deci în câteva întrebări pentru a obține o primă indicație a locului în care se află aplicația în acest moment, pentru ca părțile care consumă timp să apară devreme în loc să fie chiar înainte de livrare.
Ciclurile de revizuire din app store joacă, de asemenea, un rol: o ajustare care îmbunătățește accesibilitatea trebuie să treacă prin perioada normală de revizuire a stocului respectiv înainte ca utilizatorii să observe ceva. Aceasta se află în afara influenței echipei de dezvoltare și trebuie inclusă în fiecare plan ca tampon de timp fix.
Rămânând accesibil după lansare
O aplicație care satisface astazi nu mai poate face-o după actualizarea următoare. Fiecare nouă funcție, fiecare ecran nou și fiecare flux modificat merită aceeași atenție ca și prima rundă, altfel problema se strecură înapoi. De aceea, obligația nu se oprește la o singură testare: evaluarea proprie trebuie să rămână actuală, iar aceasta necesită un ritm recurent în loc de un proiect singular. Pentru contextul privind ceea ce vi se cere exact în această privință, comanda contextul selectat în funcție de situație este un punct de plecare potrivit.
Ce face și ce nu face axessia.eu în acest traject
Axessia testează, stabilește priorități, documentează și monitorizează: scanarea arată unde se află aplicația în acest moment, raportul prezintă rezultatele în limbaj accesibil pe o listă prioritizată, iar declarația și planul de îmbunătățire documentează ce s-a făcut și ce mai trebuie să se întâmple. Auditurile manuale și lucrările de reparație ale aplicației în sine nu fac parte din acestea; acestea rămân în sarcina echipei de dezvoltare sau a părții care a construit aplicația. Modul în care se realizează exact scanarea și care sunt sursele utilizate sunt explicate pe pagina despre cum se creează informațiile. Ce costă un parcurs complet inclusiv raport și declarație se găsește pe prezentarea generală a abonamentelor.
Cine dorește să știe unde se află o aplicație concretă în acest moment, este bine să înceapă cu scanarea rapidă și gratuită a axessia.eu. Aceasta oferă în câteva minute o primă imagine, fără a fi necesară o înregistrare.