RE: A question about immediate feedback

Steve,

 

Your interpretations of my last paragraph appear to be deliberately disingenuous to me … 

1. It depends how you interpret ‘without’ in this success criterion. Your interpretation is that the announcement of a status message must not be facilitated by moving focus whereas I interpret ‘without’ more broadly as a prohibition on moving focus entirely. And, if you read the accompanying documentation, it is the disruption caused by moving focus – even if it is to dismiss something – given the relative unimportance of the information specified in a status message that is the intention of this success criterion in my view. A modal dialog, for example, stops a process because the information is important and requires user interaction. A status message – by WCAG definition – is not this.
2. What is the definition of a dialog without referring to how one might be implemented or presented? And, yes, correct: it can be text or images with a text alternative or even the removal of text, but what Mike Cleary described in his original email was a toast which implies popup – I have been using popup throughout my email trail to avoid this confusion altogether). And, when you think of the various ways status messages can be implemented, it makes even less sense for SC4.1.3 to want focus to be moved to them … 
3. That is a paraphrasing from the benefits section of the ‘understanding success criterion 4.1.3’ documentation so if it offends your sensibilities I respectfully suggest you take it up with W3

 

Sincerely, I think That is it for this thread as I really don’t believe there’s more that can come out of it … you keep ticking off clunky server-side rendered dialogs with buttons all over them under the guise of SC2.2.1 and I’ll do my own thing thanks.

 

Cheers,

Adam 

 

 

 

 

 

 

From: Steve Green <steve.green@testpartners.co.uk> 
Sent: Friday, June 27, 2025 3:57 PM
To: Adam Cooper <cooperad@bigpond.com>; 'Juliette McShane Alexandria' <mcshanejuliette@gmail.com>; 'Michael Livesey' <mike.j.livesey@gmail.com>; 'Brooks Newton' <brooksallennewton@gmail.com>
Cc: 'Mark Magennis' <mark.magennis@skillsoft.com>; w3c-wai-ig@w3.org
Subject: RE: A question about immediate feedback

 

Your last paragraph is incorrect in almost every respect.

 

1. SC 4.1.3 does not prohibit status messages (of which toasts are a subset) from containing focusable components. It says that the information in them must be conveyed programmatically without them receiving focus.
2. A status message can be a dialog, but it does not have to be.
3. Status messages are not “intended to benefit screen reader users and users of other applications that include screen reader functionality.” Status messages are for everyone. It’s the associated live region that is intended to benefit screen reader users and users of other applications that include screen reader functionality.

 

I agree that “the unfortunate reality is that toasts are commonplace and unlikely to be ignored by designers and developers”. The unfortunate reality for designers and developers is that we will report WCAG non-conformances against them if they are not implemented correctly. Providing sufficient time for people who do not use a user agent that supports live regions is part of that. SC 2.2.1 does allow status messages to be removed automatically, but only after 20 hours.

 

Steve

 

From: Adam Cooper <cooperad@bigpond.com <mailto:cooperad@bigpond.com> > 
Sent: 27 June 2025 04:27
To: 'Juliette McShane Alexandria' <mcshanejuliette@gmail.com <mailto:mcshanejuliette@gmail.com> >; 'Michael Livesey' <mike.j.livesey@gmail.com <mailto:mike.j.livesey@gmail.com> >; 'Brooks Newton' <brooksallennewton@gmail.com <mailto:brooksallennewton@gmail.com> >
Cc: 'Mark Magennis' <mark.magennis@skillsoft.com <mailto:mark.magennis@skillsoft.com> >; w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> 
Subject: RE: A question about immediate feedback

 

Appreciate the comprehensive response, Juliet, and the sentiment that every detail contributes to an improved user experience, but the unfortunate reality is that toasts are commonplace  and unlikely to be ignored by designers and developers regardless. 

 

I agree with Scott’s assessment that there should be no negative impact if a toast is missed, but, interestingly – rather than defining a toast by its function as WCAG does – it’s about positioning etc.

 

I don’t agree with Eric’s description that toasts “may or may not contain interactive content”

 

And I don’t agree with Adrian’s assessment that toasts contain ‘essential information’ 

 

And I don’t think that these three posts are in sync about the nature and purpose of toasts nor whether they necessarily violate SC2.2.1 as you assert.

 

Read the WCAG definition of a status message. It can’t be focusable/interactive otherwise it fails 4.1.3. It doesn’t matter whether it is modeless or modal accordingly. It doesn’t comprise generally ‘essential’ or ‘important’ information – only specified information. It makes no reference to presentation, position, or persistence. It is not a dialog. It is intended to benefit screen reader users and users of other applications that include screen reader functionality. 

 

 

 

 

 

 

 

From: Juliette McShane Alexandria <mcshanejuliette@gmail.com <mailto:mcshanejuliette@gmail.com> > 
Sent: Friday, June 27, 2025 5:39 AM
To: Michael Livesey <mike.j.livesey@gmail.com <mailto:mike.j.livesey@gmail.com> >; Brooks Newton <brooksallennewton@gmail.com <mailto:brooksallennewton@gmail.com> >
Cc: Mark Magennis <mark.magennis@skillsoft.com <mailto:mark.magennis@skillsoft.com> >; w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> 
Subject: 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 <mailto: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

  <https://tracking.getmailbird.com/OpenTrackingPixel/?messageId=Mailbird-18fd9f58-ce88-442a-bee3-965051678c32@gmail.com&senderHash=2DB0E4908157CA5D6C96F6C2D4B878796FB4B77AD6F800A29FA96C2443A5CE7E&recipientHash=8CE2878435A94840519674171B0BA1DF87BC45254CDBDF5F842E692D8A284FAD&internalId=43e8ba83-38ae-4306-9de2-b33e19392e87>