01 · Concepto
Recuperación: prevenir, explicar y corregir
Un error no debería convertirse en un callejón sin salida. El diseño debe reducir la probabilidad de cometerlo y ofrecer un camino claro para resolverlo.
La recuperación comienza antes de enviar un formulario: etiquetas persistentes, requisitos visibles y ejemplos útiles ayudan a responder correctamente. Si algo falla, el mensaje debe identificar el campo, explicar el problema y orientar la corrección.
Principio esencial
Ayuda a la persona a acertar a la primera; si falla, ayúdala a entender qué ocurrió, dónde y cómo corregirlo.
Antes del error
Anticipa formato, obligatoriedad, límites y consecuencias sin sobrecargar la tarea.
Después del error
Conserva los datos, lleva la atención al problema y ofrece una sugerencia específica.
02 · Ciclo de una tarea
Cuatro señales para mantener el control
Una tarea comprensible comunica su estado desde el primer campo hasta la confirmación final.
Instrucciones
Explican formato, condiciones y ejemplos antes de que la persona tenga que adivinarlos.
Etiquetas persistentes
El nombre del campo continúa visible después de escribir y no se sustituye por un placeholder.
Errores específicos
Un texto señala el campo, describe la causa y propone una forma concreta de corregirla.
Confirmación
Antes de una acción crítica se puede revisar, corregir o cancelar sin perder información.
03 · Personas y contextos
¿A quién beneficia?
Los estados claros reducen la memoria necesaria, la incertidumbre y el costo de recuperarse.
- Personas que utilizan lectores de pantalla: reciben mensajes asociados al campo y anuncios de cambios importantes.
- Personas con baja visión o daltonismo: no dependen únicamente de un borde rojo para reconocer un error.
- Personas con discapacidades cognitivas o de aprendizaje: conservan etiquetas e instrucciones mientras completan la tarea.
- Personas con movilidad reducida: evitan repetir formularios extensos o buscar el campo incorrecto.
- Cualquier persona bajo presión, con conexión inestable o datos complejos: puede revisar antes de confirmar y corregir sin empezar de nuevo.
04 · Barreras frecuentes
Cuando el sistema culpa o deja sola a la persona
05 · Criterios de diseño
Qué debe comprobarse
Cada estado debe ser perceptible, comprensible y accionable.
Etiquetas visibles y persistentes
Cada campo conserva su nombre al escribir. El placeholder puede ofrecer un ejemplo, pero no reemplaza la etiqueta.
Relacionado: WCAG 3.3.2 · Nivel A
Obligatoriedad explicada
Marca los campos obligatorios con texto o un símbolo explicado y utiliza también el atributo required cuando corresponda.
Relacionado: WCAG 1.3.1 y 3.3.2
Error identificado con texto
El mensaje nombra el campo y describe qué dato no se aceptó. El color puede reforzarlo, pero nunca ser la única señal.
Relacionado: WCAG 1.4.1 y 3.3.1 · Nivel A
Sugerencia de corrección
Cuando se conoce una solución y no compromete la seguridad, ofrece el formato esperado o un ejemplo útil.
Relacionado: WCAG 3.3.3 · Nivel AA
Revisión de acciones críticas
Permite revertir, comprobar o confirmar información antes de compromisos legales, financieros o modificaciones importantes de datos.
Relacionado: WCAG 3.3.4 · Nivel AA
Estados anunciados
Los mensajes dinámicos importantes se comunican a tecnologías de asistencia sin mover el foco innecesariamente.
Relacionado: WCAG 4.1.3 · Nivel AA
06 · Ejemplo aplicado
De “dato inválido” a una corrección posible
Problema
Contexto y solución ausentes
<input placeholder="Correo" class="error">
<span>Dato inválido</span>- La etiqueta desaparece al escribir.
- El error no identifica el formato esperado.
- La clase visual puede depender solo del color.
Solución
Nombre, asociación y sugerencia
<label for="correo">Correo electrónico</label>
<input id="correo" aria-describedby="correo-error">
<p id="correo-error">Incluye @ y un dominio.</p>- La etiqueta permanece visible.
- El mensaje está asociado al campo.
- La sugerencia explica cómo corregirlo.
Decisión clave: un buen mensaje no dice solamente que algo está mal; reduce la distancia entre el problema y su solución.
07 · Práctica
Comprueba lo aprendido
Experimenta con dos respuestas de error, compara etiquetas y revisa un envío simulado.
Actividad 1: compara dos respuestas de error
Activa ambos ejemplos y observa qué información recibe la persona.
Respuesta A
Correo electrónico
Resultado: el borde cambia de color, pero no se explica el problema.
Respuesta B
Correo electrónico
Error en correo electrónico: incluye @ y un dominio, por ejemplo nombre@universidad.ac.cr.
Prueba las dos respuestas.
Actividad 2: pon a prueba tu memoria
Escribe un nombre de ejemplo en ambos campos. Después compara cuál mantiene visible el dato solicitado.
Patrón A: solo placeholder
Actividad 3: revisa antes de confirmar
Esta solicitud simulada contiene un correo incompleto. Edítalo y confirma la revisión.
Resumen de solicitud
- Nombre
- Ana Solís
- Correo
- ana@una
- Programa
- Diseño inclusivo
08 · Ficha rápida
Prevención y recuperación en seis preguntas
- ¿La etiqueta permanece?
- Comprueba que el nombre del campo siga visible después de escribir.
- ¿Sé qué es obligatorio?
- Informa los requisitos antes de intentar enviar.
- ¿El error está identificado?
- Nombra el campo y no dependas únicamente del color.
- ¿Puedo corregirlo?
- Ofrece una sugerencia específica y conserva el resto de los datos.
- ¿Se anuncia el cambio?
- Comunica mensajes dinámicos a las tecnologías de asistencia.
- ¿Puedo revisar?
- Antes de una acción crítica, permite comprobar, editar o cancelar.
Resultado
Progreso de las actividades
Completa las tres actividades para terminar el tutorial.