Principios de accesibilidad móvil: táctil, tamaño, orientación y gestos (WCAG2ICT)

Las WCAG se escribieron para la web, pero sus principios (perceptible, operable, comprensible, robusto) son independientes de la tecnología. El documento WCAG2ICT del W3C («Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies», nota del grupo de trabajo actualizada en 2024 para cubrir WCAG 2.2) explica cómo interpretar cada criterio en software no web, incluidas las apps nativas. La EN 301 549 (PDF, se abre en una ventana nueva) lo incorpora en su capítulo 11. Esta lección fija el marco y los principios específicos del entorno móvil antes de entrar en código.

Qué cambia en móvil

• Entrada táctil: no hay puntero preciso ni teclado físico por defecto. Las personas con temblor, movilidad reducida o que usan el móvil con una mano necesitan objetivos grandes y gestos simples.
• Pantalla pequeña y variable: el usuario puede ampliar el texto hasta un 200-300 % desde los ajustes del sistema; la interfaz debe adaptarse, no truncarse.
• Tecnologías de apoyo del sistema: VoiceOver y TalkBack (lectores de pantalla), Zoom/Ampliación, Voice Control/Acceso por voz, Switch Control/Switch Access, Full Keyboard Access, teclados Bluetooth. La app no «añade» accesibilidad: expone información para que estos servicios funcionen.
• Contexto de uso: luz solar, ruido, movimiento, atención dividida. Muchas prácticas de accesibilidad (contraste, subtítulos, mensajes claros) benefician a todo el mundo en estas condiciones.

WCAG2ICT: cómo se traducen los criterios

WCAG2ICT sustituye términos web por sus equivalentes: «página web» pasa a ser «software» o «pantalla»; «conjunto de páginas» pasa a «conjunto de programas»; «determinado por software» significa expuesto a través de la API de accesibilidad de la plataforma (UIAccessibility en iOS, AccessibilityNodeInfo en Android). La mayoría de los criterios A y AA se aplican tal cual; algunos requieren interpretación:

Tamaño y espaciado de los objetivos

El criterio 2.5.8 de WCAG 2.2 fija un mínimo de 24×24 (no figura en la EN 301 549 v3.2.1, basada en WCAG 2.1); las Human Interface Guidelines de Apple recomiendan 44×44 puntos y Material Design 48×48 dp con 8 dp de separación. Aplica la guía de plataforma: es lo que esperan los usuarios y lo que miden las herramientas (Accessibility Scanner marca los objetivos menores de 48 dp). Los casos problemáticos habituales: iconos de 24 dp sin relleno táctil, enlaces dentro de párrafos, botones de cerrar en esquinas, controles de carrusel, celdas de calendario. La solución suele ser aumentar el área táctil sin cambiar el icono (relleno, minimumInteractiveComponentSize() en Compose, hitTest ampliado en UIKit).

Gestos: siempre con alternativa

Los gestos personalizados chocan con los lectores de pantalla: cuando VoiceOver o TalkBack están activos, interceptan los gestos (un deslizamiento a la derecha pasa al siguiente elemento, no abre el menú lateral). Reglas prácticas:

1. Cualquier gesto personalizado tiene un equivalente visible y enfocable (botón, elemento de menú).
2. Expón las acciones como acciones de accesibilidad (custom actions en iOS, accessibility actions en Android) para que el lector de pantalla las ofrezca en su menú de acciones.
3. No uses toques dobles o largos como única vía: el doble toque es el gesto de activación del lector de pantalla.
4. Evita gestos en los bordes de pantalla que colisionen con los del sistema.

Escalado de texto y disposición

Los sistemas ofrecen un tamaño de texto global (iOS: Ajustes > Pantalla y brillo > Tamaño del texto, y en Accesibilidad hasta tamaños «AX5»; Android: Tamaño de fuente y Tamaño de visualización). La app debe usar las unidades y API escalables (UIFont.preferredFont, estilos de texto de SwiftUI, unidades sp en Android) y disponer la interfaz con restricciones que permitan crecer: textos que pasan a varias líneas, filas de controles que se apilan en vertical, desplazamiento vertical cuando no cabe. Los fallos típicos: textos truncados con «…», botones con el texto cortado, pestañas inferiores ilegibles, altura de celda fija.

Otros principios

• Contraste: igual que en web (4,5:1 texto, 3:1 componentes); añade pruebas con el modo oscuro y con «Aumentar contraste» del sistema.
• Movimiento: respeta «Reducir movimiento» del sistema (2.3.3 Animación por interacciones, nivel AAA pero muy recomendable; 2.2.2 Pausar, detener, ocultar para contenido en movimiento automático).
• Tiempo: cierres de sesión por inactividad con aviso y posibilidad de ampliar (2.2.1).
• Notificaciones y cambios: anunciar cambios de pantalla y mensajes de estado a la tecnología de apoyo (4.1.3 Mensajes de estado).
• Autenticación: 3.3.8 Autenticación accesible (mínimo): permitir biometría y gestor de contraseñas, no exigir memorizar ni transcribir códigos sin alternativa.
• Ayuda y contacto: 3.2.6 Ayuda coherente, en el mismo lugar de cada pantalla.

Resumen

• WCAG2ICT explica cómo aplicar las WCAG 2.2 a apps nativas, y la EN 301 549 v3.2.1 (capítulo 11) lo hace con los criterios de WCAG 2.1; la API de accesibilidad de la plataforma es el equivalente del HTML semántico.
• Orientación libre (1.3.4), texto escalable al 200 % sin pérdida (1.4.4), objetivos de 44 pt/48 dp (más que el mínimo de 2.5.8).
• Todo gesto complejo, de arrastre o de movimiento del dispositivo tiene alternativa de un toque y se expone como acción de accesibilidad.
• Las acciones se ejecutan al levantar el dedo; nada de doble toque o pulsación larga como única vía.
• Contraste, reducir movimiento, tiempo ajustable, mensajes de estado y autenticación accesible se aplican igual que en web.