Guía completa de accesibilidad para mensajes de error y microcopy: orientación clara, notificaciones de baja fatiga y vías de solución

Resumen ejecutivo (puntos clave primero)

• En un solo mensaje, cubre “qué pasa / dónde sucede / cómo se arregla” y ofrece señales redundantes que no dependan solo del color (texto + icono + contraste).
• Usa un patrón de dos niveles: área de resumen + errores por campo, elige adecuadamente entre role="alert" y role="status", y mueve el focus para minimizar el tiempo hasta la corrección.
• Emplea microcopy preventiva (ejemplos, restricciones, consejos) para minimizar errores y mantén la validación en tiempo real ligera.
• Incluye fallos fuera del formulario—asíncronos/red de datos/permisos/conflictos—y expón con claridad opciones de recuperación (reintentar, guardar borrador, contactar).
• Incluye fragmentos de implementación (HTML/ARIA/CSS/JS), plantillas de mensajes, una prueba rápida de 5 minutos y cómo construir una guía de estilo lingüístico organizacional.

Público objetivo (específico): Product Managers, Diseñadores UI/UX, Redactores técnicos, Frontend Engineers, QA/CS, Responsables de documentación
Nivel de accesibilidad objetivo: Apunta a cumplimiento WCAG 2.1 AA (persigue AAA donde sea factible). Enfócate principalmente en 1.3.1 / 1.4.1 / 1.4.3 / 1.4.11 / 2.1.1 / 2.2.2 / 2.4.3 / 2.4.6 / 2.4.7 / 3.3.x / 4.1.2

1. Introducción: los errores existen no para “regaño” sino para “ayuda”

Los mensajes de error son la pequeña mano amiga que convierte el tropiezo del usuario en el siguiente paso hacia adelante.
El rojo agresivo y la jerga interminable aumentan la carga cognitiva y la ansiedad, provocando abandono.
Nuestra meta es lenguaje calmado, pasos claros y fiables para corregir, y expresiones visibles y perceptibles en cualquier situación.
La accesibilidad también ayuda a necesidades diversas de visión/audición/motricidad/cognición y al uso con una mano, entornos ruidosos, redes lentas y pantallas pequeñas.
Esta guía te acompaña por diseño → redacción → implementación → verificación → operación con patrones “conectar y usar”.

2. Primeros principios: un set de 3 piezas para “arréglalo ahora”

2.1 La proporción áurea del mensaje (Qué / Dónde / Cómo)

• Qué (¿Cuál es el problema?) Concreto y breve. “El código postal no tiene 7 dígitos.”
• Dónde (¿Dónde está?) Identifica textualmente el campo. “Código postal.”
• Cómo (¿Cómo se arregla?) Una frase con la solución. “Introduce 7 dígitos sin guion (p. ej., 1000001).”

Buen ejemplo: “Falta código postal. Introduce 7 dígitos sin guion (p. ej., 1000001).”

2.2 Señales redundantes (no dependas solo del color)

• Texto + icono + contraste (texto 4.5:1 / elementos no textuales 3:1).
• Transmite significado con forma y posición (resaltar borde del campo, resumen de errores arriba).
• Sonido/vibración son opcionales—supón que el mensaje funciona en silencio.

2.3 Patrón de dos niveles (resumen + por campo)

• Coloca un resumen de errores arriba (con enlaces ancla a cada campo).
• Muestra mensajes por campo junto a los campos. Minimiza el ping-pong visual.

3. Diseño preventivo: evita errores desde el principio

• Mantén etiquetas visibles y ejemplos cerca; enlázalos con aria-describedby para que los lectores de pantalla los anuncien.
• Usa type, autocomplete e inputmode para prevenir entradas erróneas.
• Expón restricciones por adelantado: longitud, formato y criterios de selección en pistas.
• Divide entradas (dirección/teléfono) en orden natural.
• Validación en tiempo real solo al perder foco (blur) o tras una pausa breve de tecleo (300–600 ms). Las alertas rojas a medio tecleo fatigan.

Ejemplo (pista + asociación)

<div class="field">
  <label for="zip">Postal code <span aria-hidden="true">*</span></label>
  <input id="zip" name="zip" inputmode="numeric" autocomplete="postal-code"
         aria-describedby="zip-hint zip-err" required>
  <small id="zip-hint">7 digits, no hyphen (e.g., 1000001)</small>
  <span id="zip-err" class="error" role="alert" hidden>Please enter 7 digits.</span>
</div>

4. Diseño visual de errores: inconfundibles, no agobiantes

