Requisitos de accesibilidad de una app móvil: ¿qué debe definir una pequeña empresa antes de desarrollar?

Los requisitos de accesibilidad de una app móvil convierten «háganla accesible» en decisiones de producto verificables. Una pequeña empresa debe definir cómo los usuarios soportados van a percibir, entender, navegar y completar las tareas críticas con lectores de pantalla, escalado de texto, entrada alternativa, movimiento reducido, subtítulos, errores claros y autenticación accesible, antes de empezar a desarrollar.

Esta guía se ocupa de los criterios de aceptación de accesibilidad móvil. Complementa los materiales de Le Website sobre el alcance del producto, las pruebas generales, la seguridad, el rendimiento y la operación del lanzamiento, sin sustituir esos requisitos.

¿Qué deben incluir los requisitos de accesibilidad de una app móvil?

Deben definir el estándar objetivo, las tecnologías de apoyo soportadas, las etiquetas semánticas, el orden del foco, la entrada alternativa, el escalado de texto, el contraste, el movimiento, el audio, los medios, los formularios, los errores, la autenticación, la cobertura de dispositivos, la evidencia de pruebas, los responsables, las excepciones y las puertas de publicación. Cada regla necesita un método de aceptación medible y alguien que la apruebe.

Empiece por el documento de requisitos de una app móvil y liste los recorridos que deben seguir siendo utilizables: alta de cuenta, inicio de sesión, búsqueda, pago, reserva, actualizaciones de campo, soporte y recuperación. El alcance de accesibilidad debe seguir tareas reales del negocio, no una lista genérica desconectada del producto.

Defina la accesibilidad por tarea y por necesidad del usuario

Escriba cada requisito alrededor de un resultado: un usuario de lector de pantalla puede completar el pago, un usuario con baja visión puede leer y operar la interfaz en el tamaño de texto soportado, y un usuario de conmutador puede alcanzar todos los controles obligatorios. Así la aceptación tiene sentido y quedan a la vista los estados, instrucciones, confirmaciones y rutas de recuperación que faltan.

Separe las puertas obligatorias de las metas de mejora

Marque las barreras críticas como bloqueos de publicación y las mejoras de menor impacto como pendientes con seguimiento. Toda excepción debe nombrar a los usuarios afectados, la consecuencia para el negocio, la alternativa temporal, la mitigación, el responsable, quien aprueba, la fecha de vencimiento y el hito de reprueba. La deuda de accesibilidad no debería desaparecer dentro de una nota vaga de «problema conocido», sin responsable ni registro de la decisión.

¿Qué estándar de accesibilidad debe usar una app móvil?

Use WCAG 2.2 como línea base verificable, y luego traduzca sus resultados a componentes, gestos, ajustes y tecnologías de apoyo nativos de iOS y Android. Agregue los requisitos contractuales, sectoriales, de compras públicas y de jurisdicción que apliquen, con asesoría legal calificada. Un estándar es un piso; los recorridos críticos del negocio igual necesitan criterios de aceptación propios del producto.

El World Wide Web Consortium publica las Pautas de Accesibilidad para el Contenido Web 2.2 y una nota de orientación de WCAG 2.2 para aplicaciones móviles. Esa nota explica cómo aplicar los principios de WCAG a experiencias móviles nativas, web e híbridas, pero no sustituye a la especificación normativa.

Arme una matriz de requisitos trazable

Para cada criterio aplicable, registre la pantalla o componente, la tarea del usuario, la plataforma, los pasos de aceptación, el resultado esperado, la evidencia, el responsable y el estado. Marque con una razón lo que no aplica. La trazabilidad hace repetible una auditoría y evita que un equipo declare conformidad amplia solo porque un escáner devolvió un resumen favorable.

No publique declaraciones de conformidad sin verificar

Una lista interna aprobada no establece automáticamente conformidad legal, certificación ni accesibilidad universal. Describa con precisión el alcance probado, las versiones, las plataformas, las tecnologías de apoyo, las fechas y las limitaciones. Deje que asesores calificados interpreten las leyes y las obligaciones contractuales. El lenguaje de marketing debe coincidir con la evidencia conservada y evitar garantías que el equipo de producto no pueda sustentar.

