Accesibilidad en móvil: tamaños, gestos y reflujo que sí importan

La accesibilidad móvil no tiene estándar propio: se aplica WCAG 2.2 a pantallas pequeñas. Tamaño de objetivos, reflujo, gestos, guías de Apple y Android.

info Definición Rápida

La accesibilidad en móvil es la aplicación de las pautas de accesibilidad a apps y sitios en pantallas pequeñas y táctiles. No existe un estándar separado: el W3C indica que la accesibilidad móvil se cubre con las pautas existentes, y WCAG 2.2 es la referencia. En la práctica, eso significa tamaños de toque suficientes, contenido que se reacomoda al ampliar, y alternativas a los gestos.

¿Por qué el móvil es distinto?

En móvil, el usuario interactúa con el dedo, a menudo con una mano, a veces en movimiento y siempre con una pantalla pequeña. El W3C señala que el trabajo sobre móvil atiende cuestiones como las pantallas táctiles, los tamaños de pantalla reducidos, los métodos de entrada (por ejemplo la voz) y el uso en entornos como la luz solar intensa. Un botón de 16 píxeles es fácil de ver y difícil de tocar. Un menú que solo se abre con un arrastre puede ser imposible para alguien con temblor o con una sola mano.

El móvil también trae ayudas integradas: lectores de pantalla (VoiceOver en iOS, TalkBack en Android), aumento del texto del sistema y controles de contraste. Diseñar bien es no cerrarles el paso.

¿Qué tamaño deben tener los objetivos táctiles?

WCAG ofrece dos niveles y las plataformas, sus propias cifras:

Fuente	Valor	Nota
WCAG 2.5.8, Target Size (Minimum), AA	24 × 24 píxeles CSS	Admite objetivos menores con espaciado suficiente
WCAG 2.5.5, Target Size (Enhanced), AAA	44 × 44 píxeles CSS
Apple, guías de accesibilidad	44 × 44 puntos por defecto en iOS y iPadOS; mínimo de 28 × 28	Apple pide acercarse al tamaño recomendado de cada plataforma
Android, ayuda de accesibilidad	Al menos 48 × 48 dp, con 8 dp o más entre objetivos	El área táctil puede extenderse más allá del dibujo, con relleno

El criterio 2.5.8 admite excepciones: objetivos pequeños con espaciado suficiente (un círculo de 24 píxeles centrado en cada uno no debe cruzarse con otro objetivo), una alternativa equivalente en la misma página, enlaces dentro de una frase, controles que determina el navegador y casos en que la presentación es esencial. Y no depende del zoom: ampliar la página no hace que un botón pequeño cumpla. Para el detalle de diseño, mira áreas táctiles.

¿Qué pasa con el reflujo, el texto y la orientación?

El criterio 1.4.10, Reflow (AA), exige presentar el contenido sin pérdida de información ni funcionalidad y sin desplazamiento en dos dimensiones a 320 píxeles CSS de ancho para el contenido que se desplaza en vertical. W3C aclara que equivale a un viewport de 1280 píxeles con zoom al 400 %. En la práctica, el contenido debe apilarse en una columna. Hay excepciones para lo que necesita dos dimensiones para tener sentido, como mapas, diagramas, tablas de datos o juegos.

Para barras y menús fijos, W3C recomienda con fuerza que en viewports pequeños pasen a posición estática, y que no tapen por completo el elemento enfocado. El criterio 1.4.4, Resize Text (AA), pide poder ampliar el texto hasta el 200 % sin pérdida de contenido ni funcionalidad. Apple va en la misma línea: recomienda permitir ampliar el texto al menos un 200 % y adoptar Dynamic Type, el ajuste de tamaño del sistema.

El criterio 1.3.4, Orientation (AA), pide no restringir la vista a una sola orientación, salvo que sea esencial. Quien tiene el teléfono fijado en un soporte puede necesitar el modo horizontal.

¿Cómo se diseñan alternativas a los gestos?

El criterio 2.5.7, Dragging Movements (AA), exige que cualquier funcionalidad con arrastre pueda hacerse con un solo puntero sin arrastrar, salvo que el arrastre sea esencial. Su ejemplo es el deslizador: tocar la pista mueve el control a esa posición.