• Color: Texto 4.5:1; bordes/iconos ≥ 3:1.
• Iconos: Formas con significado claro (p. ej., error ▲ / advertencia ! / éxito ✔).
• Foco: Usa un anillo grueso y con offset con :focus-visible para hacer obvia la ubicación.
• Densidad: Demasiados rojos a la vez saturan. Resume primero → guía a los campos.
• Movimiento: Evita sacudidas/parpadeos. Comunica con color + texto.

.error { color:#b00020; }
input[aria-invalid="true"] { border:2px solid #c62828; box-shadow:0 0 0 3px rgba(198,40,40,.18); }
:focus-visible { outline:3px solid #ff9900; outline-offset:3px; }

5. ARIA y regiones en vivo: afina cómo “suenan” las notificaciones

• role="alert": Inmediato/interruptivo. Resérvalo para errores y fallos críticos.
• role="status": Actualizaciones discretas (guardado, borrador guardado).
• aria-live="polite": Narración suave para auto-actualizaciones.
• aria-atomic="true": Vuelve a anunciar todo el mensaje cuando cambien partes.

Ejemplo (resumen de errores + destino de foco)

<div id="error-summary" role="alert" aria-labelledby="err-title" hidden tabindex="-1">
  <h2 id="err-title">Please review your entries</h2>
  <ul>
    <li><a href="#zip">Postal code: enter 7 digits</a></li>
    <li><a href="#email">Email: format is invalid</a></li>
  </ul>
</div>
<script>
function showSummary(){ const sum = document.getElementById('error-summary'); sum.hidden = false; sum.focus(); }
</script>

Consejos de selección:

• Errores de campo: Un role="alert" por campo los hace perceptibles de forma fiable.
• Éxito de guardado: Usa role="status" para anunciar en voz baja.
• Pérdida de red: Usa alert más recuperación (reintentar / borrador offline) juntos.

6. Redacción: amable, breve, concreta

6.1 Principios de estilo

• Haz del campo el sujeto, no “tú” (“Falta el código postal.”).
• Prefiere propuestas a prohibiciones: evita “no se puede ingresar”; di “Introduce 7 dígitos.”
• Traduce jerga: “Timeout” → “Se cerró la sesión por seguridad por inactividad.”
• Sé numérico: Mejor “2 minutos” que “en breve”.

6.2 Plantillas comunes (en inglés)

• Falta: “{Field} is required. Please enter {requirement}.”
• Formato inválido: “{Field} is not in the correct format. Enter it like {example}.”
• Fuera de rango: “Enter {field} between {min}–{max} {unit}.”
• Duplicado: “This {field} is already in use. Please try another.”
• Red: “Communication failed. Check your connection and try again. Your draft has been saved.”
• Permisos/Seguridad: “You don’t have permission for this action. Please contact an administrator.”

6.3 “Malo → Bueno”

• Malo: “Invalid input.” → Bueno: “Introduce teléfono como 10–11 dígitos sin guiones (p. ej., 0312345678).”
• Malo: “Error (-1001).” → Bueno: “La solicitud superó el tiempo. Revisa tu conexión y vuelve a intentar.”

7. Fallos asíncronos y del servidor: prepárate para realidades más allá del formulario

7.1 Escenarios comunes

• Red inestable: fallan envíos, se interrumpen cargas.
• Errores del servidor: 5xx, mantenimiento.
• Conflictos: ediciones simultáneas en otro dispositivo.
• Authz/authn: caducidad de token, acceso denegado.
• Archivos: límites de tamaño, extensiones, malware detectado.

7.2 Estrategias de recuperación

• Ofrece reintentar (botón + atajo) e indica cuántos intentos están bien.
• Ofrece guardar borrador y auto-restaurar.
• Presenta opciones de contacto (email/teléfono/texto relay) en texto.
• Visualiza estado: usa role="status" para “Enviando…” / “Guardado.”

Ejemplo (UI de reintento)

<div role="alert">
  Save failed. Check your network and <a href="#" id="retry">try again</a>. Your draft is preserved.
</div>
<script>
document.getElementById('retry').addEventListener('click', e => { e.preventDefault(); saveDraftAgain(); });
</script>

8. Reduce carga cognitiva: orden, etapas y opciones acotadas

• Revelado progresivo: no muestres todo a la vez (acordeones/pasos).
• Limita opciones a 5–7 ítems; si hay más, usa un combo con búsqueda.
• Ejemplos concretos (p. ej., “Tokyo → Chiyoda → 1-1-1” paso a paso).
• Resume textos largos con una línea de “Puntos clave:” al inicio.
• Los iconos ayudan; lidera con texto.

9. Multilingüe, lectores de pantalla y control por voz: respeta I/O diversos

• Define atributos lang correctos para la página y para términos extranjeros en línea.
• Asegura que texto visible = nombre accesible (2.5.3). Usa las mismas palabras en botones con icono.
• Prefiere frases cortas y robustas que sobrevivan a la traducción automática (sujeto y predicado claros).
• Localiza números/fechas/divisas (p. ej., especifica YYYY-MM-DD).
• Para voz, haz que el texto de botones/enlaces sea orientado a la acción (“Delete”, “Submit”, “Retry”).

10. Código base: formulario + resumen de errores + errores por campo (listo para pegar)

<form id="f" novalidate aria-describedby="note">
  <p id="note">* Required. Takes about 2 minutes.</p>

  <div id="summary" role="alert" aria-labelledby="summary-title" hidden tabindex="-1">
    <h2 id="summary-title">Please review your entries</h2>
    <ul id="summary-list"></ul>
  </div>

  <div class="field">
    <label for="name">Full name <span aria-hidden="true">*</span></label>
    <input id="name" name="name" required aria-describedby="name-err">
    <span id="name-err" class="error" role="alert" hidden>Name is required.</span>
  </div>

  <div class="field">
    <label for="email">Email <span aria-hidden="true">*</span></label>
    <input id="email" name="email" type="email" required aria-describedby="email-hint email-err">
    <small id="email-hint">e.g., user@example.com</small>
    <span id="email-err" class="error" role="alert" hidden>Please enter a valid email address.</span>
  </div>

  <button id="send">Submit</button>
  <div id="status" role="status" aria-atomic="true" class="sr-only"></div>
</form>

<script>
const fields = [
  { id:'name', err:'name-err', check: el => el.value.trim().length>0, msg:'Name is required.' },
  { id:'email', err:'email-err', check: el => el.validity.valid, msg:'Please enter a valid email address.' }
];

document.getElementById('f').addEventListener('submit', e=>{
  e.preventDefault();
  const list = document.getElementById('summary-list');
  const sum  = document.getElementById('summary');
  list.innerHTML = '';
  let firstBad = null;

  fields.forEach(f=>{
    const el  = document.getElementById(f.id);
    const ok  = f.check(el);
    const err = document.getElementById(f.err);
    el.setAttribute('aria-invalid', String(!ok));
    err.hidden = ok;
    if(!ok){
      if(!firstBad) firstBad = el;
      list.insertAdjacentHTML('beforeend', `<li><a href="#${f.id}">${f.msg}</a></li>`);
    }
  });

  if(firstBad){
    sum.hidden = false; sum.focus();
    list.querySelectorAll('a').forEach(a=> a.addEventListener('click', ()=>document.getElementById(a.getAttribute('href').slice(1)).focus()));
    return;
  }

  const st = document.getElementById('status');
  st.textContent = 'Submitting…';
  document.getElementById('send').disabled = true;
  setTimeout(()=>{ // mock submit
    st.textContent = 'Submission completed. Thank you.';
    document.getElementById('send').disabled = false;
    e.target.reset();
  }, 1000);
});
</script>

11. Accesibilidad de notificaciones: elegir toast vs. banner vs. inline

• Toast: Avisos breves de éxito (p. ej., guardado). Historial ayuda.
• Banner: Alertas de todo el sitio en la parte superior (caída del sistema, mantenimiento).
• Inline: Resultados localizados (conteo de filtros, errores por campo).

Principios

• Los mensajes que se cierran solos deben dar tiempo suficiente de lectura (3–5 s; mantener mientras haya focus).
• Ofrece controles de pausa/reanudar cuando sea posible.
• Por defecto role="status", usa alert solo para alta prioridad.

12. Lista de verificación (diseño / redacción / implementación)

1. ¿Cada mensaje contiene Qué/Dónde/Cómo?
2. ¿Hay señales redundantes (texto + color + icono) para evitar significado solo por color?
3. ¿Etiquetas visibles = nombres accesibles (2.5.3)?
4. ¿Existe un camino resumen → por campo, navegable con teclado en ambos sentidos?
5. ¿El focus nunca se pierde? ¿:focus-visible es suficientemente notorio?
6. ¿Se usan bien las regiones en vivo (sin spam de alert)?
7. ¿La validación en tiempo real está contenida (sin rojos durante el tecleo)?
8. Ante fallo de red, ¿ofrecemos reintento/borrador/contacto?
9. Móvil (320 px): ¿el layout aguanta; objetivos 44–48 px?
10. Resiliencia multilingüe: frases cortas; nombres/unidades/fechas consistentes?

13. Prueba rápida de 5 minutos: un ritual mínimo en cada release

• Solo con Tab, completa entrada → envía → resumen → salta a campos → corrige → reenvía.
• Con lector de pantalla (NVDA/VoiceOver), los errores se anuncian de inmediato al ocurrir.
• Con colores en escala de grises, texto e iconos siguen transmitiendo significado.
• Ve offline y envía → se ofrece reintento; el borrador permanece.
• Con 150% de tamaño de texto, el ajuste es estable y la info clave no se oculta.

14. Caso práctico: tres cambios que redujeron el abandono

Antes

• Solo placeholders, sin etiquetas.
• Errores rojos instantáneos al teclear + toasts constantes.
• En fallo al enviar: solo “Error -1001”.

Después

1. Añade etiquetas visibles + ejemplos cercanos, enlazados vía aria-describedby.
2. Cambia la validación en tiempo real a on blur y adopta el patrón resumen + por campo.
3. Añade botón de reintento y guardado de borrador para fallos de red.
   Resultado: Finalización de formulario +18%, tickets de CS por errores −37%, abandono ante fallo de envío −52%.

15. Errores comunes y cómo evitarlos

16. Adopción organizacional: guía de estilo de lenguaje y sistema de diseño

• Guía de estilo de lenguaje
  • Persona, nivel de cortesía; estandariza el “Please …”.
  • Términos prohibidos (abstractos, amenazantes) vs. expresiones preferidas.
  • Plantillas (falta/formato/rango/duplicado/permisos/red).
• Sistema de diseño
  • Documenta Name/Role/Value (NRV) para alertas/toasts/banners/campos con error.
  • Mínimos de colores/contraste/iconos, grosor para :focus-visible.
  • Gobernanza de regiones en vivo (evita el abuso de alert).
• Operaciones
  • Añade checks de a11y a las PR; automatiza escaneos + prueba de 5 min como rutina.
  • Devuelve logs de CS a mejoras de redacción.

17. ¿Quién se beneficia y cómo? (impacto concreto)

• Personas con diversidad visual: Señales redundantes y alto contraste reducen omisiones.
• Usuarios de lectores de pantalla: Uso correcto de alert/status y el camino resumen → campo acortan el tiempo de arreglo.
• Perfiles cognitivos/aprendizaje diversos: Información breve, concreta y por etapas reduce carga.
• Móvil/una mano: Objetivos adecuados; validación contenida reduce fallos.
• Redes poco fiables: Reintento/guardado evitan pérdida de trabajo.
• CS/Operaciones: Menos tickets y más estructurados; menor tiempo medio de gestión.

18. Niveles objetivo y cómo luce lo “bueno”

• WCAG 2.1 AA (primario)
  • 1.3.1 Info y relaciones (resumen + por campo, asociaciones)
  • 1.4.1 Uso del color (evita significado solo por color; señales redundantes)
  • 1.4.3 / 1.4.11 Contraste (texto / no textual)
  • 2.1.1 Teclado (resumen ↔ campos)
  • 2.2.2 Pausar/Detener/Ocultar (control de notificaciones)
  • 2.4.3 / 2.4.6 / 2.4.7 Orden de foco, etiquetas, foco visible
  • 3.3.1 / 3.3.2 / 3.3.3 Identificación de error, etiquetas/instrucciones, sugerencias de error
  • 4.1.2 Nombre/Rol/Valor (alert/status/aria-invalid, etc.)
• Aspiraciones AAA
  • 1.2.8 (Alternativas de medios: transcripciones para vídeos de solución de problemas)
  • 1.4.6 (Contraste mejorado)
  • 3.3.6 (Prevención de errores: confirmaciones más fuertes en transacciones críticas)

19. Cierre: palabras suaves llegan a todos

1. Usa Qué/Dónde/Cómo para que los mensajes sean accionables al instante.
2. Resumen + por campo más movimiento del foco traza el camino más corto a la corrección.
3. Señales redundantes (texto + icono + contraste) eliminan la dependencia del color.
4. Mantén contenida la validación en tiempo real; usa microcopy preventiva para evitar errores.
5. Elige sabiamente entre alert/status; mantén las notificaciones calmas.
6. Ofrece siempre recuperación (reintento, borrador, contacto).
7. Usa una guía de estilo de lenguaje y un sistema de diseño para alinear palabras y comportamientos del equipo.

Los mensajes de error no son reprimendas: son compañeros.
Cuando tus usuarios tropiecen, que tu producto tienda una mano firme y amable—siempre.