GitHub ya no usa Toasts

 (primer.style)
16 puntos por GN⁺ 2025-12-12 | 1 comentarios | Compartir por WhatsApp
  • La UI de notificaciones toast ya no está recomendada en GitHub debido a problemas de accesibilidad
  • La estructura de notificaciones temporales que desaparecen automáticamente corre el riesgo de incumplir los criterios de accesibilidad visual y funcional (WCAG)
  • GitHub propone banner y dialog como alternativas de retroalimentación persistente y accesible
  • Los toast también presentan varios problemas de usabilidad, como en pantallas grandes, multitarea y la tendencia a ignorar banners
  • Para lograr accesibilidad y una experiencia de usuario consistente, se deja de usar Toast en todo el sistema de diseño Primer

Resumen de Toasts

  • Un toast es una pequeña ventana de notificación rectangular que aparece brevemente en la esquina inferior de la pantalla y se activa por una acción del usuario o del sistema
  • Está diseñado para desaparecer automáticamente después de cierto tiempo, lo que implica problemas de accesibilidad y usabilidad
  • Por estas razones, GitHub recomienda formas de comunicación más estables y accesibles

Alternativas a Toast

  • Es necesario elegir la UI adecuada según el propósito
    • Las notificaciones simples de éxito pueden confirmarse en la propia pantalla de resultado sin retroalimentación adicional
    • Las tareas complejas pueden comunicar el estado exitoso mediante un banner o con contenido progresivo
    • Las tareas fallidas deben mostrar la información del error mediante un banner o un dialog
  • En el caso del envío de formularios, los formularios simples no requieren confirmación adicional; los formularios complejos pueden usar una página de confirmación intermedia o un banner
  • Para la validación de entradas, se deben usar los componentes de validación de formularios ya existentes en Primer
  • Las tareas de larga duración deben comunicar su finalización mediante un banner u otros canales, como correo electrónico o notificaciones push
  • Si ocurre una desincronización de sesión, se debe informar la necesidad de recargar mediante un dialog o un banner

Consideraciones de accesibilidad (Accessibility Considerations)

  • La UI de toast puede incumplir varios criterios de éxito de WCAG
    • 2.2.1 Timing Adjustable (A): debe permanecer visible hasta que el usuario la cierre directamente
    • 1.3.2 Meaningful Sequence (A): la discrepancia entre el orden del DOM y el orden visual puede causar confusión al usar tecnologías de asistencia
    • 2.1.1 Keyboard (A): las interacciones dentro del toast deben poder controlarse con el teclado
    • 4.1.3 Status Messages (AA): su presencia debe comunicarse a las tecnologías de asistencia de manera no intrusiva
  • Además, hay otros criterios que también podrían verse afectados
    • 1.4.4 Resize text (AA): al ajustar el tamaño del texto existe riesgo de que tape la pantalla o genere overflow
    • 1.4.10 Reflow (AA): al hacer scroll horizontal se debe garantizar la accesibilidad por teclado
    • 2.4.3 Focus Order (A): puede producirse confusión en el orden del foco
    • 3.2.4 Consistent Identification (AA): es necesario mantener consistencia en el código

Consideraciones de usabilidad (Usability Considerations)

  • En pantallas grandes, el toast puede quedar fuera del campo visual y pasar desapercibido
  • Si se cierra automáticamente, el usuario puede perder el mensaje mientras realiza otra tarea
  • Ocultamiento de UI: el toast puede cubrir elementos importantes, como botones en la parte inferior
  • Los usuarios que amplían la pantalla pueden no ver el toast si queda fuera del área ampliada
  • Problemas de memoria de trabajo: al desaparecer automáticamente, no se puede volver a revisar la información
  • Tendencia a ignorar banners: el uso excesivo hace que los usuarios tiendan a ignorarlos
  • Desajuste de ubicación: la distancia física entre la UI que lo activó y el toast puede generar confusión sobre su relación
  • Acción de cierre incorrecta: la tecla Esc puede cerrar también otras partes de la UI

