It’s notable that accessibility isn’t mentioned once in this post, or, in fact, in the component’s documentation.
It's a red flag for sure. That said, there's nothing preventing toasts from being accessible: https://react-spectrum.adobe.com/react-aria/useToast.html
I think it would be accurate for GitHub to say, "GitHub no longer uses toasts because we didn't want to make the effort to make them accessible or usable."
They can technically, with ample constraints and a great deal of restraint, maybe end up complying with WCAG, etc., but all it takes is one developer saying "well a toast is easy" or "this isn't that important, make it auto-dismiss" and you're back in bad pattern town.
You see this with government web design systems - they have a very limited and constrained palette of patterns, because it allows for more consistency and reliable accessibility, versus having a bunch of tools that you just generally shouldn't use.
(The GitHub page linked above also makes a great case for how "making toasts accessible" isn't as simple as just having the right aria roles - lots of details the Adobe design doesn't seem to completely cover, unfortunately)
The first red flag was the repeated screenshots featuring Theo Browne, as if his thoughts or ideas carry any kind of authority.
Reasons that toasts are difficult to get rid of:
- Easy for developers to implement consistently.
- Providing feedback where actions are taken on elements not on the screen (like bulk actions on a data grid, or within our workflow).
- Dense UIs where actions are taken frequently and injecting an alert or banner to be dismissed adds a ton of work for users. Also, causing the UI to jump isn’t great.
Would love to hear solutions to the above.
This works well for the last category, because it provides feedback but it doesn't need to be dismissed. But it also typically needs to be implemented afresh in each place it's used, which means more fiddly developer work.
All that says, I've lost this battle plenty of times and a lot of the stuff I've worked on ends up getting toasts in the end because they're just so much easier to implement than anything else.
So I wouldn't take any inferences from their design system as gospel.
On MacOS… emails and push notifications create… toast messages
Read the above as a critique to your strong opinion and not an opinion of mine.
My opinion is that toasts are great for notifications that can be reviewed/checked later, like chat notifications or finished background tasks.
What should be avoided, just for the same reason as modals/dialogs, is an overuse, causing fatigue.
But what if you want to give details on why the action was unsuccessful? How do you show it near the button or change the button itself?
What stops you from placing these details you want as near as is reasonable to a button? Alternatively, placing the details near or in some container for the data/entity/element that the button relates to?
- macOS screenshots
- Linear toasts after every action (with common actions on them such as copy link)
I thought flashes were easier to see (not only for people with special needs). As it turns out, when you make things more accessible, everyone wins.
I went through a phase where I used toasts because it felt like everyone was using them and my product/design was "old". I happily went back to flash messages when I came back to my senses.
Sigh. So much of modern "UX design" seems to be lured by this siren call :(
Why do all these packages have so many downloads? Are all the CI / CD routines always downloading a fresh copy and not caching?
