A picture of burnt toast with a sad face carved into it. The words “toasts are ableist” are visible over it.
Why bury the lede? Toasts only work if you have peripheral vision. The whole idea is to have a “less intrusive but still available” notification. In order for “still available” to be anything other than “user must remember” is to keep that notification on screen. If you can’t see that part of the screen or the screen at all, the “available” part fails.
What Is It
Toasts are a non-modal, status message presented to the user due to an action they took or the system took that doesn’t require immediate action. They can be either persistent until acknowledged or timed. Things like background process results, non-critical errors, messages, or other “doesn’t affect what you’re currently doing” sort of things.
Useful information not important enough to interrupt you.
The Problem
The primary problems, and I’m not talking about the technical implementation problems, are those of persistence and the sensation thereof.
Persistence
The primary differentiator between typical alerts and toasts are those of persistence. Typical alerts are intrusive for a reason. And action the user took is in error some how and they need to address it then and there. Typical messages don’t let you continue until you’ve fixed the problem. They are persistent.
They can be further differentiated by modal and non-modal errors. When modal, meaning the error traps your focus and doesn’t let you move, require action to move on.
Non-modal errors are errors that prevent progress but don’t necessarily trap your attention. Firm submission errors are a good example. You have to fix the form problem before moving on.
Both types stick around and prevent advancing until you do something with them.
Sensation
Modal errors are impossible to miss. They taken the user’s primary focus until addressed. They are fully sensate in that they take your primary method of perception and hold it - sighted users that the cursor, screen reader users that’s the voice readout.
Toasts tend not to do this. They pop in, are seen (or heard in the case of screen readers), and then tend to disappear after a few seconds.
So…?
Audio interfacing tools are generally reading contents while a user is interacting with a page or application. Toasts, depending on the way it is constructed, generally default to polite notifications. Polite notifications get inserted at the end of the currently-being-read component the tool has in focus.
Maybe Interrrupt, Maybe Not
If a user takes an action, it may interrupt the currently-being-read element and potentially drop the toast message.
If what Is being read is long, the toast may not be read until after it disappears which means these users may ot be able to access that information.
If the alert is short or generic, it may or be noticeable and be missed which recreates the above timing problem.
Requiring Recall
Following current design practices around toasts, the messages generally appear at the bottom (right) of the screen. Assuming this mirrors the page structure, that would place the toast after main content. If a non-visual user hears the message but wants to hear it again, they have to navigate through all the content on the page before the toast to get to it.
If the toast is timed, it may not be there when the user gets to it.
If the toast is timed BUT will persist with hover or focus, screen reader virtual focus will not trigger these states. Thus, the message may disappear as the user arrives.
Temporary toasts must have a reasonable time limit set. Ideally, this is user-override-able to account for WCAG 2.2 Enough time which requires that users be able to respond to an action appropriately.
Preferably, there is NO timing to avoid these issues but, similarly, it may be more effective to make the message modal in these cases.
Problems Endemic to Toasts
Toasts have an expectation of “alert me but don’t annoy me.” They rely on the “corner of the eye” motion detection by having them appear in the periphery and rely on visual habituation to be discoverable without breaking user attention.
That requires sight. There’s no hearing-based equivalent that is makes something persistently audible without causing distraction. A biological equivalent would be Having a second voice whispering to the user about the status message’s persistence underneath the primary screen reader audio.
Setting aside the injected confusion we’d be giving screen readers, there’s no true habituation to that and would still be drawing attention or requiring cognitive effort to ignore.
Therefore
Toasts demand specific abilities for them to remain useful. Users without those abilities or some limitation to them are left out. Thus: ableist.
How Do You Fix It?
All the solutions I’ve seen successful are some from of “get into the users’;s face at a more convenient time,” assuming the notification isn’t really impotant. enough to be modal.
Convenient Nudge
For example, if the user is logging in or out, offering a reminder that there are messages to review, that can be far less jarring or lose-able.
Central Tracker
Creating a central place for them that a user can jump to, get an indication of message count, and an easy review method for each message makes the messages far less problematic. This still requires some amount of recall but the review behavior can be learned rapidly.
Retrigger Ability
Being able to re-trigger the message works similarly to the central tracker, though potentially only triggering the last message makes more sense and allowing a user to clear > trigger previous-1, clear, trigger previous-1, etc until all are processed.
Conlusion
I suspect most don’t agree with me here as temporary alerts are becoming more prevalent, just none of them solve the “read that back to me” problem well. The more complex the thing a user is doing the more problematic the interruption becomes.
Developers and designers need to assume users are going to miss the messages and need to refind them. Or consider how important your message really is. Do you even need it?