Toast & Alertas

Los toasts informativos o de éxito deben usar role="status" con aria-live="polite", que anuncia al lector de pantalla en el siguiente momento disponible sin interrumpir al usuario. Los toasts de error deben usar role="alert" con aria-live="assertive", que interrumpe inmediatamente porque el error requiere atención urgente. El role="alertdialog" se reserva exclusivamente para cuando el toast solicita acción explícita del usuario (confirmación, decisión) y debe mover el foco al diálogo. Usar role="alert" para mensajes informativos crea una experiencia AT ruidosa y agotadora; usarlo solo cuando el usuario debe actuar de inmediato.

Un toast debe ofrecer como máximo una acción secundaria: Undo o Retry son los arquetipos ideales porque son reversiones inmediatas de una operación única. Cuando el toast contiene dos CTAs ("Cancelar" y "Confirmar") la anchura del componente se vuelve insuficiente para dar a los botones espacio visual adecuado, el tap target se comprime en mobile, y cognitivamente el usuario debe tomar una decisión binaria en un componente temporal que puede desaparecer antes de que decida. Esas decisiones binarias pertenecen a un dialog modal que no desaparece automáticamente, permite leer el contexto con calma y no compite con el flujo de la interfaz principal.

El rango de 4 a 5 segundos para auto-dismiss de toasts informativos proviene de estudios de tiempo de lectura: un mensaje corto de 5-8 palabras se lee en 1-1.5s, por lo que 4s ofrece margen 2.5-3× para procesarlo con comodidad. Ir por debajo de 3s excluye a personas con dislexia o baja velocidad de lectura. Los toasts de error nunca deben desaparecer automáticamente: el usuario debe leer el mensaje, entender la causa, y decidir la acción correctiva; si el error desaparece mientras el usuario está procesándolo, genera confusión sobre si el problema fue resuelto. El botón de cierre explícito en errores es obligatorio.

La posición canónica del toast varía por plataforma y tiene fundamentos ergonómicos y de convención. En Android, el toast aparece en la parte inferior centrada, lejos del área de interacción principal del pulgar. En iOS, el banner de notificación aparece en la parte superior (donde el sistema operativo ubica sus propias alertas), creando consistencia con el entorno del sistema. En web desktop, bottom-right es la convención establecida por Slack, GitHub, Linear y otros productos de referencia, porque no tapa el contenido principal y el área inferior derecha es ergonómicamente periférica. Desobedecer estas convenciones crea fricción porque el usuario busca el toast en el lugar donde lo ha visto miles de veces antes.

El foco del teclado no debe moverse hacia el toast cuando aparece; hacerlo interrumpe el flujo del usuario que está completando un formulario, una selección, o cualquier tarea en curso. Los toasts usan regiones live (aria-live) que anuncian sin mover el foco. Para usuarios de tecnologías asistivas que quieren interactuar con el toast (por ejemplo, activar el botón "Deshacer"), la convención emergente es ofrecer un hotkey opt-in: F8 o F6 mueve el foco a la región de notificación, similar a como los IDEs permiten moverse entre paneles sin abandonar el área de edición. Escape devuelve el foco a su posición anterior. Esta combinación respeta el flujo de usuarios sin discapacidad mientras da acceso completo a usuarios AT.

Apilar más de 3 toasts simultáneamente crea ruido visual, compite por la atención del usuario, y llena el espacio periférico que en principio debía ser inocuo. La cola FIFO (first in, first out) garantiza que el usuario no se pierda mensajes: si un cuarto toast llega mientras hay 3 activos, espera en cola hasta que el más antiguo se descarte. Material Design 3 es más estricto en mobile: recomienda un único snackbar visible en cualquier momento dado, argumentando que el espacio vertical en pantallas pequeñas no permite apilar sin tapar contenido significativo. La ilusión de profundidad con scale() y translateY comunica que hay más mensajes debajo sin revelarlos todos de golpe.

El botón de acción en un toast (como "Deshacer" o "Recuperar") es accesible para usuarios sin discapacidad visual con buenos reflejos, pero problemático para usuarios de teclado o lector de pantalla: el toast puede desaparecer antes de que el usuario lo alcance con Tab, la zona de foco puede no ser obvia, y el timer de auto-dismiss crea presión temporal. La solución es duplicar la acción en la UI principal: si el archivo "eliminado" sigue recuperable, mostrarlo en la lista con un estado visual diferenciado ("En papelera") junto a un botón "Recuperar" estático que no desaparece. El toast es la notificación rápida para usuarios ágiles; la UI principal es el safety net universal que garantiza WCAG 2.1.

El timer de auto-dismiss debe pausarse cuando el cursor está sobre el toast o cuando cualquier elemento del toast tiene foco de teclado. Sin esta pausa, el toast puede desaparecer precisamente cuando el usuario está intentando leer el mensaje completo o mover el cursor hacia el botón de acción. WCAG 2.1 SC 2.2.1 (Timing Adjustable) requiere que los timings controlables se puedan pausar. El cambio visual durante el estado hover (color de barra, indicador "Pausado") es importante: confirma al usuario que el timer se detuvo y que tiene tiempo para actuar sin presión. CSS animation-play-state: paused en el selector :hover o :focus-within implementa esto sin JavaScript adicional.