Suggested improvement to Understanding 2.2.1: Timing Adjustable

[awkawk]

https://www.w3.org/WAI/WCAG21/Understanding/timing-adjustable.html

The issue that I'm getting asked about is for toast messages, or snackbar messages like what we refer to in the Understanding 4.1.3 Status Messages document.

The core question is "Do toast messages need to do something different in order to not result in a failure of 2.2.1?"

I would say that as long as a toast message is not the only way that a user can be aware of something happening (e.g., an email arriving) or that they have successfully accomplished something (e.g., image uploaded to personal folder in online directory) then the criticality of the message being viewed as a toast is less. Those toast messages would need to support 4.1.3 Status Messages, but that is a separate issue.

Leaving the toast in view until the user dismisses each one is not desirable as in some cases you might have dozens or more individual messages and if they need individual attention then it is making the UI harder to use for everyone.

In 4.1.3 there is a reference to Material Design's snackbar (https://material.io/components/snackbars) which are designed for low-priority messages:
After a user puts a photo in an album in an online photo app, a snackbar displays the message "Saved in 'Wedding' album", which is also read by a screen reader.

I propose that for Understanding 2.2.1 we incorporate the following text into the Intent section right before the notes regarding server time limits:
Not all content that operates on a timer requires that the timing is adjustable. For example, a web application such as an email client provides notification of new email arriving in toast messages in the lower right-hand side of the interface, and the toast messages disappear after 5 seconds. The users are able to verify the arrival of email through other means, such as viewing the Inbox, so the disappearance of the toast message does not set a time limit on the end user's ability to verify if new mail has arrived. If the messages conveyed via toast could not be verified separately, then the message would need to meet this Success Criterion in order to provide the user with sufficient time to access the information.

[bruce-usab]

Thanks for writing this up. I totally agree that not requiring these sort of status messages to be manually dismissed by the end-user is important.

FWIW, this issue came up for us when we endeavored to add an explicit "copy link to clipboard" feature for many of our docs on our new website. Many hours of conversation! Pinging @kengdoj in case she wants to add some of the details we worked through.

[mraccess77]

Also refer to: #976 This has come up a number of places. The ideal solution would be to provide user control over these - messages can't stay up indefinitely as you likely get more and more messages and you'd run out of room to display them! However, offering options to the user to adjust timing, or not show them, or play a sound, or access a list of notifications like the Windows Notification Center would be ideal. There are also different types of messages - some may require user action and be interactive - perhaps there is a distinction for messages that actually require interaction such as something that is time sensitive.

Another aspect is that there can be some subtle changes that users may miss and having a toast disappear before you can read it but yet you don't know what happened on the page does pose a real issue for some users. I saw a toast - I don't know what it said - it's gone but I don't know what. I'd then think we'd want to require that the user can go and read the list of notifications and then timing is not involved - or give the user sufficient time to find and a chance to pin the toast.

[robinmetral]

Thank you for sharing these thoughts and use cases!

I think we're mixing things up too much when we talk of a "toast" or "notification". Can we agree on these (rough) definitions? (Otherwise let's come up with better ones together, to make sure we're talking about the same things!)

• Notifications: any communication that an application wants to show to its users. These could be sub-categorized into:
  • Notifications requiring user action (e.g. "complete your profile")
  • Notifications not requiring user action (e.g. "profile updated")
• Toasts: floating UI elements, typically disappearing after a timeout, which can appear both as a result of a user action or not, and containing a notification
  • Because they disappear, it seems like they need to meet 2.2.1 Timing Adjustable
• Status Messages: "changes in content that are not given focus", in order to avoid interrupting screen readers
  • Effectively notifications not requiring user action

If we agree to this, it seems to follow that:

• Notifications that require user action should not be on toasts, because they need focus by definition
• Therefore toasts should only be used for notifications not requiring user action, i.e. status messages
• The "Notification Center" story only makes sense for notifications requiring user action—users don't need to see a list of unactionable status messages

So in the end, the remaining problem seems to be the one you're laying out, @mraccess77:

I saw a toast - I don't know what it said - it's gone but I don't know what.

