Last week I read that Laravel’s starter kits now ship with Toast notifications by default. Many seem excited about the news. I’m not one of them.
Toast notifications may look clean and modern, but they pose serious issues for many people. I believe that making them a default in a popular framework like Laravel is a wrong direction.
Let me explain why this is a poor choice, and why it should matter to you, even if you consider yourself a backend developer.
What’s wrong with Toast notifications?
They can be invisible to screen reader users
If a Toast notification isn’t correctly set up with an ARIA live region, screen reader users will not hear it. Screen readers are used by those who are blind, visually impaired or have other disabilities like dyslexia.
In fairness to Laravel, my initial tests with two screen readers did announce the notifications. I set up a basic Laravel app using the Livewire starter kit and tested the settings page. I tested with the widely used NVDA screen reader and MacOS’s inbuilt VoiceOver.
Whether the Toast notifications remain discoverable to screen readers as an app develops remains unclear.
They disappear before many users can read them
Cognitive impairments are common. They can impact the speed at which someone processes information, or cause attention difficulties. The short-lived nature of Toast notifications means that many users will not have chance to read them.
Once the notification has disappeared, some will be left unaware of the status of the process they’ve just triggered. This leaves the user having to guess, refresh or simply try again.
You don’t have to have a cognitive impairment for this to affect you. If a user is distracted — perhaps a colleague interrupts them or the phone rings — they miss the notification too.
They appear off-screen for screen magnification users
For those with a visual impairment, screen magnification is a commonly used assistive technology. For these users, they typically only see a fraction of the screen at a given time.
Toast notifications typically appear in the corner of the viewport. For screen magnification users, these notifications will often appear off-screen with no indication of any status change.
As someone who regularly needs to use screen magnification, this is a real problem.
They break when users increase text size
Lots of users choose to change their browser’s default text size. A Dutch study has found that 26% of smartphone users increase the text size.
A well-configured app will scale text to support the user’s preferences. This should include Toast notifications.
My quick tests of Laravel’s Toast notifications revealed that they do scale with the browsers text size settings. However, this does reveal another common issue with Toast notifications: the text can overflow the viewport.
When the notification doesn’t fit the viewport, it means some of the text becomes hidden to the user.
Keyboard users should be able to dismiss them
If a user is navigating by keyboard, they should be able to tab to close it as soon as it appears. However, the close button of a Toast notification is often not the next logical focusable element.
My tests with Laravel’s implementation revealed it is possible to dismiss the notification with the keyboard, but navigating to the close button was problematic. It was not the next element in the tab sequence.
The real cost of Toast notifications
When a notification fails to be fully perceived by a user, they lose confidence in your app.
Did a form submit? Was a payment successful? Did the file upload? If the only way to confirm is by refreshing the page and checking for yourself, you have a problem. If this becomes a repeated experience, you lose a user.
Accessibility failures don’t just impact a small group of edge case users. Disabilities affect a large number of people, we just often don’t recognise this.
Accessibility failures can also impact everyone when we find ourselves in situations that affect our workflow: a user that is stressed, distracted or mentally fatigued; or someone that is using a screen in bright sunlight.
When we build applications that work for those with assistive needs, we build for everyone.
Why this is a backend developer’s problem
As backend developers, we often hold a lot of influence over choice of framework and starter kit.
Admin panels and internal tooling are often built entirely by backend engineers; frontend developers and UX specialists often never get involved. It means user experience and accessibility are often forgotten.
Backend developers rarely talk about accessibility. Either through a lack of awareness or a misplaced assumption that it is someone else’s problem. However, our decisions often have a direct impact on the people that need accessibility considerations.
The people that use are apps are real. Many have assistive needs. They deserve to be able to work with the tools we build like everyone else.
When you choose a framework, starter kit or UI component library, you are making an accessibility decision. When you choose to use a default that creates barriers for many users, you are making an accessibility decision. This is your choice, and your responsibility.
The alternative
Instead of using Toast notifications, we should use a more inclusive solution. I would recommend using inline notifications that respect the user’s text sizing preferences; and if you must make them dismissible, let the user decide when they want the message to disappear.
Good notifications should be persistent and visible.
Accessibility is more than a frontend developer or UX specialist’s problem. It’s an engineering problem. We must recognise that the decisions we make have consequences. Enabling Toast notifications by default is one of them.