Re: A question about immediate feedback

I would advise that everyone reads the text of 2.2.1. Toast messages that
purely advise of some other discoverable action or information (by any
other means) are excluded from 2.2.1.

*"A web application such as an email client provides notification of new
email arriving with a temporary message (such as a 'toast' message) in the
lower right-hand side of the interface, and the message disappears after 5
seconds. *
*Users are able to identify the arrival of email through other means, such
as viewing the Inbox, so the disappearance of the message does not set a
time limit on the their ability to determine if new mail has arrived."*
A message about a download places no time limit on actually viewing or
accessing the download. The user has usually clicked a button - saying
"download" or "save", so they are aware the download is expected, and there
is no time limit on the user examining the download folder on their
computer to look for the file. Therefore, there is no restriction on the
action to which the notification relates and 2.2.1 does not apply.

2.2.1 only applies if there is no other means of discovering the same
information or performing the action. This is why it is usual for error
messages to persist but success messages to disappear. I would argue it is
better UX for for error messages to persist regardless of accessibility.

An alternative solution is to display the toast ephemerally but also have
that same information in a notification centre e.g. a bell icon in the
header. What 2.2.1 is concerned with is not making the action time-limited
by some means, it does not demand that everything that is displayed have no
time limit.

On Thu, Jun 26, 2025 at 8:39 PM Juliette McShane Alexandria <
mcshanejuliette@gmail.com> wrote:

> 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>
> 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> 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
>>>
>> [image: e21a2e4d-1c5a-48bd-8db7-517c1bbaa1a7]