Formularios accesibles: etiquetas, mensajes de error y autocompletado

Objetivo

Formularios que una persona que usa un teclado, un lector de pantalla, entrada de voz o el autocompletado del navegador pueda completar y, cuando algo esté mal, corregir sin tener que adivinar.

Requisitos previos

Controles nativos (input, select, textarea, button type="submit") en lugar de elementos div estilizados, y una lista escrita de los campos con sus reglas de validación y cuáles son obligatorios.

Pasos

1. Etiquetar cada control explícitamente: <label for="email"> cuyo for coincida con el id del control (la asociación preferida por el tutorial de la WAI). Usar aria-label o aria-labelledby solo cuando una etiqueta visible sea imposible; el texto de marcador de posición no es una etiqueta.
2. Agrupar los controles relacionados con fieldset y legend (grupos de radio, bloques de dirección) para que el nombre del grupo se anuncie con cada opción.
3. Indicar la obligatoriedad en el texto de la etiqueta («Nombre (obligatorio)») y añadir el atributo required para que los navegadores y la tecnología de asistencia también lo sepan.
4. Añadir tokens de autocomplete a los campos referidos al usuario: name, given-name, family-name, email, username, new-password, current-password, one-time-code, postal-code. MDN señala que los tokens válidos satisfacen el criterio de éxito 1.3.5 de WCAG 2.2 (Identify Input Purpose) y que los valores inválidos o inventados usados para burlar el autocompletado también incumplen ese criterio, porque el propósito deja de ser legible por máquina.
5. Validar al enviar, conservar los valores introducidos y describir cómo corregir cada problema («Introducir la fecha como DD/MM/AAAA»), no solo que es inválido.
6. Si falla, mostrar un resumen de errores en la parte superior con un enlace a cada campo, marcar cada campo con aria-invalid="true" y conectar su mensaje con aria-describedby; mover el foco al resumen o al primer campo inválido.
7. Cuando la validación se ejecute sin recargar la página, anunciar el resultado en una región activa (role="alert") para que los lectores de pantalla lo escuchen.
8. Confirmar el éxito tanto en texto como en color, y pedir confirmación antes de envíos destructivos.
9. Probar solo con teclado, con un lector de pantalla y con el autocompletado del navegador activado.

Resultado esperado

Cada campo tiene un nombre accesible y un propósito legible por máquina; cada error es alcanzable con el teclado, es leído por la tecnología de asistencia e indica qué se debe cambiar; el autocompletado rellena los campos correctos.

Límites y base de verificación

Sigue los tutoriales de la WAI y la referencia de MDN citados. Los verificadores automatizados detectan etiquetas ausentes, pero no mensajes poco útiles; los widgets personalizados necesitan patrones ARIA completos que exceden este alcance. No se afirma ninguna medición.