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)
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?
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?
anilakar•8h ago
tpetry•7h ago
urban_alien•7h ago
leosanchez•7h ago
slig•7h ago
onion2k•7h ago