No hay un plazo fijo que se aplique a todas las aplicaciones. Una aplicación pequeña con un número limitado de pantallas y una base de código limpia puede alcanzar el nivel deseado en algunas semanas; una aplicación con muchos componentes personalizados, múltiples plataformas y un largo historial de deuda técnica tardará más bien meses. La variable más importante no es la cantidad de pantallas, sino cuánta de la interacción se ha construido fuera de los componentes estándar de iOS o Android.
Como indicación aproximada: una aplicación que consiste principalmente en elementos de interfaz estándar y cuyo equipo ya está familiarizado con la accesibilidad, normalmente se puede adaptar en la práctica dentro de seis a diez semanas. Una aplicación con mucha interacción personalizada, animaciones, gestos personalizados o SDK incrustados de terceros fácilmente alcanza tres a seis meses, simplemente porque cada componente debe examinarse por separado y a veces reconstruirse. Estos no son límites estrictos sino una indicación de dónde terminan la mayoría de los proyectos en la práctica.
Lo que realmente determina el tiempo de ejecución
El tiempo que tarda un proyecto depende menos de la normativa en sí y más de tres factores prácticos. Primero: ¿la interacción está construida con componentes estándar del sistema operativo o principalmente personalizada? Los componentes estándar a menudo proporcionan accesibilidad en gran medida de forma gratuita; los componentes personalizados deben tener etiquetas, orden de enfoque y anuncios apropiados para lectores de pantalla, uno por uno. Segundo: ¿cuántos componentes externos hay en la aplicación, como módulos de pago, vistas de mapas o ventanas de chat de terceros? Estos a menudo están fuera del control directo del equipo interno, y consultar con un proveedor normalmente toma más tiempo que la prueba en sí. Tercero: ¿ya existe una rutina de prueba con un lector de pantalla en el dispositivo real, o debe configurarse? Lo último consume la mayor parte del tiempo en la primera ronda, pero se amortiza en futuras actualizaciones.
Dónde se quedan atrapadas las planificaciones en la práctica
La mayoría de los retrasos no ocurren al ajustar texto o contraste de color, sino cuando se descubre que la interacción no se puede operar con teclado o lector de pantalla: un gesto de arrastre sin alternativa, una ventana modal que no mantiene el enfoque, o un formulario cuyos mensajes de error no se anuncian. Este tipo de problemas generalmente solo se hacen visibles en las pruebas manuales con un lector de pantalla, algo que un escaneo automatizado no puede reemplazar completamente. Quien confía solo en una verificación automática normalmente descubre estos cuellos de botella demasiado tarde en el proyecto, lo que de todas formas alarga el tiempo de ejecución. Un buen punto de partida es, por lo tanto, obtener en unas pocas preguntas una indicación inicial de dónde se encuentra la aplicación en este momento, para que las partes que consumen tiempo aparezcan temprano en lugar de justo antes de la entrega.
Los ciclos de revisión de la tienda de aplicaciones también influyen: una actualización que mejora la accesibilidad debe pasar por el período de revisión habitual de la tienda respectiva antes de que los usuarios noten algo. Eso está fuera de la influencia del equipo de desarrollo y debe figurar en todas las planificaciones como un búfer de tiempo fijo.
Mantenerse accesible después de la entrega
Una aplicación que cumple hoy puede no cumplir después de la siguiente actualización. Cada nueva función, cada nueva pantalla y cada flujo modificado merece la misma atención que en la primera ronda; de lo contrario, el problema vuelve a aparecer. Por eso la obligación no termina con una sola prueba: la propia evaluación debe mantenerse actualizada, y eso requiere un ritmo recurrente en lugar de un proyecto único. Para los antecedentes sobre qué se espera exactamente de usted en este contexto, el contexto personalizado para cada situación es un punto de partida adecuado.
Qué hace y qué no hace axessia.eu en este proceso
Axessia evalúa, prioriza, documenta y monitorea: el análisis muestra dónde se encuentra la aplicación en este momento, el informe presenta los hallazgos en lenguaje sencillo en una lista priorizada, y la declaración y el plan de mejora documentan qué se ha hecho y qué aún debe hacerse. Los auditorías manuales y el trabajo de reparación en la aplicación en sí no forman parte de esto; eso sigue siendo responsabilidad del equipo de desarrollo o de la parte que construye la aplicación. Cómo se realiza exactamente ese análisis y qué fuentes se utilizan en él se explica en la página sobre cómo se genera la información. El costo de un trayecto completo que incluya informe y declaración se encuentra en el resumen de suscripciones.
Quien quiera saber dónde se encuentra una aplicación concreta en este momento, es mejor que comience con el análisis rápido gratuito de axessia.eu. Este proporciona una primera idea en pocos minutos, sin necesidad de cuenta.