Flujos de alto riesgo: acceso, seguridad, pagos, terceros y avisos

En casi todas las auditorías de apps, los hallazgos críticos se concentran en unos pocos flujos: entrar en la app, superar las medidas de seguridad, pagar, usar un componente de un tercero y reaccionar a avisos y notificaciones. Son también los más difíciles de evaluar: mezclan componentes del sistema, SDK de terceros (librerías que la app integra para chat, pagos o mapas) y medidas de seguridad que pueden impedir incluso grabar la evidencia. Esta lección te da, para cada uno, qué probar, cómo argumentar el hallazgo y qué hacer cuando la propia app te pone obstáculos.

Inicio de sesión y autenticación

Si la persona no puede entrar, el resto de la app no existe para ella. Revisa en cada plataforma:

• Biometría con alternativa: Face ID, Touch ID o la huella en Android usan diálogos del sistema, que suelen ser accesibles. Lo que se evalúa es que exista siempre otra vía (código o contraseña) igual de accesible, porque hay personas que no pueden usar la biometría.
• Autocompletar y pegar: comprueba que el gestor de contraseñas del sistema ofrece sus sugerencias en los campos de usuario y contraseña, que se puede pegar en ellos y que el código de un solo uso recibido por SMS se propone automáticamente. En iOS depende de textContentType (.username, .password, .oneTimeCode) y en Android de autofillHints. Sin estas marcas falla 1.3.5 Identificar el propósito de la entrada (11.1.3.5), y bloquear el pegado o el gestor de contraseñas hace fallar además 3.3.8 Autenticación accesible (mínimo) del bloque WCAG 2.2, porque obliga a recordar o transcribir.
• Teclados numéricos propios: muchas apps de banca dibujan su propio teclado para el PIN, a veces con las teclas en posiciones aleatorias. Con lector de pantalla, cada tecla debe anunciar su número y su rol (11.4.1.2), y el cambio de posición de las teclas no debe impedir encontrarlas recorriendo el teclado con el lector o con control por botón.
• Códigos con caducidad: si el código expira, la persona debe poder pedir otro sin reiniciar el proceso, y el aviso de caducidad debe anunciarse (2.2.1 Tiempo ajustable y 4.1.3 Mensajes de estado).
• Salto a otra app: si la identificación se delega en otra app o en el navegador, el flujo incluye ese salto y el regreso. Comprueba dónde queda el foco al volver y si se anuncia el resultado.

Medidas de seguridad que chocan con la accesibilidad

Detección de servicios de accesibilidad

Algunas apps Android, sobre todo de banca, muestran avisos o bloquean funciones cuando detectan un servicio de accesibilidad activo, como defensa contra programas maliciosos que abusan de la API de accesibilidad para leer la pantalla o pulsar por el usuario. Si esa medida impide usar TalkBack, Accesibilidad con interruptores o Acceso por voz, la app interfiere con las funciones de accesibilidad de la plataforma: incumplimiento de 11.6.2 y hallazgo crítico. La recomendación técnica existe: desde Android 14, las vistas sensibles pueden marcarse con accessibilityDataSensitive, de modo que solo accedan a ellas los servicios que se declaran como herramientas de accesibilidad, en lugar de bloquear a todos.

Bloqueo de capturas y grabaciones

Muchas apps impiden las capturas en pantallas sensibles (en Android, con la marca FLAG_SECURE): la grabación sale en negro. Eso no impide la evaluación, pero sí la evidencia. Opciones, por orden de preferencia: pedir en el plan una compilación de preproducción sin el bloqueo; grabar el dispositivo con una cámara externa, con el panel de subtítulos o la salida de voz visibles; y, como mínimo, transcribir literalmente lo anunciado. Indica la limitación en la metodología del informe.

Tiempo de sesión

Las sesiones cortas son habituales por seguridad. Provoca la caducidad con el lector activo: el aviso debe anunciarse con tiempo para reaccionar y ofrecer ampliarla, salvo que la duración sea esencial (2.2.1). Un cierre de sesión silencioso a mitad de un formulario largo es un hallazgo alto o crítico según la tarea.

Pagos y contenido de terceros

Los diálogos de Apple Pay y Google Pay son componentes del sistema: evalúa el botón que los abre y lo que ocurre al volver. Las pasarelas de pago, en cambio, suelen cargarse en una WebView o en el navegador, a veces con un paso de autenticación reforzada del banco emisor. Ese paso forma parte del proceso: según el requisito de conformidad de WCAG sobre procesos completos, si un paso no es accesible, el proceso entero no lo es.