¿Cómo se definen los requisitos para lectores de pantalla?

Deben cubrir nombres accesibles, roles, valores, estados, pistas, encabezados, agrupaciones, orden de lectura, orden del foco, restauración del foco, anuncios dinámicos, límites de los diálogos, controles personalizados, imágenes y retroalimentación de errores. Pruebe recorridos completos con VoiceOver de Apple y TalkBack de Android, no etiquetas aisladas ni solo inspección automática.

Los principios de accesibilidad de Android de Google explican el etiquetado, las áreas de toque, el contenido relacionado, las acciones alternativas y las consideraciones de prueba. La documentación de accesibilidad de Apple cubre las tecnologías de plataforma y los recursos para desarrolladores. Use componentes nativos cuando expresen de forma fiable la semántica buscada; los controles personalizados exigen un comportamiento accesible deliberado.

Especifique nombre, rol, estado y valor

Un control debe exponer qué es, qué hace, en qué estado está y cualquier valor que el usuario necesite. Evite etiquetas duplicadas o ruidosas. Los botones que solo tienen icono necesitan un nombre con sentido. Los interruptores, pestañas, indicadores de progreso, estados de validación y regiones expandibles deben comunicar los cambios de forma programática, no solo por su apariencia.

Controle el foco durante los cambios dinámicos

Cuando la navegación, los diálogos, la validación, la carga o las actualizaciones asíncronas cambien la interfaz, defina adónde se mueve el foco, qué se anuncia y adónde vuelve. No devuelva al usuario al inicio de la pantalla sin razón. Los mensajes de estado deben ser oportunos e informativos sin interrumpir cada pequeña actualización ni generar anuncios repetidos.

¿Qué requisitos de entrada alternativa son necesarios?

Deben garantizar que las tareas críticas funcionen con toque, teclado externo, acceso por conmutador y control por voz donde estén soportados. Defina un recorrido lógico, foco visible, controles operables, tamaño de objetivo, alternativas a los gestos, alternativas al arrastre, control de los tiempos, comportamiento de orientación y rutas de salida. El movimiento del dispositivo o los gestos con varios dedos no pueden ser el único método.

Integre la matriz de entrada en los requisitos de pruebas de una app móvil. Un componente puede sonar correcto en el lector de pantalla y aun así ser inalcanzable con teclado externo o conmutador. La aceptación debe verificar el recorrido entero, incluidos menús, diálogos, vistas web, mapas, cargadores de archivos, selectores de fecha y componentes de terceros.

Ofrezca alternativas a los gestos complejos

Los deslizamientos, los pellizcos, los gestos de trazado, el arrastre, la sacudida y el movimiento del dispositivo necesitan una alternativa accesible cuando ejecutan acciones obligatorias. Un botón etiquetado, un selector incremental, un menú o un control numérico pueden dar el mismo resultado. Documente la equivalencia, para que la alternativa no sea un flujo recortado que omita opciones o respuestas importantes.

Haga visible el foco y predecible el recorrido

Quien use teclado externo o conmutador necesita un indicador de foco visible, un orden lógico, ausencia de trampas de foco y una forma fiable de cerrar superposiciones o volver al contenido anterior. Pruebe el movimiento hacia adelante y hacia atrás. El foco debe seguir la estructura visual y semántica, respetando las convenciones de la plataforma y el método de entrada que el usuario eligió.

¿Cómo deben funcionar los requisitos de texto, contraste, color y zoom?

Defina el escalado de texto soportado, el reflujo de la maquetación, el contraste mínimo, el significado independiente del color, un espaciado legible, el soporte de orientación y las reglas de truncado para cada pantalla crítica. El contenido y los controles deben seguir siendo comprensibles y operables con los ajustes de plataforma documentados. Pruebe etiquetas largas, localización, validaciones, tablas, gráficos y cuentas con muchos datos, no solo textos ideales.

