Pulsas «Enviar» y el formulario no avanza. Aparece un borde rojo alrededor del correo. ¿Falta la dirección, tiene un formato incorrecto o el servidor ha rechazado la solicitud? Para el desarrollador, la validación puede ser un simple valor booleano. Para la persona que intenta contactar, es el momento en que toda la tarea queda bloqueada.
Un mensaje accesible no se limita a señalar un valor incorrecto. Explica el problema, lo relaciona con el campo correspondiente y ayuda a solucionarlo. Necesitamos texto claro, HTML adecuado y una gestión coherente del foco.
Empieza por el mensaje, no por JavaScript
«Dato no válido» ofrece poca ayuda. Si el campo está vacío, pide que se complete; si el formato no es correcto, ofrece un ejemplo concreto. Los criterios WCAG 2.2 3.3.1 y 3.3.3 abordan la identificación de errores mediante texto y las sugerencias de corrección cuando proceden. Un borde de color no es suficiente. Este ejemplo no demuestra la conformidad de todo un formulario.
Asocia el mensaje al campo adecuado
Utiliza una etiqueta visible, las restricciones HTML nativas y un elemento de error relacionado con el campo mediante aria-describedby. Basta con un único campo para observar el funcionamiento.
<form id="contact" novalidate>
<label for="email">Correo electrónico (obligatorio)</label>
<input id="email" name="email" type="email"
required aria-describedby="email-error">
<p id="email-error"></p>
<button type="submit">Enviar</button>
</form>required indica que el campo es obligatorio y type=email activa las comprobaciones nativas del formato. novalidate desactiva los mensajes interactivos del navegador al enviar, por lo que exige una alternativa accesible.
Aprovecha las comprobaciones del navegador
La API Constraint Validation distingue entre un campo obligatorio vacío (valueMissing) y un correo mal formado (typeMismatch). No hace falta crear una expresión regular nueva para cada campo habitual.
const form = document.querySelector('#contact');
const email = document.querySelector('#email');
const error = document.querySelector('#email-error');
function validateEmail() {
const message = email.validity.valueMissing
? 'Introduce tu correo electrónico.'
: email.validity.typeMismatch
? 'Introduce una dirección válida, por ejemplo nombre@empresa.es.'
: '';
error.textContent = message;
if (message) email.setAttribute('aria-invalid', 'true');
else email.removeAttribute('aria-invalid');
return message === '';
}
form.addEventListener('submit', (event) => {
event.preventDefault();
if (!validateEmail()) {
email.focus();
return;
}
// Example ends here: implement server-side processing.
});
email.addEventListener('input', () => {
if (email.getAttribute('aria-invalid') === 'true') validateEmail();
});El código muestra cómo validar, pero no envía datos. La utilización de las API se ha contrastado con la documentación; no se ha probado el formulario completo en distintos navegadores ni lectores de pantalla. Superar la validación del cliente no significa que el servidor haya recibido nada.
¿Cuándo debe aparecer el error?
Avisar con cada pulsación puede molestar a quien todavía está escribiendo. En este ejemplo, los errores aparecen al intentar enviar y se actualizan al corregir un campo que ya estaba marcado. Es una opción que debe evaluarse con usuarios. Los formularios largos pueden necesitar un resumen enlazado y anuncios apropiados para tecnologías de asistencia.
El navegador no es la barrera de seguridad
Es posible eludir las comprobaciones del cliente. Valida también los datos en el servidor. Si falla el procesamiento, conserva los valores correctos y explica el problema. Muestra el éxito solo cuando el servidor haya aceptado el envío. El W3C distingue entre mensajes de un campo y la respuesta general del formulario.
Comprueba que la persona puede continuar
Envía el formulario vacío y después introduce y corrige una dirección incorrecta. Comprueba que el mensaje desaparece y el foco se comporta de forma comprensible. Repite con teclado, zoom, pantalla estrecha y lector de pantalla; simula también un fallo del servidor. Documenta las condiciones. Una herramienta automática no demuestra por sí sola que todo el proceso sea accesible.
Para revisar toda la experiencia, consulta las siete comprobaciones de un formulario accesible. Nuestro patrocinador explica BlazeForce Forms y la gestión de envíos (en inglés); aplica los mismos principios a cualquier plugin.
La mejor validación permite terminar la tarea
Para el software, validar significa comprobar reglas. Para la persona, significa entender el error y completar su consulta. Convierte la corrección de los errores en un criterio de aceptación, en lugar de dar por terminado el trabajo al dibujar un borde rojo.
Fuentes
- W3C WAI — Validating Input
- W3C WAI — User Notifications
- WCAG 2.2 — Error Identification
- WCAG 2.2 — Error Suggestion
- MDN — Constraint Validation API
Contacta con nosotros
Cuéntanos cómo podemos ayudarte; responderemos en un plazo de dos días laborables.
