Accesibilidad en aplicaciones móviles: guía completa en la práctica

Hablar de accesibilidad es fácil. Implementar la accesibilidad en una aplicación real, con plazos ajustados, deuda técnica y diseño complejo, es otra historia.

Esta guía "en la práctica" está enfocada en desarrolladores móviles (Android/iOS/Flutter/React Native) y diseñadores que necesitan ensuciarse las manos hoy. Saltemos la filosofía y vayamos directamente al flujo de trabajo de implementación.

El “kit de supervivencia” de accesibilidad móvil

Antes de escribir código, necesita las herramientas adecuadas para realizar pruebas. Sin ellos, estás programando en la oscuridad.

Escáner de accesibilidad: aplicación de Google disponible en Play Store. Toma una captura de pantalla de tu pantalla y sugiere correcciones (aumentar texto, contraste, área táctil).
VoiceOver (iOS) / TalkBack (Android): aprende gestos básicos.
- Deslizar hacia la derecha: Siguiente elemento.
- Deslizar hacia la izquierda: Elemento anterior.
- Doble toque: Activar/Hacer clic.
Simulador de daltonismo: aplicaciones como "Sim Daltonism" (Mac/iOS) te permiten mirar la pantalla de tu aplicación como si tuvieras diferentes tipos de daltonismo.

Lista de verificación de implementación práctica

1. Orden de enfoque (orden transversal)

El lector de pantalla lee la pantalla de arriba a abajo y de izquierda a derecha (en idiomas occidentales). Pero los diseños complejos pueden estropear esto.

Problema: El lector lee el pie de página antes del contenido principal.
Solución práctica:
- Android: Utilice android:accessibilityTraversalBefore y android:accessibilityTraversalAfter para forzar el orden lógico si el XML está fuera de orden visual.
- iOS: Ajuste la matriz accessibilityElements en su controlador de vista.

2. Agrupación de contenidos (Agrupación)

Imagine una ficha de producto con: [Foto de zapatillas] [Nombre: Nike Air] [Precio: R$ 500]. Si el lector se centra en cada artículo por separado, el usuario debe "deslizar" 3 veces para comprender un solo producto. Esto es agotador.

Solución Práctica: Agrupar el contenedor.
- Flutter: Envuelva el widget de tarjeta en un Semantics(container: true, label: "Tênis Nike Air, preço 500 reais") y oculte los hijos semánticos (excludeSemantics). Por lo tanto, el foco es único en toda la tarjeta.

3. Fuentes dinámicas (tipo dinámico)

El usuario aumentó la fuente en la configuración del celular porque tiene presbicia (vista cansada). ¿Tu aplicación respeta esto o lo rompe todo?

Práctica: Nunca establezca tamaños de fuente en píxeles fijos (px).
- Android: Utilice sp (píxeles independientes de la escala).
- iOS: Utilice fuentes dinámicas (UIFont.preferredFont(forTextStyle: .body)).
- React Native: Evite limitar numberOfLines={1} en textos importantes. Deje que el texto se ajuste si la fuente aumenta.

4. Colores y contraste (modo oscuro)

La accesibilidad también tiene que ver con el confort visual.

Práctica: prueba tu aplicación en modo oscuro y modo claro. El texto gris claro que se ve hermoso sobre un fondo blanco puede desaparecer sobre un fondo negro si no usa colores semánticos del sistema (por ejemplo, SystemGray en iOS) en lugar de colores hexadecimales codificados.

5. Tocar objetivos

El botón parece grande, pero solo se puede hacer clic en el ícono de 24 píxeles en el medio.

Práctica: Utilice las herramientas "Depurar pintura" o "Mostrar límites de diseño" en las Opciones de desarrollador de Android para ver el tamaño real del cuadro en el que se puede hacer clic. Si es inferior a 48 dp, aumente el relleno interno del componente.

Corriente de desarrollo accesible (DoD)

Para garantizar que la accesibilidad ocurra en la práctica, incluya estos elementos en su “Definición de Hecho” para cada tarea:

¿Todos los elementos interactivos tienen etiquetas?
¿Navegaré por toda la función usando solo el teclado/lector de pantalla?
¿El contraste de color pasa la prueba WCAG AA?
Si aumentamos la fuente del sistema, ¿el diseño se adapta (desplaza) o corta el texto?

Accesibilidad en WebViews (¡Cuidado!)

Muchas aplicaciones son híbridas y cargan páginas web dentro de ellas.

El peligro: La accesibilidad (TalkBack/VoiceOver) nativa del teléfono celular no siempre se comunica bien con el HTML de WebView si no está bien hecho.
La práctica: si se utilizan WebViews, el sitio web cargado DEBE ser accesible (HTML semántico, etiquetas ARIA). La aplicación nativa no puede "arreglar" mágicamente HTML incorrecto.

Conclusión

La accesibilidad en la práctica tiene menos que ver con heroísmo que con hábito. Está creando el reflejo muscular de sumar contentDescription cada vez que agregas ImageView. Es una costumbre probar con TalkBack activado durante 2 minutos antes de enviar la solicitud de extracción.

Pequeñas acciones diarias crean un producto sólido. Comience hoy, en la siguiente pantalla codificará.