Use criterios medidos de WCAG en vez de juicio visual, pero valide las interfaces nativas e híbridas reales en dispositivos. Una biblioteca de tokens puede estandarizar color y tipografía; no puede demostrar que los estados en ejecución, las superposiciones, los controles deshabilitados, las imágenes, los gráficos o el contenido generado por usuarios sigan siendo accesibles en cada combinación soportada.

Soporte el escalado de texto sin perder tareas

En los tamaños de texto exigidos, el usuario no debería perder etiquetas, instrucciones, valores, acciones ni la recuperación ante errores. Deje que el contenido fluya y que los contenedores crezcan. Evite controles de alto fijo que recorten el texto. Pruebe horizontal y vertical donde estén soportados, además de texto grande del sistema, texto en negrita, zoom de pantalla y contenido real cerca de los límites documentados.

No use el color como única señal

Acompañe el color con texto, iconos, patrones, posición o estado programático. Los campos obligatorios, las pestañas seleccionadas, las series de un gráfico, las advertencias, los mensajes de éxito y los errores de validación necesitan otra señal distinguible. Verifique el contraste en los estados por defecto, presionado, con foco, deshabilitado, de error, en modo oscuro y en alto contraste, no solo en la maqueta principal.

¿Qué requisitos de movimiento, audio y multimedia debe incluir la app?

Deben respetar la preferencia de movimiento reducido, evitar destellos dañinos, permitir pausar el movimiento no esencial, preservar el significado sin animación y ofrecer subtítulos, transcripciones, controles y alternativas para el contenido pregrabado. Las alertas sonoras necesitan un equivalente visual o háptico cuando corresponda, y los avisos esenciales deben seguir siendo perceptibles sin un canal sensorial.

El rendimiento y la accesibilidad se refuerzan entre sí: menos animaciones bloqueantes, controles que responden, carga predecible y maquetaciones estables suelen mejorar los dos. Mantenga los requisitos de rendimiento de una app móvil como responsables de la latencia y los presupuestos de recursos, mientras esta guía se ocupa del movimiento reducido, las alternativas sensoriales, la reproducción accesible y la retroalimentación perceptible.

Respete el ajuste de movimiento reducido

Defina qué transiciones se eliminan, se simplifican o se acortan cuando el usuario activa el movimiento reducido de la plataforma. Conserve los cambios de orientación y de estado sin zoom innecesario, paralaje, giros ni reproducción automática. Pruebe la incorporación, la navegación, el refresco, los efectos de éxito, las cargas esqueléticas, los gráficos y las superficies promocionales, porque el movimiento suele entrar después de la revisión de diseño.

Haga usables los controles y las alternativas de multimedia

Los subtítulos y las transcripciones deben ser exactos, sincronizados cuando haga falta y fáciles de encontrar. Los controles de reproducción necesitan etiquetas, objetivos de tamaño suficiente, estado claro, foco lógico y anuncios para el lector de pantalla. Si un video o un audio comunica una instrucción obligatoria, ofrezca una ruta equivalente para quien no pueda percibir u operar ese medio.

¿Cómo se hacen accesibles los formularios, la autenticación y los errores?

Un formulario accesible necesita etiquetas persistentes, instrucciones claras, propósito de entrada correcto, teclados predecibles, opciones agrupadas, errores anunciados, entradas preservadas y una ruta de recuperación. La autenticación debe funcionar con gestores de contraseñas, copiar y pegar, biometría de la plataforma y métodos accesibles de doble factor. Los límites de tiempo, los captchas y las verificaciones de identidad exigen alternativas prácticas y soporte.

La accesibilidad y la seguridad se coordinan, no se cambian una por otra a ciegas. Los requisitos de seguridad de una app móvil siguen siendo los responsables de los controles frente a amenazas, el manejo de sesiones, los secretos, los permisos y la respuesta a incidentes. Esta guía se ocupa de si quien usa tecnologías de apoyo puede entender y completar ese flujo seguro aprobado sin barreras innecesarias.

Conecte los errores con el campo y con la recuperación

Un error debe identificar el problema, indicar cómo corregirlo, estar asociado de forma programática al campo correspondiente y recibir foco o anuncio en el momento adecuado. Conserve las entradas válidas después de enviar. No dependa de bordes rojos, de avisos que desaparecen ni de un genérico «entrada inválida» que deja al usuario adivinando.