El criterio 2.5.1, Pointer Gestures (nivel A), pide que las funciones con gestos multipunto o de trayectoria se puedan operar con un solo puntero sin trazar un recorrido. Sus ejemplos oficiales son un carrusel con flechas de avance y retroceso además del deslizamiento, y un mapa con botones de más y menos además del pellizco. Quedan fuera los gestos del sistema o del navegador, como el deslizamiento para volver atrás o el desplazamiento normal de la página. En Android, la documentación añade que puedes exponer a los servicios de accesibilidad una acción personalizada para lo que se hace con arrastrar o deslizar, de modo que TalkBack, Voice Access o Switch Access puedan completarlo. Más detalle en gestos en móvil.

¿Cómo se audita una app móvil?

Una revisión corta, que combina las pautas anteriores:

Toca con una mano, la dominante, en la pantalla principal. Anota lo que no alcanzas o activas por error.
Sube el texto del sistema al máximo y comprueba que nada se corta ni se superpone.
Gira la pantalla y verifica que la tarea sigue siendo posible.
Haz cada tarea sin gestos de arrastre o deslizamiento. Si no puedes, falta una alternativa.
Prueba con VoiceOver o TalkBack: cada control necesita una etiqueta que explique su función. Android pide además etiquetas únicas dentro de una colección. Para organizarlo, mira las pruebas con lectores de pantalla.

Ejemplo

Ejemplo ilustrativo: una app de reservas tiene un calendario que se mueve con deslizamiento horizontal y un botón de cerrar de 18 píxeles en la esquina superior. Al auditar, el equipo detecta tres problemas: el botón no llega al tamaño mínimo ni tiene espaciado suficiente; el calendario no ofrece una alternativa de un toque para cambiar de mes; y con el texto del sistema al máximo, las fechas se salen de la pantalla. La solución: el botón pasa a 44 × 44 píxeles, aparecen flechas para cambiar de mes y el calendario se reorganiza en lista en pantallas estrechas.

¿Cuándo NO basta con esta revisión?

Cuando la app depende de sensores como la cámara o el giroscopio. Hay que probar con dispositivos reales y ofrecer alternativas.
Cuando hay lectores de pantalla en juego. Una revisión visual no reemplaza probar con VoiceOver o TalkBack.
Cuando no hay pruebas con personas con necesidades de acceso. Una auditoría contra criterios es un mínimo, no un sustituto.

Errores comunes

Suponer que el móvil no necesita accesibilidad por ser un dispositivo personal.
Diseñar botones pequeños por estética, sin ampliar el área de toque.
Usar gestos como única forma de operar un contenido.
Olvidar el texto del sistema en su tamaño máximo.
Bloquear la orientación sin que sea esencial.
Probar solo en escritorio con zoom y creer que eso reemplaza una prueba en móvil.

Relacionado en la wiki

Para la base de los criterios, lee WCAG explicado. Si quieres priorizar desde el inicio, el diseño mobile-first ayuda. Y para planear pruebas con usuarios reales, mira pruebas de usabilidad en móvil.

Fuentes

Preguntas frecuentes

¿Existe una norma de accesibilidad solo para móvil?

No. El W3C indica que no tiene pautas separadas para móvil: la accesibilidad móvil se cubre con los estándares existentes, como WCAG 2.2, que aplica a la web móvil, a las apps nativas y a las híbridas. Existe además un borrador informativo, WCAG2Mobile, que explica cómo aplicarlo.

¿Qué tamaño mínimo deben tener los botones en móvil?

WCAG 2.2 (criterio 2.5.8, nivel AA) pide al menos 24 × 24 píxeles CSS, o espaciado suficiente alrededor. El nivel AAA (2.5.5) sube la exigencia a 44 × 44. Apple indica 44 × 44 puntos como tamaño por defecto en iOS y Android recomienda al menos 48 × 48 dp.

¿Qué es el reflujo y por qué importa en móvil?

Es la capacidad de que el contenido se reacomode en una columna sin perder información ni exigir desplazamiento en dos dimensiones. WCAG 1.4.10 (nivel AA) lo pide a 320 píxeles CSS de ancho, equivalente a un viewport de 1280 con zoom al 400 %.

¿Un deslizador se puede usar solo con gestos de arrastre?

No, según WCAG 2.5.7 (nivel AA). Toda funcionalidad que use arrastre debe poder hacerse con un solo puntero sin arrastrar, por ejemplo tocando la pista del deslizador para mover el control a esa posición.

¿Hay que permitir girar la pantalla?

Sí, salvo que una orientación sea esencial. WCAG 1.3.4 (nivel AA) pide que el contenido no restrinja su vista y operación a una sola orientación de pantalla.