Mensajes de error de formulario accesibles: identificar, explicar y corregir

Qué exigen los mensajes de error de formulario accesibles (WCAG 3.3.1)

El criterio 3.3.1 «Identificación de errores» (Error Identification) se aplica cuando se detecta automáticamente un error de entrada: el elemento erróneo debe identificarse y el error debe describirse al usuario en texto. Según el W3C, el objetivo es que el usuario sepa que existe un error y qué está mal.

El W3C cita en particular dos casos de error de entrada: información que la página exige pero que el usuario omitió, e información proporcionada que queda fuera del formato de datos requerido o de los valores permitidos. Sus ejemplos son muy concretos: una abreviatura de estado, provincia o región incorrecta, un código postal inexistente, una fecha de nacimiento dos años en el futuro, letras o paréntesis en un campo de teléfono que solo admite números, o una puja inferior a la anterior.

Un caso que se olvida a menudo: si la página cambia automáticamente un valor demasiado alto o demasiado bajo para que quede dentro del rango permitido, el error debe describirse igualmente al usuario. Un mensaje que le informe del valor modificado cumple a la vez 3.3.1 y 3.3.3.

El color, un icono o una imagen están permitidos, pero solo como complemento del texto. El criterio tampoco impone una ubicación: lista de errores al inicio del formulario, mensajes junto a cada campo, una alerta o un cuadro de diálogo. El único requisito es que los errores se presenten en texto o mediante una alternativa textual.

• Nombrar en el mensaje el campo con error (por ejemplo «Correo electrónico»).
• Describir la naturaleza del error: campo obligatorio vacío, formato incorrecto, valor fuera de la lista.
• No confiar nunca solo en el color rojo o en un icono.
• Informar también de las correcciones automáticas que haga la página.

Sugerir la corrección: el criterio 3.3.3

El criterio 3.3.3 «Sugerencias ante errores» (Error Suggestion, nivel AA) va más allá: si se detecta automáticamente un error de entrada y se conocen sugerencias de corrección, deben ofrecerse al usuario, salvo que ello ponga en peligro la seguridad o el propósito del contenido. El W3C recuerda que saber que hay un error no siempre basta: las personas con limitaciones cognitivas pueden tener dificultades para entender cómo corregirlo, y un usuario inseguro puede abandonar el formulario.

El ejemplo de redacción del W3C es un buen modelo. «Email is not valid» (el correo no es válido) cumple 3.3.1. «Please provide a valid email address in the format [email protected]» (indique un correo válido con el formato [email protected]) explica además cómo corregirlo y cumple ambos criterios.

Otro ejemplo de la documentación: un campo espera el nombre de un mes y el usuario escribe «12». La corrección puede ser una lista de valores aceptados («Elija uno de: enero, febrero… diciembre») o una interpretación de la entrada («¿Quiere decir diciembre?»). El W3C describe también un formulario que no se envió correctamente y muestra el error en su lugar, junto con la entrada correcta y ayuda adicional para el campo.

• Formato esperado: dé un ejemplo concreto ([email protected], dd/mm/aaaa).
• Lista cerrada: recuerde los valores permitidos o proponga el más probable.
• Excepción: no sugiera nada que ponga en peligro la seguridad o el propósito del contenido.

Prevenir errores con etiquetas e instrucciones (3.3.2)

El mejor mensaje de error es el que nunca se muestra. El criterio 3.3.2 «Etiquetas o instrucciones» (Labels or Instructions, nivel A) exige que se proporcionen etiquetas o instrucciones cuando el contenido requiere que el usuario introduzca datos. «Requiere» no se refiere solo a los campos obligatorios: el criterio se aplica a todos los campos, obligatorios u opcionales. No se aplica a enlaces ni a otros controles no asociados a la introducción de datos, como un widget de desplegar/plegar.

En botones de opción, casillas de verificación y listas desplegables, cada opción necesita su propia etiqueta. Si las etiquetas de las opciones bastan para indicar la función del grupo, puede que no haga falta una etiqueta visible para el grupo; si no, hay que proporcionar una etiqueta, una leyenda o instrucciones para el conjunto. Las instrucciones pueden precisar el formato esperado, sobre todo si es poco habitual o sigue reglas específicas de entrada. El W3C advierte además contra el exceso: demasiada información puede ser tan perjudicial como demasiado poca. Las instrucciones pueden mostrarse solo cuando el control tiene el foco, o estar disponibles mediante un enlace, sobre todo si son largas.

Ojo con el alcance: 3.3.2 no exige que la etiqueta esté correctamente marcada y asociada al campo; eso corresponde al criterio 1.3.1. A la inversa, un campo puede tener un nombre accesible mediante aria-label y cumplir 4.1.2, pero fallar 3.3.2 si la etiqueta solo se presenta a quienes usan tecnologías de apoyo. La claridad de la etiqueta corresponde al criterio 2.4.6.

• Un campo de fecha con el formato esperado indicado en texto (dd/mm/aaaa o mm/dd/aaaa).
• Un campo de nombre de usuario con las reglas sobre los caracteres permitidos.
• Dos campos «Nombre de pila» y «Apellidos» en lugar de una sola etiqueta «Nombre» para ambos.
• Un campo de búsqueda cuyo icono de lupa sirve de etiqueta visible.

