Diseño de formularios accesibles: validación, ayudas y mensajes de error que funcionan

Los formularios son el punto donde una interfaz deja de “informar” y empieza a “negociar”: pedir datos, confirmar intenciones y guiar decisiones. Si fallan, el usuario no solo se frustra; también se expone a errores silenciosos, pérdida de información y abandono. Diseñar formularios accesibles implica algo más que cumplir WCAG: es construir un diálogo claro con ayudas oportunas, validación predecible y mensajes de error accionables.

1) Empieza por lo básico: estructura y etiquetas que no se rompen

• Etiqueta visible (label) para cada campo. Evita usar solo placeholder como “etiqueta”: desaparece al escribir y es menos accesible.
• Agrupa con fieldset/legend cuando haya conjuntos (p. ej., “Dirección”, “Preferencias”).
• Orden de tab natural: el flujo de teclado debe seguir el orden visual.

2) Validación: elige el momento correcto (y sé consistente)

La validación no es “detectar errores”, es “evitar que sucedan” sin interrumpir. Tres patrones habituales:

Regla práctica: valida “mientras escribe” solo si puedes dar feedback constructivo (qué falta) y no solo “está mal”. Para campos obligatorios, no castigues al usuario antes de que termine.

3) Ayudas y microcopys: reduce la carga cognitiva

Una ayuda efectiva responde una sola pregunta a la vez. Ubícala cerca del campo, en lenguaje simple, y anticipa el formato esperado:

• Ejemplos: “Ej: nombre@dominio.com”.
• Restricciones: “Mínimo 8 caracteres, 1 mayúscula y 1 número”.
• Propósito: “Usaremos este teléfono solo para recuperación de cuenta”.

Si tu formulario es largo, considera dividirlo en pasos, pero sin esconder información crítica. La accesibilidad no es solo teclado y lector de pantalla; también es arquitectura de información y reducción de ambigüedad.

4) Mensajes de error que funcionan: qué decir y dónde decirlo

Un mensaje útil tiene 3 partes: qué pasó, por qué (si ayuda) y cómo se arregla. Evita “Inválido” o “Error 400”. En su lugar:

• Mal: “Correo inválido”.
• Bien: “Escribe un correo con este formato: nombre@dominio.com”.
• Mal: “Contraseña débil”.
• Bien: “Agrega 1 número y 1 mayúscula para continuar”.

Ubicación: muestra el error junto al campo y, si el envío falla, agrega un resumen al inicio con enlaces que lleven al campo problemático. Así ayudas a usuarios de teclado a navegar rápido.

5) Accesibilidad técnica: estados, ARIA y foco

En términos técnicos, asegúrate de que el feedback sea detectable por tecnologías de asistencia:

• Cuando un campo tenga error, marca aria-invalid="true".
• Conecta ayuda y error usando aria-describedby hacia IDs reales (p. ej., help-email, err-email).
• Si el mensaje se actualiza dinámicamente, usa una región viva (aria-live="polite") para que el lector lo anuncie.
• Al fallar el envío, mueve el foco al resumen de errores o al primer campo inválido (y no a un modal inesperado).

<label for="email">Correo</label>
<p id="help-email">Ej: nombre@dominio.com</p>
<input id="email" name="email" type="email"
  aria-describedby="help-email err-email"
  aria-invalid="true" />
<p id="err-email" role="alert">Escribe un correo válido.</p>

6) Colores, iconos y contraste: nunca dependas de “solo rojo”

La señalización de error debe ser redundante: color + texto + (si aplica) icono. Asegura contraste suficiente entre texto y fondo, y también en estados de enfoque (outline visible). Si necesitas una guía rápida, revisa contrast ratio y color en WCAG.

Checklist final (antes de lanzar)

• ¿Cada input tiene label visible y asociada?
• ¿Los campos requeridos están indicados sin ambigüedad (y no solo con “*”)?
• ¿Los mensajes dicen cómo corregir, no solo que “está mal”?
• ¿El error aparece junto al campo y existe un resumen al enviar?
• ¿Se puede completar todo con teclado y el foco es visible?
• ¿Ayudas y errores están conectados con aria-describedby?
• ¿El contraste se mantiene en estados normal, focus y error?