Respuesta corta: la validación de formularios comprueba lo que la gente escribe antes de aceptar el formulario. Comprueba en el navegador para responder rápido y otra vez en el servidor por seguridad. Muestra cada error con texto junto a su campo, cuando la persona lo termina, y márcalo con aria-invalid para los lectores de pantalla.
Para qué sirve la validación de formularios
La validación detecta campos obligatorios vacíos y datos con un formato incorrecto antes de que te lleguen. MDN cita los mensajes del propio navegador, como «Este campo es obligatorio» e «Introduce una dirección de correo electrónico válida».
El criterio 3.3.1 de las WCAG, de nivel A, trata los errores que se detectan de forma automática. Hay que identificar el campo con error y describir el error con texto. Nuestra guía del formulario de contacto explica qué campos hacer obligatorios.
Navegador, script y servidor
| Dónde se comprueba | Qué hace | Qué conviene saber |
|---|---|---|
| En el navegador | required y type="email" frenan el envío con el mensaje del navegador | Es rápido, pero MDN advierte que es demasiado fácil de eludir |
| En tu propio script | Muestra tus mensajes junto a los campos y marca aria-invalid | Añade un estilo y un mensaje que diga cómo corregirlo |
| En el servidor | Vuelve a comprobar los datos antes de guardarlos | Las comprobaciones del navegador solas no dan seguridad, según el W3C |
De las páginas de MDN sobre validación en el lado del cliente y aria-invalid y del tutorial de formularios del W3C, consultadas el 4 de noviembre de 2026.
MDN advierte que los usuarios malintencionados pueden enviar datos incorrectos a tu servidor, porque la validación en el navegador es demasiado fácil de eludir.
Cómo escribir los mensajes de error
NN/g recomienda mostrar cada mensaje debajo o al lado del campo con error. El mensaje debe ser explícito, fácil de entender, educado y preciso, y dar un consejo útil.
El criterio 3.3.3, de nivel AA, pide sugerir una corrección cuando la conoces, salvo que eso ponga en riesgo la seguridad o el propósito del contenido. «Escribe un correo como nombre [at] ejemplo.com» ayuda más que «Dato no válido».
NN/g señala que el rojo es el color que más se asocia a los errores, y que un icono ayuda a quien no distingue los colores. El W3C acepta el color o una imagen además del texto, nunca en su lugar.
Cuándo mostrar el error
NN/g recomienda la validación en línea: en cuanto alguien termina un campo, aparece cerca un aviso si el campo tiene un error. También desaconseja mostrar un error antes de que la persona termine con el campo.
Algunas comprobaciones solo pueden hacerse después de enviar el formulario. En ese caso, muestra cada mensaje junto a su campo y haz que los campos con error sean fáciles de encontrar.
Los errores y los lectores de pantalla
Un borde rojo no le dice nada a quien no lo ve. MDN pide que tus propios scripts de validación marquen con aria-invalid los campos con error, junto con un estilo visible y un mensaje que explique cómo corregir el error.
MDN también indica que no marques con aria-invalid un campo obligatorio vacío hasta que la persona intente enviar el formulario. Sugiere enlazar el mensaje con aria-errormessage. En nuestra guía de aria-label verás cómo reciben su nombre los campos.
Cómo añadir validación a un formulario
- Marca los campos obligatorios en su etiqueta visible y con el atributo required.
- Usa tipos de campo como type="email" para que el navegador haga las comprobaciones básicas.
- Vuelve a comprobar los mismos datos en el servidor antes de guardarlos.
- Muestra cada error con texto junto a su campo, cuando la persona lo termina.
- Explica cómo corregir el problema, con un ejemplo cuando ayude.
- Marca con aria-invalid los campos con error y enlaza cada uno con su mensaje; espera a un envío para marcar los obligatorios vacíos.
- Quita las marcas cuando el campo se corrige, y prueba todo el formulario con el teclado.
Cómo avisa de los errores nuestro formulario
El 4 de noviembre de 2026 revisamos nuestro formulario de contacto en sus dos idiomas, a tamaño de computadora y de teléfono. Ningún mensaje salió del navegador de prueba. Pulsamos «Enviar mensaje» con el nombre, el teléfono y el correo vacíos.
Cada uno de esos campos mostró su mensaje debajo, y el foco pasó al primero. Con la versión anterior de nuestro formulario, nada le decía a un lector de pantalla qué campos estaban mal. Cuando un envío fallaba, el foco del teclado también volvía a la página.
Tras el cambio que hicimos ese día, cada campo con error lleva aria-invalid y apunta a su mensaje con aria-describedby. Al escribir un correo válido, ese campo perdió sus marcas y los otros dos las mantuvieron. Cuando un envío falla, el foco se queda en el botón, y una línea dice «No se pudo enviar. Inténtalo de nuevo».
Antes de publicar
- Los campos obligatorios lo dicen en su etiqueta.
- Cada error aparece con texto junto a su campo.
- Ningún error aparece mientras alguien todavía escribe.
- Los campos con error llevan aria-invalid y apuntan a su mensaje.
- El servidor vuelve a comprobar los datos.
- Un envío fallido lo dice con texto.
RecuerdaUn mensaje de error es parte del formulario. Ponlo junto al campo, di cómo corregir el problema y asegúrate de que también llegue a los lectores de pantalla.
Hacemos formularios así en nuestro servicio de diseño web. Nuestra guía de las WCAG 2.2 explica el resto del estándar de accesibilidad.
Respuestas rápidas sobre la validación de formularios
¿Qué es la validación de formularios?
Comprobar lo que alguien escribió antes de aceptar el formulario: que los campos obligatorios estén llenos y que un correo o una fecha tengan el formato correcto. Si algo falla, el formulario dice qué campo está mal y cómo arreglarlo.
¿Valido en el navegador o en el servidor?
En los dos. Las comprobaciones del navegador dan una respuesta rápida, pero MDN advierte que son muy fáciles de saltar. El W3C añade que solas no hacen seguro un formulario, así que los datos también se comprueban en el servidor.
¿Cuándo debe aparecer un mensaje de error?
Cuando la persona termina un campo, no mientras todavía escribe. NN/g recomienda la validación en línea cuando el campo está completo. MDN añade que un campo obligatorio vacío no se marca con aria-invalid hasta que la persona intenta enviar el formulario.
¿Dónde va el mensaje de error?
Junto al campo que tiene el problema, normalmente debajo. NN/g dice que el mensaje debe ser explícito, educado y preciso, y dar un consejo útil. Las WCAG piden que el error se describa con texto, no solo con color.
¿Cómo sabe un lector de pantalla que un campo tiene un error?
Marca el campo con aria-invalid="true" y enlázalo con su mensaje de error. MDN pide que tus propios scripts de validación añadan aria-invalid junto con un estilo visible y un mensaje que explique cómo corregir el error.
Fuentes
Consultadas el 4 de noviembre de 2026. MDN Web Docs: Validación de formularios en el lado del cliente. En inglés, Iniciativa de Accesibilidad Web del W3C: Understanding SC 3.3.1 Error Identification (Level A), Understanding SC 3.3.3 Error Suggestion (Level AA) y el tutorial de formularios Validating Input; MDN Web Docs: ARIA: aria-invalid attribute; Nielsen Norman Group: 10 Design Guidelines for Reporting Errors in Forms. Nuestro caso: el formulario de contacto de nuestra web, revisado el 4 de noviembre de 2026.