Material adicional de referencia

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-12-12
Comentarios en Hacker News
  • Mientras daba una charla sobre accesibilidad, experimentó una situación en la que había un retraso de 3 segundos después de hacer clic, por lo que parecía que no pasaba nada
    • Al hacer clic en el banner, tenía que esperar sin ninguna indicación y luego terminaba en una página no relacionada, lo que resultaba frustrante
    • Cree que el problema es la falta de retroalimentación que indique que está cargando
    • Alguien dijo que eso era simplemente un enlace `` y que el retraso solo se debía a que la página era innecesariamente pesada
    • Otra persona señaló que incluso en 4G lento responde de inmediato, sugiriendo que podría ser un problema del navegador o de la red
  • Le pareció interesante leer la documentación de GitHub Primer
    • Aunque no esté de acuerdo con todo, siente que hay cosas que aprender y que es mucho mejor que hacerlo por intuición
    • Como referencia, Apple y Android también ofrecen sus propias guías de diseño
  • Ojalá por fin este tipo de tendencia se extienda
    • Ha perdido demasiados mensajes por culpa de las notificaciones tipo toast
    • Otro usuario estuvo totalmente de acuerdo con la frase “no se recomienda usar toasts por problemas de accesibilidad” y enfatizó que, aunque hubiera existido un centro de notificaciones, seguiría siendo una mala solución
  • A mí me gustan los toasts para confirmaciones no intrusivas, pero me parecen inadecuados para transmitir información importante
    • Otra persona explicó con más detalle los distintos contextos de uso de los toasts
      • Respuesta inmediata al hacer clic en un botón → es mejor dar retroalimentación desde el propio botón
      • Respuesta a un atajo de teclado → está bien
      • Aviso de finalización de una tarea larga → está bien, pero hace falta una bandeja de notificaciones persistente
      • Mostrar una advertencia al entrar en una página → si es importante, debería mostrarse dentro de la página como una notificación permanente
    • En React, como es fácil hacer una llamada global a toast(), tiende a abusarse, pero propone que una estructura como useAlerts() es mucho mejor
  • Para mí, los toasts son como un torniquete
    • Son útiles para contener temporalmente un problema urgente, pero no deberían mantenerse a largo plazo
    • En un proyecto nuevo, se podrían poner temporalmente cuando falta retroalimentación y luego ir quitándolos uno por uno a medida que mejora la UI
    • Una organización grande como GitHub no necesita este tipo de parche temporal, pero un equipo pequeño podría ser distinto
  • Le gustó la parte de la documentación de GitHub donde se dice que “hace falta retroalimentación adicional al crear muchos Issues”
    • También le gustaría ver ese tipo de retroalimentación en GitHub Actions, porque tarda demasiado en aparecer el resultado después de ejecutar algo
  • Le gusta la idea de usar los toasts como un registro de acciones en toda la UI
    • En lugar de una retroalimentación que desaparece cada vez que haces clic, hay ejemplos bien implementados como Sonner
  • Parece que ya es momento de considerar soporte nativo para toasts a nivel del navegador
    • Podrían mejorarse aspectos de accesibilidad como el control del tiempo, un centro de notificaciones y la integración con lectores de pantalla
    • Visualmente están bien, pero muchas veces desaparecen demasiado rápido y se pierden
    • Es difícil entender directamente los problemas que enfrentan las personas con discapacidad visual, pero le gustaría escuchar formas de mejorar su accesibilidad
  • La ventaja de los toasts es que son fáciles de implementar y requieren poco esfuerzo de diseño
    • La desventaja es que son fáciles de pasar por alto y corren el riesgo de superponerse a otra información
    • Si hay margen, cree que es mejor eliminar todos los toasts
    • Otra persona señaló que “como son fáciles de hacer, se abusa de ellos como un parche que finge resolver el problema”
    • Otra más dijo que había usado toasts simplemente como retroalimentación tranquilizadora
    • En cambio, alguien sostuvo que “los toasts son una herramienta útil para dar retroalimentación inmediata sobre eventos de baja importancia” y que son más eficientes que una ventana modal o un área fija
    • Criticó la visión en blanco y negro de descartarlos por completo solo por el abuso de la herramienta
  • Vio un texto que decía que “la eliminación de los toasts por parte de GitHub es una mala noticia para la accesibilidad”
    • A alguien esa afirmación le pareció extraña
      • Considera exagerado decir que, en vez de eliminar los toasts, GitHub debería haber creado un estándar de navegador a través del W3C
      • Cree que el simple hecho de que el elemento creado aparezca en la lista ya es retroalimentación suficiente
    • Otra persona dijo que “si se afirma que los toasts son malos para la accesibilidad y la UX, es contradictorio criticar a GitHub por no haberlos estandarizado en el navegador”