Identificación de Errores: Haciendo los Errores de Formulario Claros y Accionables

Introducción

Cuando los usuarios cometen errores al completar formularios, necesitan información clara sobre qué salió mal y cómo corregirlo. WCAG 3.3.1 (Identificación de Errores) requiere que cuando se detectan errores, el campo específico con el error debe ser identificado y el error descrito en texto. Esto no es solo un requisito de accesibilidad—es esencial para una buena experiencia de usuario.

Los formularios con mensajes de error poco claros frustran a todos. Para usuarios con discapacidades, particularmente aquellos que usan lectores de pantalla o que tienen discapacidades cognitivas, el manejo ambiguo de errores puede hacer que los formularios sean completamente inutilizables.

Qué Requiere WCAG

3.3.1 Identificación de Errores (Nivel A)

Si se detecta automáticamente un error de entrada, se identifica el elemento que está en error y el error se describe al usuario en texto.

Esto significa:

• Los errores deben describirse en texto (no solo color o iconos)
• El campo específico con el error debe ser identificado
• Los usuarios deben poder encontrar y entender qué salió mal

3.3.3 Sugerencia de Errores (Nivel AA)

Si se detecta automáticamente un error de entrada y se conocen sugerencias para la corrección, entonces las sugerencias se proporcionan al usuario.

Esto significa:

• Cuando sea posible, proporcionar orientación específica sobre cómo corregir el error
• Sugerir formatos correctos (ej., “Usa el formato: DD/MM/AAAA”)
• Ofrecer alternativas cuando sea apropiado

Quién Se Beneficia

Tipo de Usuario	Beneficio
Usuarios de lectores de pantalla	Errores anunciados claramente, no solo señales visuales
Usuarios con baja visión	Descripciones de texto complementan cambios de color
Usuarios con discapacidades cognitivas	Orientación clara sobre qué necesita corrección
Usuarios con discapacidades motoras	Pueden navegar directamente a campos con errores
Todos los usuarios	Completado de formularios más rápido con retroalimentación clara

Problemas Comunes en el Manejo de Errores

1. Errores Solo por Color

<!-- MAL: Solo el color indica error -->
<input type="email" class="error-borde-rojo">

<!-- BIEN: Descripción de texto con color -->
<input type="email" aria-describedby="email-error" aria-invalid="true">
<p id="email-error" class="error-text">
  Por favor ingresa un correo electrónico válido (ej., [email protected])
</p>

2. Mensajes de Error Genéricos

<!-- MAL: Mensaje inútil -->
<p class="error">Entrada inválida</p>

<!-- BIEN: Mensaje específico y accionable -->
<p id="telefono-error" class="error">
  El número de teléfono debe tener 10 dígitos. Ingresaste 8 dígitos.
</p>

3. Errores Lejos de los Campos

<!-- MAL: Todos los errores arriba sin asociación de campo -->
<div class="error-summary">
  <p>Hubo errores en tu envío</p>
</div>

<!-- BIEN: Resumen con enlaces a campos + errores en línea -->
<div class="error-summary" role="alert">
  <h2>Por favor corrige 2 errores:</h2>
  <ul>
    <li><a href="#email">El correo electrónico es requerido</a></li>
    <li><a href="#telefono">El formato del teléfono es inválido</a></li>
  </ul>
</div>

4. Errores No Anunciados a Lectores de Pantalla

<!-- MAL: El error aparece pero no se anuncia -->
<span class="error">Campo requerido</span>

<!-- BIEN: Región en vivo anuncia el error -->
<span class="error" role="alert" aria-live="assertive">
  Campo requerido
</span>

Patrones Clave de Manejo de Errores

Patrón de Resumen de Errores

Proporciona un resumen de todos los errores en la parte superior del formulario, con enlaces a cada campo:

<div class="error-summary" role="alert">
  <h2>Hay 2 errores en este formulario</h2>
  <ul>
    <li><a href="#nombre">El nombre es requerido</a></li>
    <li><a href="#email">El formato del correo es inválido</a></li>
  </ul>
</div>

Patrón de Error en Línea

Coloca mensajes de error directamente junto al campo que describen:

<div class="form-group">
  <label for="email">Correo Electrónico</label>
  <input
    type="email"
    id="email"
    aria-describedby="email-error"
    aria-invalid="true"
  >
  <p id="email-error" class="error">
    Ingresa un correo electrónico válido (ej., [email protected])
  </p>
</div>

Validación en Tiempo Real

Valida mientras los usuarios escriben o cuando abandonan un campo, pero evita validar demasiado agresivamente:

• Sí validar: En blur (cuando el usuario abandona el campo)
• Sí validar: Al enviar el formulario
• Evitar: Validar mientras el usuario aún está escribiendo
• Evitar: Mostrar errores para campos requeridos vacíos antes de que el usuario interactúe

Componentes de Mensajes de Error Accesibles

Indicadores Visuales

• Borde o fondo rojo (pero nunca solo color)
• Icono de error (con texto alt o aria-label)
• Texto de error claro cerca del campo

Requisitos Programáticos

• aria-invalid="true" en el campo con error
• aria-describedby vinculando campo con mensaje de error
• role="alert" o aria-live="assertive" para errores dinámicos
• Gestión de foco (mover foco al resumen de errores o primer campo con error)

Probando Identificación de Errores

Prueba Manual Rápida

1. Envía un formulario con errores intencionales
2. Verifica que cada error se describa en texto
3. Comprueba que los mensajes de error identifiquen qué campo tiene el error
4. Prueba con lector de pantalla para asegurar que los errores se anuncien
5. Verifica que los usuarios de teclado puedan navegar a los campos con errores

Qué Verificar

• [ ] Los errores se describen en texto (no solo color/iconos)
• [ ] Cada error identifica qué campo tiene el problema
• [ ] Las sugerencias de error proporcionan orientación útil cuando es posible
• [ ] Los lectores de pantalla anuncian los errores cuando aparecen
• [ ] Los usuarios pueden navegar del resumen de errores a campos específicos
• [ ] El foco se gestiona apropiadamente después del envío del formulario

Herramientas para Pruebas

• Lector de pantalla: Prueba el anuncio de errores con NVDA, VoiceOver o JAWS
• axe DevTools: Verifica asociaciones de errores faltantes
• Prueba de teclado: Verifica que el foco se mueva apropiadamente a los errores

Resumen de Mejores Prácticas

Hacer	No Hacer
Describir errores en texto	Confiar solo en color o iconos
Identificar campo específico con error	Usar mensajes vagos “el formulario tiene errores”
Proporcionar sugerencias de corrección	Solo decir “entrada inválida”
Usar aria-invalid y aria-describedby	Dejar errores sin vincular a campos
Anunciar errores a lectores de pantalla	Mostrar errores silenciosamente
Colocar errores cerca de campos relacionados	Poner todos los errores lejos de los campos

Artículos Relacionados

• Guía de Implementación de Identificación de Errores - Patrones detallados
• Guía de Etiquetas ARIA - Nombres accesibles
• Hub de Cumplimiento WCAG - Todos los evaluadores de accesibilidad

---

Referencias

1. W3C - WCAG 2.2 SC 3.3.1 Error Identification
2. W3C - WCAG 2.2 SC 3.3.3 Error Suggestion
3. W3C - WAI Forms Tutorial - Validating Input
4. WebAIM - Accessible Form Validation