Ofrezca opciones de autenticación accesibles

Soporte gestores de contraseñas y el pegado cuando la política de seguridad lo permita, exponga los campos correctamente y evite pruebas de memoria o acertijos inaccesibles. Si el doble factor usa códigos, enlaces, notificaciones o biometría, pruebe cada ruta soportada con tecnología de apoyo. Documente una ruta accesible de recuperación y de soporte para clientes y empleados bloqueados.

¿Cómo debe probar un equipo la accesibilidad de una app móvil?

Pruebe durante todo el diseño y el desarrollo con inspección semántica, comprobaciones automáticas, recorridos manuales con tecnología de apoyo, entrada por teclado y conmutador, escalado de texto, medición de contraste, movimiento reducido, orientación y contenido representativo. Ejecute las pruebas en dispositivos iOS y Android soportados. Las herramientas automáticas encuentran clases de defectos; que la persona complete la tarea es lo que determina si el producto funciona.

La guía oficial de pruebas de accesibilidad de Android recomienda combinar métodos manuales, analíticos y automáticos. Use herramientas para ampliar la cobertura y la repetibilidad, pero nunca equipare un escaneo limpio con una experiencia accesible. La navegación, la comprensión, la entrada, la retroalimentación y la recuperación reales siguen exigiendo evaluación humana.

Pruebe los prototipos antes de que el código sea caro

Revise la jerarquía de información, el orden de lectura, las etiquetas, la secuencia del foco, el crecimiento del texto, el contraste, los gestos, el manejo de errores y el movimiento durante el diseño. Las pruebas sobre prototipo revelan barreras estructurales antes de que la arquitectura de componentes se endurezca. Documente los supuestos que no puedan validarse hasta la implementación nativa y conviértalos en tareas explícitas de aceptación para ingeniería y calidad.

Incluya a personas con discapacidad de forma adecuada

Usuarios con discapacidad pueden revelar barreras de flujo, lenguaje, tiempo y contexto que un equipo técnico no ve. Recluté con criterios éticos, compense a los participantes, proteja la información personal y defina el alcance de la investigación. Las pruebas con usuarios complementan a los estándares y a las pruebas técnicas; una muestra pequeña no demuestra accesibilidad universal ni sustituye una cobertura sistemática de aceptación.

¿Qué evidencia debe bloquear o aprobar una publicación?

La evidencia debe incluir la matriz de requisitos, las compilaciones probadas, los dispositivos, los sistemas operativos, las tecnologías de apoyo, los recorridos completados, los resultados automáticos, las notas manuales, grabaciones o capturas cuando corresponda, la severidad de los defectos, la prueba de la reprueba, las excepciones, los responsables y la aprobación. Bloquee la publicación cuando un usuario soportado y crítico no pueda completar una tarea esencial de forma segura, privada e independiente.

La evidencia pertenece a una versión y a un alcance concretos. Registre el identificador de compilación, la fecha, el entorno, el estado de la cuenta, el dispositivo, la versión de plataforma, los ajustes de la tecnología de apoyo, quién probó, el resultado esperado, el resultado real, el defecto y la reprueba. Ate las barreras sin resolver a la decisión de publicar, en vez de esconderlas dentro de un resumen general de calidad.

Defina la severidad por consecuencia para el usuario y el negocio

Una barrera crítica impide una tarea obligatoria, expone información sensible, produce un resultado inseguro o no deja alternativa razonable. Los defectos de severidad alta causan gran dificultad o una finalización poco fiable. Los de menor severidad igual necesitan responsable y fecha. Priorice por consecuencia y por recorridos afectados, no por el número de pantallas ni por el esfuerzo técnico.

Vigile las regresiones después del lanzamiento

Siga los defectos de accesibilidad, los contactos a soporte, los recorridos abandonados, los cambios de componentes, las actualizaciones de sistema operativo y las versiones de los SDK de terceros. Revise de nuevo los flujos críticos después de cambios relevantes en el sistema de diseño, la navegación, la autenticación, los pagos, los medios o el framework. La analítica de producción puede revelar fricción, pero no identifica discapacidad ni sustituye la investigación con consentimiento ni las pruebas directas.

