Is it sufficient if short toast messages are displayed only 20 seconds

[JAWS-test]

My reading of SC 2.2.1 is that time limits must be 10x extendable. However, there is the option: "The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action".

I.e. here also a short message is displayed and then the user must press a key and has only 20 seconds for both (reading and operation). If I think this logically to the end, would it then also be sufficient for other, short messages to be displayed only 20 seconds? Or am I wrong there.

[bruce-usab]

Such a great question!

The 20 second metric from 2.2.1 is sufficient timing for a simple physical action. It assumes zero reading time and background understanding/experience of the end-user that some web pages close automatically. For someone who moves slowly and has never before encountered a "press any key" style prompt, 20 seconds would not be expected to be enough time.

SC 2.2.1 is very much applicable to temporary informational messages that displays on a web page. Toasts, by their nature, incorporate a "time limit that is set by the content". If a site owner thinks the Toast message can typically be read in two seconds, is there an option for the end-user to make that message last twenty seconds? If you add a pause button, then the UI component is no longer a Toast!

Toast are animations. So please also be sure to address SC 2.2.2 Pause Stop Hide with your implementation.

[patrickhlauke]

Toast are animations.

not sure I agree. They may also simply appear/disappear (as in yes, the "classic" toast, that gave these temporary notifications their name, pops up from the bottom of the screen like a toast from the toaster, but they may simply appear/disappear in a corner without animating as such, so I'd be careful with that characterisation of them being animations)

[bruce-usab]

I agree I could have been more careful with the characterization of "animation" since the key adjective (for this discussion) from 2.2.1 is "moving". Content which appears/disappears might be a distraction of the sort meant to be addressed by 2.2.1, by the SC text misses it.

[JAWS-test]

Toast are animations

In my opinion, toasts are not animations according to SC 2.2.2, even if they are animated, because they do not fulfill 2 out of 3 conditions:

• starts automatically - usually they are displayed after user interaction (save, delete, etc.)
• lasts more than five seconds - the animation when fading in and out never lasts 5 seconds

Toasts are sometimes animations according to SC 2.3.3 (AAA) - if they are animated

[bruce-usab]

I am not sure we are agreeing on what is an animation (or not), let alone the exact canonical behavior for a toast.

If I think this logically to the end, would it then also be sufficient for other, short messages to be displayed only 20 seconds?  Or am I wrong there.

You are wrong to think you have found a twenty second safe harbor loophole in 2.2.1 when Guideline 2.2 Enough Time literally reads: Provide users enough time to read and use content.

That generally requires letting end-users read at their own pace.

A paragraph of informative text that disappears after twenty seconds is a barrier to many people with disabilities. It is a failure of 2.2.1.

[JAWS-test]

The 20 second metric from 2.2.1 is sufficient timing for a simple physical action. It assumes zero reading time and background understanding/experience of the end-user that some web pages close automatically. For someone who moves slowly and has never before encountered a "press any key" style prompt, 20 seconds would not be expected to be enough time

I do not understand your comments. If I am new on a website and - without knowing it before - I am automatically logged out after 30 min., but 20 seconds before I get a hint, I have to

• read the hint first
• and then react: press a key.

Maybe I have a phone call, am distracted or use a screen magnifier and the timeout notice is not displayed in the visible area. What then?

By the way, my initial question is not about considering toasts that are only displayed for 20 seconds to be accessible. On the contrary, I want to understand why the 20 seconds exception exists in 2.2.1.

However, if 20 seconds is considered sufficient to read a message in 2.2.1, then this time should apply to all messages of the same length. Otherwise it would be unfair...

[bruce-usab]

20 seconds is not considered sufficient to read a message in 2.2.1.

The time is strictly meant for the physical action.

If I am new on a website and - without knowing it before - I am automatically logged out after 30 min., but 20 seconds before I get a hint...

I agree that the scenario you describe is problematic. For many people, including some people with disabilities, 20 seconds to cognitively process an unexpected and surprising behavior is not enough time.

[bruce-usab]

My own organization deliberately kept our use of toasts under 5 seconds so that they were exempt under 2.2.2.

I would argue that toasts do "start automatically". It is not similar to how the end-user activates a play button. I guess it depends what triggers the toast? If I hit submit I might expect a confirmation screen. A Thanks! message rising from the bottom of the screen is exactly the sort of distracting moving content that 2.2.2 purposefully sets limitations upon.

[JAWS-test]

My own organization deliberately kept our use of toasts under 5 seconds so that they were exempt under 2.2.2.

I suspect that we have quite different ideas here:

• I would consider it a violation if the toast fade in is animated (e.g. slowly moved from the right margin to the center) and the animation lasts longer than 5 seconds.
• you see it as a violation at 2.2.2, that e.g. after saving the form a toast message is first shown and after more than 5 seconds automatically hidden again (both without animation). The fade in is definitely not a violation of 2.2.2, because it happens after user interaction. The hiding can be considered as a violation. But not as a violation against "moving, blinking, scrolling", but at most against "auto-updating". But I wonder if hiding information once is "auto-updating".

That a one-time (non-animated) fade-out is considered "auto-updating" I doubt, based on the mention of update frequency (a frequency can only occur when something happens multiple times) and the sentence in the understanding:

there is no five second exception for auto-updating since it makes little sense to auto-update for a few seconds and then stop

[bruce-usab]

One main purpose 2.2.2 is put limits on page behavior that is distracting. A short message sliding up and down from the bottom of the page is meant to cause a change of focus, and it exactly the sort of moving animation which 2.2.2 means to target.

[JAWS-test]

I don't find any reference in the Understanding for 2.2.2 that showing a toast after a user action and hiding the message after a certain time - each without animation, as described by me - is understood as "moving". In my opinion, "moving" actually means a movement. "moving" would actually be the fade-in and fade-out itself, if this is animated. However, this usually takes only a few milliseconds and thus fulfills the 5 seconds exception. To regard the animated fade-in and fade-out as a total animation, which may then last longer than 5 seconds, I think is a daring interpretation.

[bruce-usab]

I understand you to be describing a message that uses some sort of visual effect to arrive on the screen. You are trying to get the users attention with this visual effect. If would disingenuous to try and count each piece of the animation separately. 5 second fade-in (pass). A static text message for five seconds (pass). 5 second fade-out (pass). No, sorry! That is a single animation, taking 15 seconds, and subject to SC 2.2.2.

[JAWS-test]

20 seconds is not considered sufficient to read a message in 2.2.1.

If the 20 seconds is only for pressing the key, then in 2.2.1 the information is missing, how many seconds before the information must be displayed, that a key is to be pressed.

[bruce-usab]

The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action

The 20 seconds is only for the simple action. I agree that information about how detailed the instructions is missing, but it is clearly on the order of "Press any key to continue." An informative message that goes away is clearly a time limit that is set by the content so that's 2.2.1.

[JAWS-test]

@bruce-usab: But even a simple message, with a request to press a key, I have to read - and to read I need time. And this time, which I need for reading, I then lack for pressing the button. Therefore I understand 2.2.1 in such a way that I have only 20 seconds to read, to make a decision (whether I want to continue working) and to press a key. That is really short. And if it is considered sufficient, then 20 seconds should also be sufficient to read a toast message that says, for example, "The item has been deleted".

[bruce-usab]

Again, you implicating something into one bullet (one part, a subset) of 2.2.1 which simply is not there. The Extend bullet 20 seconds is about the simple action, nothing else, nothing more.

That said, yes 20 seconds to read a short confirmation toast message is plenty!

Your recent example is not what I was imagining from OP. The user did the action to delete the item. No conformation message is required at all! 0 seconds is enough! This sort of toast message is completely superfluous. It would be better, of course, to ensure that the toast message is available -- at their option -- to people using AT. But there is so little information being conveyed (the button did the thing it was supposed to do) that it is essentially noise. AFAIK, any technique to ensure AT users get the toast will be counterproductive. I think you are fine.

That said, having gone through considered discussion for my own agency's website (for a toast to confirm that a link was copied to the clipboard), we kept the toast message to 5 seconds -- so as to not impinge on 2.2.2.

[awkawk]

If the toast messages are available to be seen at the user’s pace, such as in a “notification center”, then it doesn’t really matter how long the toast is shown. I can’t think of an example where 2.2.1 really comes into play for toast.