We could go one of two ways from here:

1. add an exception for status messages on toasts to 2.2.1 Timing Adjustable
   • assumes that users will end up thinking of toast notifications as the non-critical, "FYI"-style notifications that they should be: "I saw a toast —I don't know what it said— it's gone, but it doesn't matter"
2. toasts that disappear too fast can confuse users, they do fall under 2.2.1 Timing Adjustable
   • since it doesn't make sense to make the timing of "profile updated" adjustable, maybe the real recommendation here would be not to use the toast pattern at all, and instead rely on other ways of visually displaying status messages (without timings)

I'd love to head your thoughts here and keep the discussion going!

[mraccess77]

I don't think we can mandate whether toasts have interactive content or not. Provide some status message of a notification and a mechanism to open the notification after it has closed could be ways to meet the criteria in my opinion. I agree we need to come to consensus on what is required and also what is best practice.

[bruce-usab]

@mraccess77 if a UI element has interactive content then it's not a toast -- which kind of begs the question if we need to be clearer about what UI patterns we are considering as not being covered by 2.2.1? @mraccess77 are you okay with the last paragraph @awkawk proposes in OP? (That paragraph starts with the sentence: Not all content that operates on a timer requires that the timing is adjustable.)

If we want to get more prescriptive, we might start by trying to list out characteristics of which sort of status messages are permissible to self-disappear.

[mraccess77]

This page seems to indicate that snackbars and toasts can have an action https://material.io/archive/guidelines/components/snackbars-toasts.html#

[mraccess77]

I'd think messages that are allowed to disappear are ones that can be accessed again AND the user is alerted to or ones that have a setting to be kept up at user request. If you had non-decorative content that disappeared and you couldn't access it again I think it would fail.

[bruce-usab]

I am remembering that not too long ago, perhaps in the context of carousels, we went round-and-around (!) that not everything which had a time aspect is covered by 2.2.1. Captioning might have been discussed in that context too. My recollection is that there was consensus that these examples were not of a time limit that is set by the content.

This page seems to indicate that snackbars and toasts can have an action

I find that for Snackbars but not toasts. I am not confident that toasts is sufficiently universal in meaning, but I don't have a problem with including mention of them (as @awkawk proposed in OP).

A not-uncommon pattern nowadays is provide an explicit copy link to clipboard feature. Yes, this functionality is redundant to choices from the right-mouse contextual menu. It is not uncommon for this sort of feature to have some subtle status message associated with them. I am not aware of any implementation of this feature which can be accessed again or where behavior changes per end-user setting preference. @mraccess77 - are you asserting that these all fail against 2.2.1? I am presently of the opinion that what you describe is a best practice, but not not something required by any 2.x SC.

[bruce-usab]

I found #1658 but unfortunately, the resolution there is not quite on point enough for toasts.

[mraccess77]

2.2.2 is odd that it only requires pause when media is presented in parallel with other content and starts automatically - so in theory you could have a pre-recorded video with no pause if it's the only thing presented - but in practical reality I find this unlikely to occur. Often I do see videos that move without audio - but they tend to start automatically and are in parallel with other content.

If toasts have content that the user doesn't have time to read and they can't be accessed another way and the information is informative and doesn't fall under some other exception such as real time exceptions then I think I would fail it somewhere under SC 2.2.1 or 2.2.2 as it's a user issue and appears to be covered by the requirements.

The understanding document says "Any process that happens without user initiation after a set time or on a periodic basis is a time limit. This includes partial or full updates of content (for example, page refresh), changes to content, or the expiration of a window of opportunity for a user to react to a request for input.

It also includes content that is advancing or updating at a rate beyond the user's ability to read and/or understand it. In other words, animated, moving or scrolling content introduces a time limit on a users ability to read content."

If the group feels like there is wording that indicates these are allowed or fall outside the scope and we make that clear I'm happy to discuss.

[robinmetral]

Just a few follow-up thoughts here:

This page seems to indicate that snackbars and toasts can have an action
https://material.io/archive/guidelines/components/snackbars-toasts.html#