<!-- Etiqueta asociada (H44), campo obligatorio indicado en la etiqueta (H90)
     y formato esperado con ejemplo (G89) -->
<label for="fecha-nacimiento">Fecha de nacimiento (obligatorio)</label>
<p id="fecha-nacimiento-hint">Formato esperado: dd/mm/aaaa, por ejemplo 14/07/1990</p>
<input type="text" id="fecha-nacimiento" name="fecha-nacimiento"
       aria-describedby="fecha-nacimiento-hint" aria-required="true">

<!-- Grupo de campos: fieldset y legend (H71),
     con una etiqueta visible para cada subcampo (H44) -->
<fieldset>
  <legend>Dirección</legend>
  <label for="codigo-postal">Código postal</label>
  <input type="text" id="codigo-postal" name="codigo-postal">
  <label for="ciudad">Ciudad</label>
  <input type="text" id="ciudad" name="ciudad">
</fieldset>

Anunciar el error al lector de pantalla: técnicas del W3C

El criterio 3.3.1 no exige información programática: basta un texto, o una alternativa textual, que identifique el campo y describa el error. Aun así, el W3C señala que la identificación del error puede combinarse con información que los navegadores y las tecnologías de apoyo pueden utilizar, aspecto que puede corresponder a otros criterios como 4.1.2 «Nombre, función, valor» (Name, Role, Value). Entre las técnicas suficientes para 3.3.1, clasificadas según la situación, figuran ARIA21 «Usar aria-invalid para indicar un campo con error» para campos obligatorios sin completar, así como ARIA19 «Usar role=alert de ARIA o regiones live para identificar errores», ARIA18 «Usar aria-alertdialog para identificar errores» y SCR32 «Validación del lado del cliente añadiendo el texto de error mediante el DOM» para entradas fuera del formato o de los valores permitidos.

Una implementación posible combina un mensaje vinculado al campo mediante aria-describedby, un atributo aria-invalid en el campo erróneo y un resumen en una zona role="alert". Como técnicas recomendadas, el W3C cita también G139 «Crear un mecanismo que permita a los usuarios saltar a los errores», que puede realizar con enlaces a cada campo en el resumen, y G199 «Confirmar el éxito cuando los datos se envían correctamente».

<form id="signup" novalidate>
  <div id="error-summary" role="alert"></div>

  <label for="email">Correo electrónico (obligatorio)</label>
  <input type="email" id="email" name="email" aria-describedby="email-error">
  <p id="email-error" hidden></p>

  <button type="submit">Crear mi cuenta</button>
</form>

<script>
  const form = document.getElementById('signup');
  form.addEventListener('submit', (e) => {
    const field = document.getElementById('email');
    const msg = document.getElementById('email-error');
    const summary = document.getElementById('error-summary');
    // Reinicio antes de cada comprobación
    msg.textContent = '';
    msg.hidden = true;
    summary.innerHTML = '';
    field.removeAttribute('aria-invalid');

    let error = '';
    if (!field.value.trim()) {
      error = 'Correo electrónico: este campo es obligatorio.';
    } else if (!/^[^@\s]+@[^@\s]+\.[^@\s]+$/.test(field.value)) {
      error = 'Correo electrónico: formato no válido. Introduzca una dirección con el formato [email protected].';
    }
    if (error) {
      e.preventDefault();
      msg.textContent = error;
      msg.hidden = false;
      field.setAttribute('aria-invalid', 'true');
      summary.innerHTML = '<p>1 error: <a href="#email">Correo electrónico</a></p>';
    }
  });
</script>

¿Basta con la validación HTML nativa?

Con la validación HTML nativa (atributos required, type="email", etc.), el navegador impide el envío de un formulario incompleto o no válido y muestra un mensaje genérico. Por lo general devuelve el foco al primer campo con error y, en la mayoría de las combinaciones habituales de navegador y lector de pantalla, este anuncia el mensaje de error y el nombre programático del campo. El W3C considera que esto cumple el criterio 3.3.1.

Aun así, el W3C enumera varios inconvenientes y recuerda que los desarrolladores deben evaluar con cuidado si la validación nativa es compatible con la accesibilidad («accessibility supported» en el sentido de las WCAG).

• Según el navegador, el mensaje puede no ser permanente o no desplazarse con la página.
• Según el navegador, el mensaje no se amplía cuando el usuario hace zoom: se queda al tamaño de la interfaz del navegador y puede ser demasiado pequeño.
• Los mensajes por defecto suelen ser genéricos y pueden no ofrecer sugerencias suficientes para 3.3.3.
• Solo se muestra el primer error: el usuario puede tener que corregir y reenviar el formulario varias veces.

Preguntas frecuentes

Más sobre el tema en Conformly

• Corregir un campo de formulario sin etiqueta en HTML
• Criterio RGAA 11.10 sobre el control de entrada
• Criterio RGAA 11.11 sobre sugerencias de corrección

Fuentes

Este artículo se basa en las fuentes oficiales citadas al final de la página.

• W3C — Comprendre 3.3.1
• W3C — Comprendre 3.3.3
• W3C — Comprendre 3.3.2