Cómo comprobar que el formulario de tu web funciona bien en el móvil

Para comprobar un formulario en móvil, recorre el proceso completo: escribe, corrige un error, envía una solicitud controlada y verifica qué ocurrió en el destino previsto. Un botón que responde o un aviso de éxito solo muestran una parte del recorrido. Esta guía te ayuda a convertir cada comprobación en un resultado que puedas revisar con quien mantiene la web.

Prepara una prueba controlada

Acuerda primero dónde vas a probar y quién comprobará el resultado. Lo más sencillo es un entorno de pruebas que recoja las solicitudes sin enviarlas a clientes ni activar procesos comerciales. Si hace falta una prueba en la web pública, coordínala con su responsable, usa un buzón propio destinado a pruebas y confirma qué automatizaciones puede activar.

Prepara un mensaje reconocible, por ejemplo «PRUEBA FORMULARIO F-01, acordada con el responsable». Utiliza datos ficticios en el entorno de pruebas y evita introducir información de clientes. Anota la hora y la página para localizar después esa solicitud. No necesitas enviar muchas veces: empieza por un recorrido y registra lo que encuentres.

Antes de escribir, revisa qué se pide y para qué. La guía de formularios de W3C recomienda limitar los campos a la información necesaria para completar el proceso. Si no puedes explicar la utilidad de un campo, apúntalo para revisarlo con el negocio.

Revisa las etiquetas y el teclado

Abre el formulario en un móvil y comprueba que cada campo tiene una etiqueta comprensible y asociada a su control, como explica W3C en su guía de etiquetado. Debes poder distinguir qué dato falta aunque ya hayas empezado a rellenarlo.

El texto de ejemplo que desaparece al escribir se llama placeholder. MDN advierte que no sustituye a la etiqueta. Haz una prueba sencilla: escribe parte del mensaje, vuelve a otro campo y comprueba si aún sabes qué información corresponde a cada uno.

Toca el campo de email y observa si el teclado facilita introducir una dirección. La configuración del campo puede sugerir un teclado adecuado; MDN explica que inputmode es una indicación para el navegador, no una validación del dato. Comprueba el comportamiento en el dispositivo disponible: no deduzcas que una dirección es correcta por el teclado que aparece.

Con el teclado abierto, llega al último campo y al botón de envío. Anota si puedes ver lo que escribes, corregir una palabra y desplazarte sin que un aviso fijo tape los controles. Si hay un selector o una casilla, inclúyelos en el recorrido.

Provoca un error y comprueba la ayuda

En el entorno acordado, deja vacío un campo obligatorio. Después prueba un email incompleto, como «prueba@», y observa la respuesta. La guía de validación de W3C recoge comprobaciones de campos obligatorios y formatos habituales. Como aclara MDN sobre los campos de email, un formato aceptado no demuestra que exista el buzón.

El aviso debería identificar el campo y explicar cómo corregirlo. W3C desarrolla estas pautas en su guía de notificaciones. «Revisa el email: falta completar la dirección» es un ejemplo de ayuda más concreta que «Error». Comprueba también que puedes encontrar el problema sin depender únicamente de un borde de color.

Corrige solo el dato señalado. Para los campos corrientes de contacto, revisa si siguen disponibles el nombre y el mensaje que ya eran válidos. Si todo se borra, registra exactamente qué acción lo provocó. Así podrás pedir una corrección reproducible y comprobarla después.

Observa la espera y la confirmación

Completa la prueba y pulsa enviar una vez. Durante la espera debe quedar claro que la operación está en curso y cuál es el resultado al terminar. Si el botón parece no responder, anota lo que ves antes de insistir: repetir pulsaciones puede dificultar saber qué envío estás comprobando.

Los avisos que aparecen sin cargar otra página también necesitan ser perceptibles para quienes usan tecnologías de asistencia. El criterio de mensajes de estado de W3C incluye situaciones de espera, error y finalización. Pide que su funcionamiento se compruebe con un lector de pantalla; ver un texto nuevo no permite dar por hecha esa parte de la revisión.

Para revisar la prevención de duplicados, pide al responsable técnico que simule una respuesta lenta en pruebas y compruebe qué sucede al repetir el envío. El resultado esperado es una única solicitud para la misma acción. Si hay un fallo, el formulario debe explicar cómo continuar sin afirmar que ha recibido algo que no puede confirmar.

La ilustración muestra dos estados de un formulario ficticio: «Revisa el email» y «Solicitud registrada». Sirve para explicar la diferencia entre corregir un dato y confirmar el registro; ese segundo aviso, por sí solo, no acredita que se haya entregado un correo.

Comprueba qué llegó y dónde

Separa tres comprobaciones. Primero, qué confirmó la página. Segundo, si la solicitud aparece en el destino acordado, que puede ser un panel de gestión o un buzón. Tercero, quién la atenderá. Son preguntas distintas y conviene dejar una evidencia de cada una, usando la referencia de prueba y sin copiar datos personales.

Si el recorrido incluye email, la aceptación por un servidor de correo puede ir seguida de un fallo de entrega: esa posibilidad está contemplada en la especificación SMTP. Por eso, pide a la persona responsable que confirme la llegada al buzón previsto o revise el registro de entrega. No des por recibido el correo solo porque la web muestre un aviso.

Si el mensaje no aparece, entrega al responsable la página utilizada, la hora y la referencia de prueba. Evita cambiar varias cosas a la vez o repetir envíos sin control. Si sí aparece, comprueba que conserva el contenido esperado y que permite identificar cómo responder a la consulta. No hace falta enviar una respuesta real para dejar documentado este paso.

Repite el recorrido con teclado y otros tamaños

En escritorio, utiliza Tab y Mayús+Tab para recorrer los controles. El orden de foco debe permitir seguir una secuencia comprensible y el indicador de foco debe ser visible. Comprueba también que puedes operar los controles sin ratón. Anota dónde se pierde el recorrido, si ocurre.

Después, aumenta el texto y repite la lectura en una ventana estrecha y otra amplia. Busca etiquetas cortadas, errores fuera de la vista y botones ocultos. La emulación ayuda a revisar tamaños; el móvil real permite observar el teclado y la interacción táctil. Para ampliar estos criterios generales puedes consultar nuestra guía de diseño pensado para móvil.

Guarda una ficha que permita repetir la prueba

Copia estos apartados en un documento y completa una ficha por incidencia. Es una herramienta de trabajo para esta revisión, no un certificado de accesibilidad ni una auditoría completa del sistema.

• Identificación: URL, fecha, hora, dispositivo, navegador y referencia de prueba.
• Paso: acción concreta realizada, con los datos ficticios necesarios para reproducirla.
• Resultado esperado: qué debería poder hacer la persona y qué debería registrar el sistema.
• Resultado observado: qué ocurrió realmente, incluido el texto del aviso o una captura sin datos personales.
• Destino: solicitud localizada, no localizada o pendiente de comprobar; indicar quién puede verificarlo.
• Seguimiento: corrección acordada, persona responsable y resultado al repetir el mismo paso.

Ejemplo ficticio de ficha, sin una prueba real detrás: F-01, formulario de pruebas, email incompleto. Esperado: identificar el campo, explicar la corrección y conservar el mensaje. Observado en este ejemplo: aparece un aviso general y se vacía el mensaje. Revisión pendiente: localizar el error junto al campo y conservar el texto válido; después repetir F-01.

Si tu formulario da problemas en móvil, puedes contarnos qué ocurre y en qué paso. Una ficha breve y una captura ayudan a entenderlo. Nuestro servicio de diseño web es el punto de partida para valorar las necesidades de tu proyecto.