IMHO we need to stop drawing on Material as an example: several of its patterns (e.g. the text inputs and the toasts) have major accessibility issues by design.

This is what I was trying to do with defining terms—if we're going to talk about accessible toasts, I think we need to think of them as not having actions, period. A toast with an action is either inaccessible, or it's a dialog.

I'd think messages that are allowed to disappear are ones that can be accessed again AND the user is alerted to or ones that have a setting to be kept up at user request. If you had non-decorative content that disappeared and you couldn't access it again I think it would fail.

I wonder if the key here is the "non-decorative content". In our case (and in the one @bruce-usab is describing) the toasts are basically redundant, for example:

• the user submits a form, the UI updates, a toast says "Successfully submitted"
• the user clicks "copy to clipboard", a toast says "Copied to clipboard"
• the user logs out, on the login page a toast says "You were logged out"

These scenarios would all be usable without the toast, and would pass an AA audit (correct me if I'm wrong).

In this case, aren't these toasts basically decorative? Why would we suddenly fail 2.2.1 when introducing this progressive enhancement? (as in: it's fine is users miss the toast completely, but it's still good UX for those who don't)

Anyways, practically speaking, I have never seen a toasts implementation that would pass 2.2.1 by the current wording of the SC. We're working on one right now, and it seems to me that we're actually meeting the intent of 2.2.1. We're not asking users to do anything under time pressure: our toasts are meant to add an extra layer to success/error states that should actually enhance usability for most users (including using assistive technology), and I can't think of cases when it would degrade it¹. So I'm kind of at a loss on what to do next here: either we can somehow pinpoint this exception and reflect it in the SC understanding guide, or I guess toasts are meant to just fail WCAG AA

Footnotes

1. arguably we have the case (mentioned previously) of a user seeing the toast but not having enough time to read it. I don't know if this is actually a UX issue or just an assumption, it would be great to see research on this. My own assumption is that users have learned that they can ignore toasts by now—since they're practically used as decorative elements ↩

[patrickhlauke]

In this case, aren't these toasts basically decorative? Why would we suddenly fail 2.2.1 when introducing this progressive enhancement? (as in: it's fine is users miss the toast completely, but it's still good UX for those who don't)

just on this, to be clear: they may not fail 2.2.1, but they will fail 4.1.3 if not announced by AT

[patrickhlauke]

i also wouldn't outright say notification-style toasts are just decorative, because they are used in circumstances where they provide confirmation that something happened, an action was carried out, or that an error occurred.

[bruce-usab]

I am taking the liberty to invite @kengdoj to comment, but yes, that was our reasoning: the toasts add no information.

Our more technical challenge was not having the toasts disrupt focus or keyboard order, and that were not too distracting per SC 2.2.2.

[mraccess77]

If something is not "information" then I would pose the question - just remove them. The response would then be - they are needed to give feedback to the user. Which likely means they are information.

[robinmetral]

i also wouldn't outright say notification-style toasts are just decorative, because they are used in circumstances where they provide confirmation that something happened, an action was carried out, or that an error occurred.

That's correct, some toasts do, but not all, which is why I'm trying to make a distinction here.

What if we saw toasts as a part of user feedback, but not feedback in itself? So for example, if there's a form submission error, you could have inline errors on each relevant field and a toast. Kind of like how since the use of red alone is not a sufficient indicator or error, you have red and an icon. So toasts in isolation are inaccessible (failing 2.2.1), but paired with other ways of finding the information they provide, they're progressive enhancements.

Does this make any sense? Or are you saying that there's no space for this distinction, because we can't recommend that toasts shouldn't be a necessary part of a user flow?

If something is not "information" then I would pose the question - just remove them. The response would then be - they are needed to give feedback to the user. Which likely means they are information.

In theory I completely agree with this, but toasts do enhance the experience for a large amount of users (while not being "needed"). It's similar IMO as whether one should remove illustrative images: they do contribute to the experience in a way, though not for everyone.

[patrickhlauke]

What if we saw toasts as a part of user feedback, but not feedback in itself?

