Usabilidad móvil: prueba el recorrido completo

Mejora de interfaces · Nivel inicial e intermedio

Que una página encaje en una pantalla pequeña no garantiza que sea cómoda. En un móvil hay menos espacio visible, teclado virtual e interrupciones. La revisión debe comprobar si una persona consigue el objetivo y puede retomarlo cuando algo cambia.

Prueba el recorrido completo

Escoge una tarea concreta, como encontrar un curso, consultar su horario e iniciar una inscripción. Incluye menú, búsqueda, detalle, formulario, error y confirmación. Usa un teléfono real para observar teclado, pulsación, desplazamiento y orientación. El simulador del navegador sirve para explorar anchos y detectar fallos de composición, pero no reproduce por completo un dispositivo.

Registra modelo o dimensiones relevantes, sistema, navegador, orientación, tamaño de texto y condiciones de conexión. Si una incidencia solo aparece tras abrir el teclado, una captura de la página inicial no permitirá reproducirla.

Texto, jerarquía y espacio visible

• Sitúa la respuesta principal antes de información secundaria. Un encabezado decorativo no debería obligar a desplazarse varias pantallas para encontrar el contenido.
• Comprueba el zoom y el aumento del texto: no debe desaparecer la acción principal ni quedar contenido cortado.
• Evita barras fijas que consuman casi toda la altura disponible, especialmente en horizontal o con teclado abierto.
• Mantén tablas y código dentro de regiones con desplazamiento controlado cuando necesitan dos dimensiones. El resto de la página debe adaptarse.
• Conserva títulos, etiquetas y unidades al reorganizar datos; apilar celdas sin contexto puede volver una tabla incomprensible.

Revisa la redistribución a una anchura equivalente a 320 píxeles CSS en contenido de lectura horizontal, considerando las excepciones de WCAG para elementos que requieren dos dimensiones. No es una medida física del teléfono. Consulta la guía de fundamentos de accesibilidad para criterios y pruebas de zoom.

Objetivos táctiles: tamaño y separación

Prueba si se puede activar cada control sin tocar el vecino. Importa el área interactiva completa, no solo el icono visible. Una lupa de 16 píxeles puede estar dentro de un botón mayor; una etiqueta visual grande puede tener una zona pulsable demasiado pequeña.

WCAG 2.2, criterio 2.5.8 de nivel AA, establece un tamaño mínimo de 24 × 24 píxeles CSS o las condiciones de separación previstas, con excepciones como enlaces dentro de texto, controles equivalentes y otros casos definidos. El criterio 2.5.5 de nivel AAA usa 44 × 44 y sus propias excepciones. Como decisión de diseño, apunta a áreas cómodas mayores cuando el espacio y la tarea lo permitan; no presentes 44 como una obligación universal de nivel AA.

Caso didáctico: en una lista de favoritos, «Ver producto» y el botón para eliminar están muy próximos. Aumentar ambos sin separar sus áreas puede mantener el riesgo. Prueba la pulsación y ofrece recuperación de una eliminación accidental cuando tenga sentido.

Menú, búsqueda y filtros

Mantén visibles los nombres de las opciones importantes. Un icono sin texto puede ahorrar espacio a costa de comprensión. Al abrir el menú, comprueba el estado, el cierre, el orden de teclado y el retorno al contenido. No uses un menú de aplicación ARIA para una navegación convencional sin una necesidad real.

En filtros, muestra cuáles se aplican y permite retirarlos. Al volver de una ficha, conservar la selección y la posición puede evitar repetir trabajo. Si no hay resultados, explica qué filtro puede cambiarse y ofrece una acción concreta. Comprueba también el botón Atrás del navegador: las expectativas incluyen ese control.

Formularios con el teclado abierto

• Solicita solo los datos que necesita la tarea en ese momento.
• Usa etiquetas persistentes: el texto de ejemplo dentro del campo no las sustituye.
• Aprovecha tipos de campo y autocompletado adecuados sin impedir pegar datos.
• Para códigos que pueden empezar por cero, no asumas que son cantidades numéricas.
• Comprueba que el teclado no oculta instrucciones, errores o el botón necesario.
• Conserva datos válidos tras un error y permite corregirlo sin empezar de nuevo.

Después de enviar, muestra qué se ha recibido y cuál es el siguiente paso. Evita que una respuesta lenta provoque múltiples envíos sin control. Las técnicas de etiquetas, errores y estados están desarrolladas en formularios accesibles y comprensibles.

Orientación, conexión e interrupciones

Prueba vertical y horizontal; no fuerces una orientación salvo que sea esencial para la función. Simula una conexión lenta para identificar esperas, luego comprueba qué ocurre cuando falla una petición. La interfaz debe distinguir entre «aún cargando», «sin resultados» y «no se pudo conectar».

Interrumpe de forma controlada una tarea de prueba: cambia de pestaña, vuelve atrás o deja que caduque una sesión preparada. Observa si se pierde información, si se explica lo ocurrido y si hay una vía de recuperación. No des por hecho que un teléfono siempre implica una conexión mala ni que todos sus usuarios utilizan los dedos; incluye teclado y tecnologías de apoyo cuando corresponda.

Guarda evidencia y repite la comprobación

Describe el paso exacto, el estado del teclado, la orientación y la consecuencia. Ejemplo didáctico: «Al enfocar el último campo, la barra inferior tapa el error y el botón; no se puede continuar sin cerrar el teclado». Después de corregir, repite ese estado y comprueba la versión de escritorio. No cierres un hallazgo solo porque la portada se vea bien.

Fuentes y siguiente paso

• W3C: tamaño mínimo del objetivo, 2.5.8
• W3C: tamaño mejorado del objetivo, 2.5.5
• W3C: redistribución del contenido
• W3C: orientación
• Lista práctica de revisión
• Investigar el rendimiento con PageSpeed Insights