Preguntas frecuentes sobre los requisitos de accesibilidad de una app móvil

Las pequeñas empresas suelen necesitar respuestas sobre estándares, alcance en apps nativas, tecnología de apoyo, momento y responsabilidad. La regla práctica es constante: defina la accesibilidad antes de implementar, pruebe recorridos soportados completos, conserve evidencia por versión y asigne decisiones a responsables con nombre en producto, diseño, ingeniería, calidad y negocio, en vez de confiar en un escaneo automático tardío.

¿Qué es un requisito de accesibilidad de una app móvil?

Es un enunciado verificable que describe cómo un usuario soportado puede percibir, entender, navegar, operar o recuperarse dentro de un recorrido concreto del producto. Nombra la plataforma, la condición, el resultado esperado, el método de evaluación, la evidencia, la severidad y el responsable, en vez de usar instrucciones vagas como «hagan la app accesible».

¿WCAG aplica a las apps móviles nativas?

WCAG ofrece una línea base de accesibilidad verificable y muy usada, y el W3C publica orientación para aplicar sus principios a experiencias móviles. Las apps nativas igual requieren interpretación específica de plataforma para componentes, semántica, gestos, ajustes y tecnologías de apoyo. La organización también debería identificar los contratos, reglas de compra, obligaciones sectoriales y leyes aplicables con asesoría calificada.

¿Las pruebas deben incluir tecnología de apoyo real?

Sí. Las comprobaciones automáticas y la inspección semántica sirven, pero el equipo debe completar manualmente los recorridos críticos con las tecnologías de apoyo soportadas, como VoiceOver y TalkBack, además de entrada alternativa y ajustes de texto cuando corresponda. La prueba debe verificar navegación, comprensión, cambios de estado, errores, recuperación y finalización, no solo etiquetas de componentes aisladas.

¿Cuándo deben empezar las pruebas de accesibilidad móvil?

Empiezan en la etapa de requisitos y diseño, antes de que las decisiones de implementación se vuelvan caras. Revise prototipos, especificaciones de componentes, contenido, orden del foco, escalado, contraste, gestos y movimiento temprano. Continúe con comprobaciones de componentes, pruebas de recorrido integradas, aceptación de la publicación y vigilancia de regresiones. Esperar al envío a la tienda convierte las barreras estructurales en excepciones sensibles a la fecha.

¿Quién debe aprobar los requisitos de accesibilidad?

Los responsables de producto y de negocio aprueban los recorridos soportados y el riesgo; diseño y contenido definen la interacción y la comunicación inclusivas; ingeniería implementa la semántica de plataforma; calidad verifica la evidencia. Toda excepción necesita un responsable del riesgo autorizado, impacto documentado, mitigación, vencimiento y fecha de reprueba. Las preguntas legales requieren asesoría calificada.

¿Cuál es el siguiente paso?

Elija cinco recorridos críticos, identifique las versiones de iOS y Android soportadas, seleccione la línea base de accesibilidad, liste las tecnologías de apoyo y los ajustes exigidos, y escriba criterios de aceptación medibles antes de estimar el desarrollo. Después asigne responsables de diseño, ingeniería, contenido, pruebas, excepciones y aprobación. Le Website puede convertir ese alcance en un plan de implementación y verificación.

Use esta secuencia:

1. Nombre los usuarios, dispositivos, plataformas, ajustes y recorridos críticos dentro del alcance.
2. Traduzca los resultados de WCAG y el comportamiento nativo de cada plataforma a cada recorrido.
3. Defina criterios de aceptación semánticos, visuales, de entrada, de movimiento, de multimedia, de formularios y de autenticación.
4. Elija la evidencia manual, automática, con tecnología de apoyo y con usuarios.
5. Fije los bloqueos de publicación, la autoridad para excepciones, las fechas de revisión y quién responde por las regresiones.

Si su equipo necesita ayuda para convertir objetivos de producto en requisitos de accesibilidad medibles, contacte a Le Website para una sesión enfocada de descubrimiento y planificación de accesibilidad.