Notificaciones y toasts: cuándo interrumpir y cuándo no
Un toast es un aviso breve que aparece y desaparece. Cuándo usarlo para confirmar una acción, cuándo no, y cómo evitar que se pierda o moleste.
¿Qué es una notificación de tipo toast?
Es el mensaje flotante que aparece en una esquina cuando guardas un archivo, cuando un envío sale bien o cuando un elemento se borra y ofrece deshacer. El nombre viene de su parecido con la tostadora: sale, se ve un momento y se va.
Los sistemas de diseño la describen igual. Por ejemplo, el sistema de diseño del Gobierno de Singapur lo define como un componente para notificaciones rápidas, con un retraso por defecto de 5 segundos para mensajes breves y rutinarios (Singapore Government Design System, “Toast”).
¿Por qué le importa a un diseñador?
Porque es una de las formas más baratas de dar feedback. Una confirmación evita que alguien se pregunte si el clic funcionó. Pero el mismo patrón, mal usado, es una fuente de ruido: mensajes que aparecen cuando nadie los necesita, o que tapan el botón que la persona estaba a punto de pulsar.
Adrian Roselli, que lleva años revisando patrones de notificación, parte de una premisa incómoda: la gente va a perderse los toasts. Por eso propone preguntarse primero si el mensaje aporta valor. Si no lo aporta, no debe mostrarse (Adrian Roselli, “Defining Toast Messages”).
¿Cuándo sí usarlo?
El toast encaja en tres casos:
- Confirmar una acción sin consecuencias graves. «Borrador guardado» o «Enviado a Ana».
- Ofrecer deshacer después de un borrado. Es el caso más útil del patrón. Consulta las salvaguardas para acciones destructivas para ver cuándo conviene confirmar antes y cuándo deshacer después.
- Avisar de un proceso en segundo plano que terminó. «Exportación lista» o una subida completada.
Una regla simple: si la persona puede seguir trabajando sin leer el mensaje y no pierde nada si se le escapa, el toast funciona.
¿Cuándo NO usarlo?
- Para errores que bloquean la tarea. Si el pago falló, la persona necesita leerlo y actuar. Eso es un aviso que se queda en la pantalla, no un toast.
- Para instrucciones. El texto que explica cómo completar un paso no puede desaparecer.
- Como única señal de algo crítico. La guía de Singapur lo dice sin rodeos: no uses un toast como único lugar de una instrucción crítica, ni para contenido que deba seguir visible hasta que se lea.
- Para contenido que deba leerse con calma. Un texto largo se lee mal en un aviso que se va solo.
- Varios seguidos. Si una acción dispara tres toasts, el usuario deja de leer el tercero.
¿Cómo hacerlo accesible?
Aquí es donde la mayoría de los toasts fallan. Estos son los puntos que señalan las fuentes de este artículo:
- Tiempo y pausa. Según Roselli, un aviso que desaparece solo tras unos segundos incumple WCAG 2.2.1 (Timing Adjustable), salvo que se ofrezca una forma de ajustar el tiempo. Como mínimo, pausa el temporizador cuando el cursor o el foco esté sobre el aviso. El sistema de diseño de MiHCM lo hace así, con 5 segundos por defecto.
- Anuncio a lectores de pantalla. El mensaje debe anunciarse con una región en vivo. Para avisos no urgentes,
status(educado) olog(útil cuando importa el orden de los mensajes) son las opciones habituales. Reservaalertpara información urgente que requiere atención inmediata. Roselli recalca que la región debe existir en la página antes de que aparezca el mensaje: si se crea justo cuando hace falta, probablemente no se anunciará. - Sin robar el foco. Un toast no debe mover el foco automáticamente en actualizaciones rutinarias. Quien está escribiendo debe seguir escribiendo.
- Botón de cierre real. Si hay un botón para cerrar, que sea un botón con nombre, alcanzable con teclado y lo bastante grande para tocarlo. En MiHCM, por ejemplo, la tecla Esc cierra el aviso con foco.
Roselli va más lejos: afirma que ninguno de los patrones de toast que había encontrado pasaría una auditoría WCAG. Su alternativa es una región de mensajes fija en la parte superior, donde los avisos permanecen hasta que la persona los descarta. Su artículo es de 2020; antes de adoptar esa postura, prueba con lectores de pantalla reales. Esa prueba es parte de la revisión de accesibilidad de cualquier cambio.
Ejemplo
Ejemplo ilustrativo: una app de notas tiene un botón “Eliminar” que borra una nota al instante y muestra un toast de cinco segundos: «Nota eliminada». Un usuario que borra por error no tiene forma de recuperarla. El equipo cambia el patrón: al borrar aparece «Nota eliminada. Deshacer», el toast se pausa mientras el cursor o el foco están sobre él, tiene un botón de cierre, y la nota eliminada sigue recuperable desde la papelera aunque el toast ya no esté. El cambio no es estético. Es un cambio de qué puede recuperar la persona.
Errores comunes
- Mostrar un toast para cada acción, incluso las obvias.
- Poner en el toast algo que debería estar en la pantalla, como un error de formulario.
- Usar
alertpara cualquier mensaje y ensuciar la lectura del lector de pantalla. - Hacer que el toast tape el botón que la persona necesita pulsar.
- Confiar en que el toast se lee solo porque aparece.
Cómo empezar mañana
Haz una lista de todos los toasts de tu producto. Para cada uno, escribe qué pasa si la persona no lo lee. Si la respuesta es “nada”, déjalo. Si la respuesta es “pierde algo”, cámbialo por un aviso persistente o por un deshacer. Después prueba el flujo con un lector de pantalla y con el teclado. Si el toast no se anuncia o no se puede cerrar, ya tienes el primer ticket de accesibilidad.
Si te interesa cómo el sistema muestra en qué estado está, mira la conciencia de estado. Y si el aviso aparece porque algo tarda, el capítulo de estados de carga te dará el contexto.