Re: A question about immediate feedback

Hi all,
In my perspective, toast messages almost always fall afoul of WCAG 2.2.1. Even though they might seem minor or purely cosmetic, they often convey information that users need in order to understand what just happened or what to do next. When that information disappears after a few seconds without any way for the user to pause or review it, we’re creating a time-based barrier that a significant number of users can’t work around.
The key point in 2.2.1 is to make sure users have enough time to read and act on content. It’s not just about time limits on forms or sessions. If a toast is the only place a confirmation or error message appears, and it vanishes without user control, then users who need more time, whether they’re using a screen reader, magnification, or just processing more slowly, are put at a real disadvantage.
Scott O’Hara wrote a great post laying out some of the challenges with toast notifications from an accessibility standpoint (https://www.scottohara.me/blog/2019/07/08/a-toast-to-a11y-toasts.html). He pointed out that screen readers often miss these messages entirely unless they’re wired up correctly with live regions, and even then, timing and focus issues can make them unreliable. Erik Kroes took a stronger position and made the case that we’re better off just avoiding toast messages altogether if we can’t guarantee that everyone will be able to perceive them (https://www.erikkroes.nl/blog/burn-your-toast/). Adrian Roselli also called out how often developers treat toast messages as decorative, even when they’re delivering key feedback (https://adrianroselli.com/2020/01/defining-toast-messages.html). All three of these experts cite 2.2.1 as a significant SC to consider when deciding on a toast component instead of something else.
All three of those perspectives point in the same direction. If a toast message contains anything important, it needs to either stay present until the user dismisses it or be repeated somewhere else that’s persistent and perceivable. Otherwise, it’s creating a barrier, even if unintentionally.
It might feel like a small detail, but these are the kinds of small details that add up and shape the user experience. So while toasts may look clean from a UX perspective, they’re not a great solution unless they’re designed with accessibility top of mind.
Juliette Alexandria


On 6/26/2025 12:24:47 PM, Michael Livesey <mike.j.livesey@gmail.com> wrote:
Toast notifications are not a contravention of 2.2.1 Timing Adjustable where they are for notification only and require no action.

The key point of 2.2.1 is to allow users sufficient time to perform actions and input material. As the material below the SC bullets says:

"This success criterion helps ensure that users can complete tasks without unexpected changes in content or context that are a result of a time limit."

<dialog> modals, shown using showModal(), are relatively easy to style and have wide cross browser support for retaining the tab focus in the modal and allow Escape to close the modal.

My feeling here is that a toast notification is the preferred UX and accessible option. Don't overcomplicate it.

On Thu, Jun 26, 2025 at 5:06 PM Brooks Newton <brooksallennewton@gmail.com [mailto:brooksallennewton@gmail.com]> wrote:

Hi Mark,

I documented toasts and similar design patterns that automatically disappear as a WCAG violations almost seven years ago to the day.  

Alert Dialog Example: Is disappearing toaster alert WCAG compliant? #756 [https://github.com/w3c/aria-practices/issues/756]
The more you know!

Brooks

On Thu, Jun 26, 2025 at 3:43 AM Mark Magennis <Mark.Magennis@skillsoft.com [mailto:Mark.Magennis@skillsoft.com]> wrote:

Adam Cooper said:  "It should be onscreen for as long as you believe it is necessary for everybody to consume its content and then disappear."
 
Adam, I would have thought that automatically disappearing toast notifications are a violation of 2.2.1 Timing Adjustable. Unless they disappear when they are no longer valid or one of the other mechanisms (turn off, adjust, extend) are implemented.

Interested to hear your view on this.

Mark
[1e16ac6f-d657-42b9-8c31-31d7641c5586]