Gestos en móvil: descubribilidad y alternativas
Cómo diseñar gestos en móvil que el usuario descubra, con alternativas de un solo toque según WCAG 2.5.1, y cuándo un gesto no debe ser la única vía.
¿Qué es un gesto y qué lo hace difícil de descubrir?
Los gestos pesan más en productos mobile first, donde casi todo ocurre con el pulgar. Un gesto no tiene forma visible. Un botón se ve y se toca; un deslizar lateral para borrar una tarea, o un pellizco para acercar un mapa, solo funcionan si el usuario sabe que existen. Esa es la diferencia central: el gesto añade una capa de conocimiento que el usuario tiene que traer consigo o aprender. Apple lo plantea así en sus guías: un gesto propio debe ser descubrible, fácil de hacer, distinto de otros gestos y no ser la única forma de realizar una acción importante.
Por eso el primer criterio para usar un gesto es sencillo: ¿el usuario llega a la función sin haberlo aprendido antes? Si la respuesta es no, el gesto tiene que ser la segunda vía, nunca la primera.
¿Qué dice WCAG sobre los gestos?
El criterio 2.5.1 (Pointer Gestures, nivel A) es el que más importa aquí. Su texto dice, en esencia, que toda funcionalidad que use gestos de varios puntos o basados en trayectoria debe poder operarse con un solo puntero, sin necesidad de un gesto de trayectoria, a menos que el gesto sea esencial.
Cuatro ideas clave:
- El gesto esencial es una excepción estrecha. Es el que, si se quitara, cambiaría de forma fundamental la función. El ejemplo de la fuente es introducir una firma, mientras que confirmar tu identidad no tiene por qué ser un trazo. Un pellizco para zoom no es esencial, porque el mismo resultado puede lograrse con botones.
- Solo cubre los gestos que define el autor del contenido. Los gestos del sistema operativo, del navegador o de las tecnologías de apoyo, como deslizar hacia abajo para ver las notificaciones, quedan fuera del criterio.
- El arrastre tiene su propio criterio. Los movimientos de arrastre se evalúan en el criterio 2.5.7 (Dragging Movements, nivel AA), no en el 2.5.1. Una alternativa al arrastre tampoco puede depender solo de un gesto de trayectoria, como deslizar.
- El fallo es documentado. La técnica de fallo F105 describe justamente una función que solo se activa con un gesto de trayectoria, sin una alternativa de un solo puntero.
La intención del criterio es ayudar a personas que no pueden hacer gestos con precisión y a quienes usan herramientas adaptadas, como un puntero de cabeza, un sistema de seguimiento ocular o un emulador de ratón controlado por voz. Por eso la alternativa no es un detalle de compatibilidad: es parte del diseño.
¿Por qué le importa a un diseñador junior?
Porque los gestos son una de las decisiones que más se toman “para que quede moderno” y menos se revisan después. Un junior que propone un deslizar para eliminar, sin un botón visible, está diseñando una función escondida. Y las funciones escondidas se usan poco, incluso cuando funcionan bien.
Además, un gesto es un obstáculo habitual para quien usa un puntero adaptado o no puede hacer trazos precisos. Revisar la alternativa de un solo toque es, en la práctica, probar la accesibilidad del flujo. Una forma de empezar es con las pruebas con lectores de pantalla.
¿Cómo diseñar la alternativa y la descubribilidad?
- Ofrece siempre una vía visible. Si el usuario puede eliminar una tarea deslizando, también debe haber un botón de eliminar, en el menú de la tarea o en el detalle. Ese botón también debe respetar las áreas táctiles mínimas.
- Usa pistas visuales. Una tarjeta que asoma un poco por el borde sugiere que hay más contenido a los lados. Una barra fina en la parte inferior sugiere que la pantalla se puede desplazar. Son pistas, no garantías.
- Haz los gestos consistentes en toda la app. Si deslizar a la izquierda borra en una pantalla y archiva en otra, el usuario no puede aprender el patrón.
- Evita chocar con los gestos del sistema. Apple pide no definir gestos propios que entren en conflicto con los que abren la interfaz del sistema, porque la gente espera que esos controles funcionen siempre igual. Un gesto de la app que nace en el borde de la pantalla compite con ellos.
- Documenta el gesto en el onboarding y en el menú de ayuda. Un gesto que se explica una vez y después se olvida sigue siendo útil si hay una vía visible.
Una prueba rápida de descubribilidad: da la tarea a una persona sin ninguna guía y observa si encuentra el gesto o la vía visible en un minuto. Si no lo logra, el gesto está escondido y la vía visible necesita más peso en el diseño.
WCAG da dos ejemplos claros. Un mapa que permite zoom con pellizco ofrece además botones de más y menos. Y un carrusel de noticias que responde a deslizamientos rápidos tiene botones de avance y retroceso que funcionan con un solo toque.
¿Cuándo un gesto sí conviene?
- Cuando el gesto es parte de la función y no solo un atajo. Dibujar o firmar son ejemplos donde el gesto es el contenido.
- Cuando es un atajo para usuarios frecuentes y existe la vía visible. Apple lo formula como usar gestos de atajo para complementar los estándar, no para reemplazarlos: un deslizar para archivar en una app de correo funciona si el botón de archivar sigue en el menú.
- Cuando el sistema operativo ya establece el patrón. Apple recomienda no usar un gesto conocido para una acción exclusiva de tu app, ni inventar un gesto nuevo para una acción estándar como pulsar un botón o desplazar una lista.
Una pregunta sencilla ayuda a decidir: si el gesto desapareciera, ¿alguien lo echaría de menos? Si no, es decoración y puede quitarse.
En cambio, no conviene un gesto como única vía para una acción destructiva, ni un gesto complicado que requiera dos dedos y una trayectoria para algo que se hace cien veces al día.
Ejemplo
Ejemplo ilustrativo: una app de notas en la que cada nota se borra deslizando a la izquierda.
- Problema: los usuarios nuevos no saben que existe el gesto, y los que usan lector de pantalla no pueden borrar notas.
- Corrección: el mismo deslizar sigue existiendo, pero cada nota tiene un menú de tres puntos con “Eliminar”. El menú está visible y se puede operar con un toque.
- Comprobación: se prueba la acción con un lector de pantalla y con una sola mano. Se confirma que el borrado desde el menú pide confirmación, porque es la acción destructiva.
Ambas vías llevan a la misma confirmación, así que hay un solo comportamiento que probar y explicar en el onboarding. El gesto no desaparece; deja de ser el único camino. Así el flujo funciona para todas las personas, no solo para las que descubren el gesto.
Errores comunes
- Poner el gesto como única forma de realizar una acción.
- Usar pellizco para zoom en un mapa sin botones de más y menos.
- Crear gestos distintos para la misma acción en pantallas diferentes.
- Asignar gestos a zonas donde el sistema operativo ya actúa.
- Diseñar gestos complicados para funciones que el usuario usa a diario.
- Probar los gestos solo con el ratón o en el simulador, sin un móvil real.