maybe i'm misunderstanding the point here, but this sounds a lot to me like trying to narrow the definition in an attempt to then be able to exempt things. "no, toasts don't violate this SC...if they're 'toasts' in the sense that we narrowly defined, visual fluff that doesn't actually serve a purpose"

but i think fundamentally the problem is that terms like "toast" just mean different things to different people. if the terms are "loaded" already with varying misconceptions/definitions, perhaps it's best to avoid using them altogether and to be very specific about "dynamic notifications" or similar, drawing distinctions there, rather than attempting to redefine/authoritatively define what we mean when we say that "toasts are exempt" or something. otherwise, we risk still giving a broad-strokes advice that gets misinterpreted because devs see the "toasts are exempt" part without bothering to check the nuanced (re)definition of what WCAG means when it talks about "toasts"

[bruce-usab]

@patrickhlauke (et al.) – I very much agree that we need to be clear on what we mean by toast. Moreover, something we all agree is a toast might still be barrier. Regardless, I will keep using the word for now.

Building on @robinmetral example, if the user submits a form, the UI updates, and a toast says "ticket # 1234 successfully submitted" – when that ticket number is not available elsewhere – we all agree that is not acceptable. This behavior is not accessible, and fails versus 2.1 SC 4.1.3. But for 2.x, I am not of the opinion that the behavior fails against SC 2.2.1, I do not consider text from a toast to be a time limit that is set by the content as described by SC 2.2.1. Under the 2.0 rubric I would be inclined to fail the behavior against SC 1.3.1, but that is not unambiguous either.

@mraccess77 wrote:

If something is not "information" then I would pose the question - just remove them.

This is an analysis approach which I very much agree with! For our link-copied-to-clipboard toast, the response would then be: Our audience is not as sophisticated as you might think. That is why we asked for a visible copy-link-to-clipboard feature, even though a savvy user would known it is redundant, since one could just right-click.

[mraccess77]

If it fails 4.1.3 then we are saying it needs to be accessible to screen reader users but not accessible to low vision users and not to users with cognitive disabilities. It seems like we are choosing accessibility for one group over another. Sometimes ARIA also allows support for users with cognitive disabilities - but not in this case.

[mraccess77]

If a toast is additional to something already available in another way then it would already be allowed under WCAG's conformance requirements which allow for alternatives. Today we allow for a data table to represent an image of a chart without making the chart itself accessible.

[robinmetral]

Thanks for the feedback esp. @patrickhlauke, you're raising very good points.

FWIW I wasn't trying to get toasts exempt, I was trying to understand why an accessible behaviour (this narrower definition of toasts, as discussed) would still fail 2.2.1.

I get it though, adding nuance around toasts to the understanding guide might actually result in developers thinking that toasts are generally okay, and to inaccessible implementations—which would be exactly the opposite of what we're striving towards.

The only thing I'm still confused about is the fact that this is roughly saying "if you want to be AA compliant, you can't use toasts" (unless timing is adjustable for them, which, let's face it, won't happen a lot). And yes, this does make sense in most cases, so fair enough—it just seems like a bizarre message because that's such a common pattern in web apps. Maybe we do need this <toast> after all, where timing could be adjusted in browser settings... (joking, let's not go there 😅)

Cheers!

[alastc]

Just marking this as ready for survey, the original post included a proposal:

I propose that for Understanding 2.2.1 we incorporate the following text into the Intent section right before the notes regarding server time limits:
"Not all content that operates on a timer requires that the timing is adjustable. For example, a web application such as an email client provides notification of new email arriving in toast messages in the lower right-hand side of the interface, and the toast messages disappear after 5 seconds. The users are able to verify the arrival of email through other means, such as viewing the Inbox, so the disappearance of the toast message does not set a time limit on the end user's ability to verify if new mail has arrived. If the messages conveyed via toast could not be verified separately, then the message would need to meet this Success Criterion in order to provide the user with sufficient time to access the information."

From reading the other comments above, I think there needs to be some redundency to pass 2.2.1. I.e. if there wasn't a toast and it was usable, then it could pass. So the toast is a nice-to-have, not the only way to get that information.