El RD 1112/2018 (PDF, se abre en una ventana nueva) excluye el contenido de terceros que no esté financiado ni desarrollado por el organismo ni bajo su control. Un SDK o una pasarela que el organismo ha contratado, elegido y configurado difícilmente encaja en esa exclusión: se evalúa, y si falla, figura en la declaración. Presta especial atención a:

• Avisos de consentimiento (privacidad, cookies, seguimiento) que aparecen en el primer arranque: si no son accesibles, bloquean toda la app.
• Chats de soporte y encuestas: suelen ser WebViews con mensajes nuevos que no se anuncian (4.1.3) y campos sin etiqueta. Recuerda que el soporte accesible es también exigencia del capítulo 12.
• Mapas: marcadores sin nombre, ampliación solo con pellizco (2.5.1) y desplazamiento solo arrastrando. El RD excluye los mapas y servicios cartográficos en línea, con una condición para los destinados a la navegación: que la información esencial se ofrezca de forma accesible. lo que se evalúa entonces es esa alternativa (por ejemplo, la lista de oficinas con dirección y horario).

Avisos y notificaciones

• Mensajes efímeros: provoca cada aviso («Guardado», «Sin conexión», «Pago realizado») con el lector activo y anota lo anunciado. Los toasts del sistema Android (avisos breves que aparecen y desaparecen solos) suelen anunciarse; los avisos propios dibujados por la app, a menudo no. En iOS, la app debe enviar un anuncio explícito. Si no se anuncian, falla 4.1.3 Mensajes de estado (11.4.1.3). Si el aviso trae una acción («Deshacer») y desaparece en pocos segundos, comprueba que la persona con lector o con control por botón puede alcanzarla, o que la acción existe en otro sitio.
• Notificaciones: el texto debe tener sentido leído por el lector (no solo un emoji o «Tienes novedades»), y al abrirla, la pantalla de destino debe anunciar su título y dejar el foco en el contenido relacionado.

Cámara, escaneo y hardware

Escanear un código QR, fotografiar un documento o leer el DNI electrónico por NFC son tareas que una persona ciega o con baja visión necesita poder hacer con guía: indicaciones habladas o hápticas de encuadre («acerca el documento», «mantén la posición»), captura automática cuando el encuadre es correcto, controles etiquetados y, siempre que sea posible, una alternativa manual (introducir el código a mano). Además de los criterios aplicables (11.1.1.1 para el contenido no textual, 11.4.1.2 para los controles, 4.1.3 para los avisos), las declaraciones de prestaciones funcionales del capítulo 4 de la EN 301 549 (PDF, se abre en una ventana nueva), como 4.2.1 Uso sin visión, ayudan a argumentar el impacto en el informe.

Flujo	Riesgo típico	Qué probar
Acceso	Sin alternativa a la biometría; sin autocompletar ni pegar	Cada vía de acceso con lector; gestor de contraseñas; código por SMS
Seguridad	Bloqueo de servicios de accesibilidad; sesión que caduca en silencio	Usar la app con TalkBack, interruptores y voz; provocar la caducidad
Pago	Pasarela o paso del banco inaccesible	El proceso completo, hasta el justificante
Terceros	Aviso de consentimiento, chat o mapa inaccesibles	Primer arranque con lector; mensajes nuevos del chat; alternativa al mapa
Avisos	Mensajes no anunciados o que desaparecen antes de poder actuar	Provocar cada aviso con lector y con control por botón
Hardware	Escaneo sin guía ni alternativa manual	Completar el escaneo con lector y sin mirar la pantalla

Resumen

• El acceso necesita alternativa a la biometría, autocompletar y pegar (1.3.5 y, en WCAG 2.2, 3.3.8), teclados propios etiquetados y avisos de caducidad anunciados.
• Bloquear servicios de accesibilidad incumple 11.6.2; el bloqueo de capturas limita la evidencia, no la evaluación.
• Pasarelas, avisos de consentimiento, chats y mapas forman parte del proceso cuando el organismo los ha integrado.
• Cada aviso y notificación se provoca con el lector activo y se registra lo anunciado (4.1.3).
• El escaneo con cámara o NFC necesita guía no visual y, si es posible, alternativa manual.