Errores en formularios web que impiden completar o gestionar una solicitud

El diseño de formularios web tiene que evitar dos tipos de error. Los que impiden completar el formulario se ven en pantalla: no se entiende qué se pide o el error no se ve. Los que impiden gestionar la solicitud llegan después de «Enviar»: se pierde, llega sin contexto o nadie la revisa.

Las pautas de accesibilidad del W3C (las WCAG 2.2, en inglés) dedican a la entrada de datos su pauta 3.3: ayudar a evitar y corregir los errores. Los dos tipos de error se pueden evitar en el diseño: qué pides, cómo lo colocas, cómo avisas de los errores y adónde va cada solicitud.

Un formulario solo debería pedir lo que necesitas para el siguiente paso que anuncia: antes de añadir un campo, escribe qué decisión tomarás con ese dato. El Reglamento General de Protección de Datos (RGPD) lo llama minimización de datos (artículo 5). Quitar el dato que sirve para asignar la solicitud tampoco ayuda, porque alguien tendrá que llamar para pedirlo.

La guía de Google en web.dev propone el nombre en un solo campo, salvo que haya un buen motivo, y marcar los opcionales si la mayoría son obligatorios. Las WCAG piden que lo que se vuelve a pedir en el mismo proceso se rellene solo o se pueda elegir (criterio 3.3.7), salvo excepciones como la seguridad.

Cada campo de un formulario necesita una etiqueta visible: las WCAG piden etiquetas o instrucciones siempre que haya que introducir datos (criterio 3.3.2). Google añade que sea corta, como «Dirección de correo electrónico», y que el texto de ejemplo de dentro del campo (el placeholder) no haga de etiqueta.

Si el formato es obligatorio, dilo antes del campo y no solo en el mensaje de error. Acepta tildes, dos apellidos o espacios en el teléfono.

La validación de un formulario comprueba los datos antes de aceptarlos. Las WCAG piden identificar el campo con error y describirlo en texto (criterio 3.3.1), y sugerir la corrección si se conoce (criterio 3.3.3), salvo que comprometa la seguridad o el propósito del contenido.

El color solo no basta (criterio 1.4.1): para quien no distingue el rojo del verde, explica Google, un borde rojo y uno verde se ven casi iguales.

Pon cada mensaje junto a su campo y, si se envía con errores, lleva el foco (el campo activo) al primero. Valida también en el servidor.

Un formulario que recoge datos personales tiene que informar al recogerlos. La ley española de protección de datos permite hacerlo en dos capas (artículo 11): una información básica junto al formulario y una dirección electrónica u otro medio para llegar de forma sencilla e inmediata al resto. La básica incluye, al menos, quién es el responsable (y su representante, si lo hay), la finalidad y que se pueden ejercer los derechos de los artículos 15 a 22 del RGPD. Si vas a elaborar perfiles, la básica lo dice y avisa del derecho a oponerse a decisiones automatizadas con efectos jurídicos o de importancia parecida, cuando exista.

La casilla depende de la base legal, el motivo que permite tratar los datos. Si es el consentimiento, tiene que ser libre, específico, informado e inequívoco, por declaración o por una «clara acción afirmativa» (artículo 4 del RGPD). El RGPD dice (considerando 32) que «el silencio, las casillas ya marcadas o la inacción no deben constituir consentimiento». Además (artículo 7), tienes que poder demostrarlo; la petición se distingue del resto y usa un lenguaje claro y sencillo; antes de darlo, la persona sabe que puede retirarlo en cualquier momento, y retirarlo es tan fácil como darlo; y, si condicionas el servicio a usos que no necesita, puede no ser libre.

Para atender una petición de presupuesto puede servir otra base: el tratamiento necesario para aplicar, a petición del interesado, medidas previas a un contrato (artículo 6). El boletín va en casilla aparte; la publicidad por correo electrónico tiene reglas propias, resumidas en cómo diseñar una web B2B, en su apartado de formularios.

La entrega de un formulario termina cuando la solicitud está donde se atiende: un buzón compartido, el CRM (el programa donde ventas sigue cada contacto) o la agenda. Para gestionar la solicitud, esta debe llegar con su página de origen, la hora y lo aceptado, y tener quien la atienda y quien lo haga cuando esa persona falte.

Un buzón personal, una integración sin vigilar o un antispam mal ajustado pueden perder solicitudes sin que nadie lo note. Repite a menudo un envío de prueba y revisa la carpeta de spam. Decide cuánto tiempo las guardas: el RGPD pide conservar los datos «no más tiempo del necesario para los fines del tratamiento» (artículo 5). Para elegir dónde guardarlas, mira cómo elegir un CRM para una pyme; para contar como conversión solo lo que llega, consentimiento y medición de conversiones.

Seguir esta guía no certifica que un formulario sea accesible.

Tampoco que vaya a seguir entregando: un cambio de plugin puede romperlo.

Lo que aquí se dice de las normas de protección de datos las resume y no sustituye a una asesoría legal.

Elige el formulario que más solicitudes debería traerte.

Pruébalo con los pasos de arriba.

Si prefieres revisarlo con nosotros, así trabajamos la mejora de la conversión web.

Publicado el 15 de septiembre de 2026.

Actualizado el 12 de octubre de 2026.

Reescrito y ampliado el 3 de octubre: qué consigue un buen diseño de formularios, el mapa de errores por etapa, qué datos pedir, etiquetas, validación y mensajes de error, aviso de privacidad y consentimiento, envío y confirmación, entrega y gestión, protocolo de prueba, un ejemplo con datos inventados y la lista de comprobación. Nuevos: la disposición de los campos y el uso en el móvil, y las preguntas frecuentes.

Añadidos el 12 de octubre: dos esquemas, uno con qué hacer según el estado del envío y otro con los campos del ejemplo, antes y después.