Can you make toast messages accessible?

I will answer this question. Let me explain with a post I wrote on LinkedIn last week:

Github’s Design System has banned toast messages.

Toast messages are little messages that appear on top of the UI to give you feedback about an action you just took.

Banning toast messages is an excellent decision because they’re not accessible and have bad UX.

Here’s a few reasons why:

(1) They disappear automatically after a few seconds - at best this is stressful, at worst you’ll miss it

(2) They obscure the content underneath which is frustrating and slows you down

(3) They’re hard to spot because they’re small and shown at the edge of the screen

I received 135 comments.

Let’s go through the 4 main comments that challenged Github’s decision. That’s where we learn the most:

Comment #1: “What about actions that take a long time to process - during this time you can work on other things.”

It depends on the action.

Sending an email is instant so there’s no need for a toast message.

But let’s say you’re exporting videos which take a long time. You don’t want to stop users from working on other things.

In this case, give users a clear message that the export has started and that the user will be notified when the export is ready to download.

That notification might come via email or via the UI or both.

Comment #2: “Toast messages are great for updates like ‘Changes saved’ so that the user doesn’t rage spam the button and make unnecessary requests to the server.”

If you feel like you have to “rage spam” the button to get your changes saved, then you’ve got other problems.

Firstly, when you click a button you should get instant feedback that confirms that you did indeed click the button.

Secondly, if the server is so slow to perform an action that you end up clicking the button again, your server is way too slow.

Thirdly, if you want to protect your server from multiple clicks, you can do that in other ways.

Toast messages don’t solve the root cause of any of these issues.

Comment #3: “You can always make the toast message more obvious and increase the time it stays on screen”

You can make the toast message bigger, but that means it will obscure even more of the content beneath.

Similarly, you can increase the time it stays on screen but that forces users to stop what they’re doing to dismiss the message.

Users shouldn’t have to stop what they’re doing to tidy up the UI for themselves.

But the most interesting comment was from accessibility specialist, Attila Vago:

Comment 4: “Banning toast messages isn’t the solution, improving them is. You can absolutely make toast messages accessible.”

I’ve met a few accessibility specialists like Attila.

When you’re an accessibility specialist, your main job is to make something accessible. Suggesting that the pattern is banned is not usually part of their role.

Also, a lot of accessibility specialists like the challenge of making something more accessible.

But ultimately, some patterns are just plain inaccessible.

Like I mentioned already, toast messages disappear automatically.

You can totally announce that fact in screen readers but that just makes the UX the same level of bad for users who don’t use screen readers.

Here’s what I mean:

Imagine you’ve got cognitive impairments or you’re stressed out or you’re tired, or you receive a phone call just at the moment you took an action.

By the time you get back to what you were doing, you’ll have no clue about what you’ve just done.

That is just shit design.

But you don’t have to take my word for it. Github’s design team didn’t decide to ban toast messages on a whim.

They did thorough, moderated, task-based usability testing with blind, low-vision and motor control disabilities. The research included people who use a wide range of assistive technology including NVDA, JAWS, VoiceOver, Windows Magnifier and Dragon.

And the tests showed significant problems that cannot be addressed with a sprinkling of ARIA.

Despite this fact, Attila insists that toast messages can be made accessible.

When I asked him how he would do that, one of the things he said was:

“Your incessant argument that they disappear is invalid - they don’t have to disappear and it has been said a million times. How can you not understand that it is nothing but an implementation problem?”

Sure, we could totally change the toast message so that: