Planificar la evaluación de una app: exploración, inventario y muestra

En la lección anterior fijamos la referencia normativa (el capítulo 11 de la EN 301 549 (PDF, se abre en una ventana nueva)) y los elementos que debe recoger el alcance. Esta lección convierte eso en un plan ejecutable: cómo adaptar los cinco pasos de WCAG-EM (se abre en una ventana nueva) a una app, cómo explorarla para levantar un inventario de pantallas, estados y componentes, cómo escoger una muestra que puedas defender ante el cliente y qué hay que pedir antes del primer día de pruebas. Una muestra mal elegida invalida el informe aunque cada prueba esté bien hecha.

WCAG-EM aplicado a una app

Los cinco pasos de WCAG-EM, que viste en el nivel 4, se trasladan a una app con un cambio de vocabulario apoyado en WCAG2ICT. Estas son las equivalencias que usarás en el plan:

En WCAG-EM (web)	En la evaluación de una app
Sitio web	Una app en una plataforma: iOS y Android son dos productos a efectos de evaluación, aunque compartan código.
Página web	Pantalla, incluidas las vistas superpuestas: modales, hojas inferiores (bottom sheets, paneles que suben desde el borde inferior), menús y diálogos.
Estados de la página	Estados de la pantalla: vacío, cargando, con datos, error, sin conexión, sin permisos, sesión caducada.
Plantillas comunes	Patrones de navegación (pestañas, menú lateral) y pantallas que se repiten con distinto contenido.
Tecnologías en las que se confía	Versiones de iOS y Android, frameworks (SwiftUI, Compose, React Native, Flutter), contenido web dentro de WebViews y tecnologías de apoyo declaradas.
Procesos completos	Flujos: secuencias de pantallas que completan una tarea, incluidos los saltos a otras apps, al navegador o a componentes del sistema.

Infografía · Proceso

WCAG-EM aplicado a una app: cinco pasos

De la definición del alcance al informe, con pantallas, estados y flujos en lugar de páginas

1. 1Paso 1: 1. Definir el alcanceReferencia, versión, plataformas, dispositivos y tecnologías de apoyo
2. 2Paso 2: 2. Explorar la appInventario de pantallas, estados, componentes, terceros y hardware
3. 3Paso 3: 3. Seleccionar la muestraEstructurada por capas, flujos críticos completos y un 10 % aleatorio
4. 4Paso 4: 4. EvaluarPasada automática, protocolo en dispositivo y matriz de cobertura
5. 5Paso 5: 5. InformarResultados por cláusula, hallazgos con evidencia y declaración

Leer la infografía como texto

Proceso de cinco pasos en secuencia para evaluar una app móvil adaptando WCAG-EM. Paso 1, definir el alcance: referencia normativa, versión y compilación de la app, plataformas, dispositivos y tecnologías de apoyo. Paso 2, explorar la app: levantar un inventario de pantallas, estados, componentes personalizados, contenido de terceros, puntos de entrada externos y funciones de hardware. Paso 3, seleccionar la muestra: estructurada por capas, con todos los flujos críticos completos, más una muestra aleatoria de en torno al 10 % de la estructurada. Paso 4, evaluar: pasada automática, protocolo manual en dispositivo físico y una matriz de cobertura que decide qué configuración se prueba en qué pantallas. Paso 5, informar: resultados por cláusula, hallazgos con evidencia y recomendación, y declaración de accesibilidad.

Explorar la app y levantar el inventario

Explorar es el paso que más se descuida en apps, porque no hay mapa del sitio ni rastreador que liste las URL. Se hace a mano, primero sin tecnología de apoyo, anotando lo que encuentras en seis bloques:

1. Mapa de navegación: pantallas raíz, de segundo nivel, modales y hojas inferiores, en un esquema en árbol.
2. Estados: para cada pantalla relevante, qué estados puede mostrar. Provócalos: activa el modo avión para ver el error de red, deniega un permiso, deja caducar la sesión, usa una cuenta sin datos.
3. Componentes: separa los estándar de la plataforma (botones, listas, interruptores del sistema) de los personalizados (calendario propio, gráfico, deslizador dibujado, carrusel, selector de asiento). Los personalizados son donde aparecen los fallos de 11.4.1.2 Nombre, función, valor y de 11.5.
4. Contenido incrustado: WebViews, PDF que se abren dentro de la app, vídeos, mapas y SDK de terceros (chat de soporte, pasarela de pago, encuestas, aviso de consentimiento).
5. Puntos de entrada externos: notificaciones, widgets de la pantalla de inicio, enlaces profundos (deep links, enlaces que abren directamente una pantalla interna de la app) y extensiones para compartir.
6. Funciones que dependen del hardware: cámara (escaneo de códigos QR o documentos), NFC (por ejemplo, lectura del DNI electrónico), geolocalización, biometría, sensores de movimiento.

