Técnica Técnicas generales WCAG 2.2
G85Explicar en texto cómo corregir un dato con formato incorrecto
Nombre oficial en el W3C: Proporcionar una descripción textual cuando la entrada del usuario no se ajusta al formato o a los valores requeridos
En pocas palabras
Cuando un dato no tiene el formato correcto, como un DNI sin letra o una fecha mal escrita, la web debe explicarlo con texto. El mensaje dice qué campo falla y cómo corregirlo: el formato esperado, un ejemplo válido o un valor parecido que sí se acepta.
Por qué es importante
Un mensaje como «Datos incorrectos» no ayuda a nadie. La persona no sabe qué cambiar y lo intenta a ciegas.
Lo sufren sobre todo las personas con discapacidad cognitiva, las que usan lector de pantalla y las personas mayores. Muchas abandonan el trámite a medias.
Cómo se hace
- Compruebe el dato al salir del campo o al enviar el formulario.
- Si hay error, escriba un mensaje que nombre el campo y diga cómo corregirlo. Por ejemplo: «Fecha de nacimiento: use el formato día/mes/año, como 05/03/1980».
- Ponga el mensaje junto al campo, asociado con
aria-describedby, y marque el campo conaria-invalid="true". - Si hay varios errores, muestre arriba un resumen con enlaces a cada campo y lleve el foco a ese resumen.
- Conserve lo ya escrito, salvo contraseñas y otros datos de seguridad.
Ejemplo práctico
Formulario de cita previa de un ayuntamiento que comprueba el DNI y el código postal antes de enviar. Lo que se evalúa es el mensaje de error. Debe decir qué campo falla, por qué y cómo corregirlo. Y debe conservar lo ya escrito.
Así no: Mensaje genérico que además borra los datos
Si el DNI o el código postal están mal, solo aparece «Datos incorrectos.». No dice qué campo falla ni qué formato se espera. Además, el formulario se vacía y hay que escribirlo todo de nuevo. Pruebe a enviar el DNI «1234» y el código postal «3000».
La demostración contiene, a propósito, el error de accesibilidad que se explica.
Ver el código del ejemplo incorrecto
<form id="cita" action="#" novalidate>
<label for="dni">DNI</label>
<input id="dni" name="dni" autocomplete="off">
<label for="cp">Código postal</label>
<input id="cp" name="cp" inputmode="numeric" autocomplete="postal-code">
<button>Pedir cita</button>
<p id="msg"></p>
</form>
<style>label, input { display: block; } input { margin-bottom: .6em; }</style>
<script>
document.getElementById('cita').addEventListener('submit', function (e) {
e.preventDefault();
var ok = /^\d{8}[A-Za-z]$/.test(this.dni.value.trim()) && /^\d{5}$/.test(this.cp.value.trim());
document.getElementById('msg').textContent = ok ? 'Cita solicitada.' : 'Datos incorrectos.';
if (!ok) this.reset();
});
</script>Así sí: Error explicado junto al campo y en un resumen con enlaces
Cada campo con error muestra un mensaje con el formato esperado y un ejemplo válido. El mensaje se asocia al campo con aria-describedby y el campo se marca con aria-invalid. Arriba aparece un resumen con enlaces a cada campo. El foco pasa a ese resumen y los datos escritos se conservan.
Pruébelo aquí:
Ver el código del ejemplo correcto
<form id="cita" action="#" novalidate>
<div id="resumen" tabindex="-1"></div>
<label for="dni">DNI</label>
<input id="dni" name="dni" autocomplete="off" aria-describedby="dni-err">
<p id="dni-err" class="err"></p>
<label for="cp">Código postal</label>
<input id="cp" name="cp" inputmode="numeric" autocomplete="postal-code" aria-describedby="cp-err">
<p id="cp-err" class="err"></p>
<button>Pedir cita</button>
</form>
<style>label, input { display: block; } .err { color: #b00020; margin: .2em 0 .6em; }</style>
<script>
var f = document.getElementById('cita'), res = document.getElementById('resumen');
var reglas = [
['dni', /^\d{8}[A-Za-z]$/, 'DNI: debe tener 8 números y una letra, por ejemplo 12345678Z.'],
['cp', /^\d{5}$/, 'Código postal: debe tener 5 cifras, por ejemplo 30001.']
];
f.addEventListener('submit', function (e) {
e.preventDefault();
var lista = '';
reglas.forEach(function (r) {
var ok = r[1].test(f[r[0]].value.trim());
f[r[0]].setAttribute('aria-invalid', ok ? 'false' : 'true');
document.getElementById(r[0] + '-err').textContent = ok ? '' : r[2];
if (!ok) lista += '<li><a href="#' + r[0] + '">' + r[2] + '</a></li>';
});
res.innerHTML = lista ? '<p>Revise estos datos:</p><ul>' + lista + '</ul>' : '<p>Cita solicitada.</p>';
res.focus();
});
res.addEventListener('click', function (e) {
var a = e.target.closest('a');
if (a) { e.preventDefault(); document.getElementById(a.getAttribute('href').slice(1)).focus(); }
});
</script>Cómo comprobarlo
Errores frecuentes en auditorías
- Mensajes genéricos como «Revise el formulario» o «Error 400», que no dicen qué campo falla ni qué formato se espera.
- Indicar el error solo con un borde rojo o un icono, sin texto.
- Recargar la página con el formulario vacío, de modo que hay que escribirlo todo otra vez.
- Fiarse solo de los avisos del navegador. Desaparecen enseguida y no siempre explican el formato correcto.
Ver el texto completo del W3C (traducción al español)
Esta es una traducción no oficial al español de la técnica G85 de Techniques for WCAG 2.2, del W3C. Puede contener errores. El único documento oficial y normativo es la versión original en inglés, publicada en el sitio web del W3C.
Aplicabilidad
Contenido que acepta la introducción de datos por parte del usuario, con restricciones en el formato, el valor o el tipo de la entrada.
Descripción
El objetivo de esta técnica es ofrecer ayuda para corregir los errores de entrada cuando la información facilitada por el usuario no se acepta. Cuando los usuarios introducen datos que se validan y se detectan errores de entrada, se proporciona en texto información sobre la naturaleza y la ubicación del error de entrada, de modo que los usuarios puedan identificar el problema. Un enfoque consiste en usar validación en el lado del cliente y mostrar un cuadro de diálogo de alerta que describa el error inmediatamente, cuando el usuario introduce datos no válidos en el campo. Otro enfoque, con validación en el lado del servidor, consiste en volver a mostrar el formulario (incluidos los datos introducidos previamente) junto con una descripción textual en la parte superior de la página que indique que se ha producido un error, describa la naturaleza del problema y ofrezca formas de localizar fácilmente el campo o los campos con problemas.
Sea cual sea la forma en que se proporcione la descripción textual, debería hacer alguna de las siguientes cosas para ayudar al usuario:
- Ofrecer ejemplos de la entrada de datos correcta para el campo,
- Describir la entrada de datos correcta para el campo,
- Mostrar valores de entrada correctos que sean similares a los introducidos por el usuario, con instrucciones sobre cómo introducir uno de esos valores correctos si el usuario así lo desea.
Ejemplos
- El usuario introduce datos no válidos en un campo de formulario. Cuando el usuario sale del campo, aparece un cuadro de diálogo de alerta que describe la naturaleza del error para que pueda corregirlo.
- El usuario introduce datos no válidos en un campo de formulario y envía el formulario. El servidor devuelve el formulario, con los datos del usuario todavía presentes, e indica claramente en texto, en la parte superior de la página, que ha habido errores de entrada. El texto describe la naturaleza del error o errores e indica claramente qué campo tenía el problema, de modo que el usuario pueda llegar a él fácilmente para solucionarlo.
- El usuario introduce datos no válidos en un campo de formulario e intenta enviar el formulario. Un script en el lado del cliente detecta el error, cancela el envío y modifica el documento para añadir, después del botón de envío, una descripción textual del error con enlaces al campo o campos erróneos. El script también modifica las etiquetas de los campos con problemas para resaltarlos.
Pruebas
Procedimiento
- Rellenar un formulario introduciendo deliberadamente datos que no se ajusten al formato o a los valores requeridos
- Comprobar que se proporciona una descripción textual que identifica el campo erróneo y ofrece información sobre la naturaleza de la entrada no válida y sobre cómo corregirla.
- Comprobar que los demás datos introducidos previamente por el usuario se vuelven a mostrar, salvo que se trate de un campo relacionado con la seguridad en el que no sea apropiado conservar los datos para volver a mostrarlos (p. ej., una contraseña).
Resultados esperados
- Las comprobaciones n.º 2 y n.º 3 son verdaderas
Cómo lo comprobamos en ADDAW
En cada auditoría de ADDAW revisamos esta técnica página a página y le entregamos los errores con capturas y la forma de corregirlos.
Basado en la técnica G85 del W3C (WCAG 2.2). Explicación y ejemplos: ADDAW. Traducción no oficial del texto del W3C © W3C, licencia de documentos del W3C. ¿Ha visto un error? Escríbanos.