Non esiste una scadenza fissa che si applica a ogni app. Un'app di piccole dimensioni con un numero limitato di schermate e una base di codice ordinata può raggiungere il livello desiderato in poche settimane; un'app con molti componenti personalizzati, più piattaforme e una lunga storia di debito tecnico richiede piuttosto mesi. La variabile più grande non è il numero di schermate, ma quanto dell'interfaccia è stata costruita al di fuori dei componenti standard di iOS o Android.
Come indicazione approssimativa: un'app che è composta principalmente da elementi UI standard e il cui team ha già familiarità con l'accessibilità, nella pratica spesso può essere adattata entro sei-dieci settimane. Un'app con molto interfaccia personalizzata, animazioni, gesti personalizzati o SDK incorporate di terzi arriva facilmente a tre-sei mesi, semplicemente perché ogni componente deve essere esaminato separatamente e talvolta ricostruito. Questi non sono limiti rigidi ma un'indicazione di dove la maggior parte dei progetti finisce nella pratica.
Cosa determina davvero il tempo di realizzazione
Il tempo che un progetto richiede dipende meno dalla legge stessa e più da tre fattori pratici. In primo luogo: l'interfaccia è costruita con componenti standard del sistema operativo, o principalmente personalizzata? I componenti standard spesso già forniscono gran parte dell'accessibilità; i componenti personalizzati devono essere forniti individualmente delle etichette corrette, dell'ordine di focus e degli annunci per i lettori di schermo. In secondo luogo: quanti componenti esterni sono presenti nell'app, come moduli di pagamento, visualizzazioni di mappe o finestre di chat di terzi? Questi spesso ricadono al di fuori del controllo diretto del team interno, e richiedere informazioni a un fornitore di solito richiede più tempo del test stesso. In terzo luogo: esiste già una procedura di test con un lettore di schermo sul dispositivo reale, o deve ancora essere creata? Quest'ultimo richiede il maggior tempo nel primo ciclo, ma si ripaga nei successivi aggiornamenti.
Dove le pianificazioni si bloccano nella pratica
Il maggior ritardo non si verifica durante l'adattamento del testo o del contrasto dei colori, ma nell'interazione che non risulta utilizzabile con tastiera o lettore di schermo: un gesto di trascinamento senza alternativa, una finestra modale che non mantiene il focus, o un modulo i cui messaggi di errore non vengono annunciati. Questo tipo di problemi di solito diventa visibile solo durante i test manuali con un lettore di schermo, qualcosa che una scansione automatizzata non può sostituire completamente. Chi si affida solo a un controllo automatico scopre di solito questi colli di bottiglia troppo tardi nel progetto, il che allunga comunque il tempo di realizzazione. Un buon punto di partenza è quindi ottenere in poche domande un primo indicazione di dove si trova l'app attualmente, in modo che le parti che richiedono più tempo vengano identificate presto invece che poco prima della consegna.
Anche i cicli di revisione dell'app store giocano un ruolo: un adattamento che migliora l'accessibilità deve comunque passare attraverso il consueto periodo di revisione del negozio interessato prima che gli utenti ne notino qualcosa. Ciò esula dal controllo del team di sviluppo e dovrebbe figurare in ogni piano come buffer di tempo fisso.
Rimanere accessibili dopo la consegna
Un'app che è conforme oggi potrebbe non esserlo dopo l'aggiornamento successivo. Ogni nuova funzione, ogni nuovo schermo e ogni flusso modificato meritano la stessa attenzione della prima volta, altrimenti il problema si ripresenta. Per questo motivo l'obbligo non si ferma a un test una volta sola: la propria valutazione deve rimanere attuale, e ciò richiede una cadenza ricorrente piuttosto che un progetto una tantum. Per le informazioni di contesto su cosa vi è richiesto esattamente in questa situazione, il contesto personalizzato per la vostra situazione è un punto di partenza appropriato.
Cosa axessia.eu fa e non fa in questo processo
Axessia valuta, assegna le priorità, registra e monitora: la scansione mostra lo stato attuale dell'app, il rapporto presenta i risultati in linguaggio semplice in un elenco ordinato per priorità, e la dichiarazione e il piano di miglioramento documentano ciò che è stato fatto e ciò che ancora deve accadere. Le verifiche manuali e il lavoro di correzione dell'app stessa non rientrano in questo ambito; rimangono a carico del team di sviluppo o della parte che ha costruito l'app. Come avviene esattamente questa scansione e quali fonti vengono utilizzate è spiegato su la pagina su come vengono prodotte le informazioni. Quanto costa un percorso completo incluso rapporto e dichiarazione è disponibile su la panoramica degli abbonamenti.
Chi vuole sapere lo stato attuale di un'app specifica, farebbe bene a iniziare con la scansione gratuita di axessia.eu. In pochi minuti fornisce una prima panoramica, senza necessità di un account.