Anota también la tecnología con la que parece construida: condiciona las herramientas, como verás en la lección sobre apps híbridas y multiplataforma.

Seleccionar la muestra

Con el inventario delante, la muestra estructurada se construye por capas, igual que en web, y cada pantalla se anota con el motivo por el que entra:

• Pantallas comunes: inicio, inicio de sesión y registro, menú o ajustes, ayuda y contacto, y la pantalla de accesibilidad o «Acerca de» donde debería enlazarse la declaración.
• Una pantalla por cada tipo de componente personalizado y por cada patrón de navegación.
• Una pantalla por cada funcionalidad principal de la app.
• Todas las pantallas de los flujos críticos, de principio a fin, sin saltarse los pasos «aburridos» (confirmaciones, justificantes, pantallas de éxito).
• Los estados relevantes de las pantallas anteriores: un formulario se evalúa vacío, con errores y enviado.
• El contenido incrustado que forma parte de un flujo (la pasarela de pago, el PDF del justificante).

La muestra aleatoria sirve para comprobar que la estructurada es representativa. WCAG-EM propone que equivalga aproximadamente al 10 % de la muestra estructurada. Como en una app no hay URL que sortear, numera las pantallas del inventario que no han entrado en la estructurada y elige con un generador de números aleatorios. Deja constancia del método en el plan: si la muestra aleatoria saca a la luz problemas que no aparecían en la estructurada, es señal de que esta se quedó corta.

Usa la misma muestra en iOS y Android para poder comparar, y documenta las funciones exclusivas de una plataforma. Si las tabletas entran en el alcance, incluye al menos los flujos críticos en tableta: la disposición cambia y aparecen fallos propios.

La matriz de cobertura: qué se prueba dónde

El protocolo manual que verás más adelante enumera diez configuraciones. Aplicarlas todas a todas las pantallas en dos plataformas multiplica el esfuerzo sin aportar hallazgos. La solución es una matriz de cobertura:

Prueba	Dónde se aplica	Por qué
Lector de pantalla (VoiceOver y TalkBack)	Toda la muestra, en las dos plataformas	Es la que más hallazgos produce.
Texto al máximo, orientación horizontal, modo oscuro	Toda la muestra	Son rápidas: una captura por pantalla.
Teclado externo, control por botón (Switch Control o Accesibilidad con interruptores), control por voz	Flujos críticos y pantallas con componentes personalizados	Ahí se concentran sus fallos.
Reducir movimiento, escala de grises	Pantallas con animación, gráficos o estados por color	Solo aportan en esas pantallas.
Reproducción en el segundo dispositivo	Hallazgos críticos y altos	Distingue fallos de la app de los de una versión o fabricante.

Lo que hay que pedir antes de empezar

Muchos retrasos no son técnicos, sino de acceso. Pide por escrito, con antelación:

• Una versión congelada, identificada por número de versión y de compilación. Si la app no está publicada, la distribución habitual es TestFlight en iOS y las pruebas internas de Google Play o Firebase App Distribution en Android.
• Cuentas de prueba preparadas para cada estado que quieras evaluar (sin datos, con historial, con una incidencia abierta) y una solución para el segundo factor: códigos fijos en preproducción o un teléfono que reciba los SMS.
• Un entorno adecuado: preproducción con la pasarela de pago en modo de pruebas, y confirmación de que podrás grabar la pantalla (algunas apps lo bloquean).
• Documentación: sistema de diseño, declaración vigente, informes anteriores e incidencias conocidas.
• Un contacto técnico que conozca la tecnología de cada parte y los componentes de terceros.

Documentar y cerrar el plan

El plan es un documento breve que el cliente valida antes de empezar: referencia (EN 301 549 v3.2.1, capítulo 11 y cláusulas aplicables de los capítulos 5, 6, 7 y 12, más WCAG 2.2 AA si se acuerda), alcance, inventario resumido, muestra justificada, matriz de cobertura, calendario, entregables y exclusiones («el widget de la pantalla de inicio queda fuera del alcance»).

Resumen

• Los cinco pasos de WCAG-EM se trasladan a apps: la página pasa a ser pantalla con sus estados, el proceso pasa a ser flujo, y cada plataforma es un producto.
• La exploración levanta un inventario de navegación, estados, componentes, contenido incrustado, puntos de entrada externos y funciones de hardware.
• La muestra estructurada se construye por capas y la aleatoria, en torno al 10 % de la estructurada, se sortea sobre el inventario.
• Una matriz de cobertura decide qué configuración se prueba en qué pantallas y flujos.
• Antes de empezar hay que asegurar versión congelada, cuentas de prueba, entorno, permiso de grabación y un contacto técnico, y cerrar el plan por escrito.