I assume you don't want a full screen reader if you're not already using one, but if toasts are properly implemented (big if), screen readers can actually present them accessibly via the ARIA alert pattern[0].

Wanted to mention in case you're not aware and maybe there's some tool somewhere (or some way to configure a screen reader?) so that you can keep your simple zoom workflow but still benefit from the ARIA alert pattern.

[0] https://www.w3.org/WAI/ARIA/apg/patterns/alert/

Thanks for this! I visited your link and hadn’t seen such a nice demo with working code on w3.org before: whoever worked on these pages deserves kudos.

None of that invalidates what your parent comment is saying. They’re not saying you should use toasts to the detriment of other options, but in addition to them. If anything, your comment reinforces the notion that redundant information is beneficial because you don’t know where the user is looking.

Yes. For example: while OP uses a magnifier, lots of other people use a screen reader. "Loading indicator disappeared" is a tricky thing to communicate clearly with audio. "Toast: save successful" is trivial.

This is something that I think a lot of people miss. There is for sure a reason why google has that toast. One shouldn't just dismiss what the big tech guys do in terms of UI because they are among those who have the most resource to spend on it, and also the most amount of users. So for them it makes a lot of sense to spend effort to cater to people with various disabilities, as there is financial profit in there for them.

For a small regional golf court chain who want to build an online tool for reserving tee times? They most definitely won't have the budget to do things entirely properly.

I was attempting to suggest toasts "are bad UX", but your points make a lot of sense. Thanks.

There was some discussion in the article and elsewhere in the thread about how a toast with an undo button could be a very useful interface pattern. It wouldn't work for me, so I would hope that UX designers that want to use toasts would also design in other means to find and execute an undo action.

For you, my comments reinforce that toasts are "good UX" when they contain redundant information. I'm warming to the idea. In parallel, for me, this discussion is reinforcing my intuition that "actions and feedback as close as possible to the area of interaction" should be considered the primary vector.

Same here, in the last 2 years, my eyesight has gone down a lot (combination of astigmatism and presbyopia is not great). I used to love the growl style notifications from macos, now I always miss them (and often miss the alert that I only have 5% battery left).

The issue with the not seeing toast notifications is that in some apps it’s the only true notification that the request went through to the server so missing them when they failed for whatever reason is rather annoying

I think this is because a global toast service is trivial to implement, one service class / event listener, one UI component. It takes one ticket to make, and then it's just a matter of implementing the event publishes // serviceclass calls. This is much faster than implementing a plurality of ways to indicate loading and resulting success/fail.

In other words, it's a crutch that is often taken when there isn't enough budget/resources to make a proper UI (Or enough care/love/interest/skill).

I have definitely myself gone down the quick path of implementing only server side validation + toast service for projects where the customer just does not have the budget to do things entirely properly.