2.2.1 Timing Adjustable and notifications/toasts/etc

[patrickhlauke]

A question that often bubbles up is: does https://www.w3.org/WAI/WCAG21/Understanding/timing-adjustable.html also cover, conceptually, things such as notifications/toasts that appear and then disappear after a certain amount of time. While 4.1.3 Status Messages now at least ensures that, for AT users, the notification/toast should get announced explicitly (without moving focus), does a disappearing toast represent a timeout? A hard reading of the SC suggests that yes, it's a timeout.

If so, is the logical conclusion that any website/application that uses any form of notification/toast actually violating 2.2.1 if it doesn't provide an option to make toasts static/permanent (or a way to extend the timeout before the toasts disappear) [and yes, unless the toasts are set to disappear on their own after 20 hours ;) ]. Because if that's the case, I'm surprised that toasts are even used at all, since so many sites use them ... and I'm not seeing a big push to change them. Nor am i seeing any large sites that offer users customisation options to make notification messages permanent/set their preferred length of time for them to remain visible before disappearing.

[JAWS-test]

The Understanding says:

People with disabilities such as blindness, low vision, dexterity impairments, and cognitive limitations may require more time to read content ...

For me it is quite clear that 2.2.1 applies to messages that are automatically hidden and I always rate this as a problem. Often the messages are only displayed for a few seconds, which can be a problem even for unimpaired users...

This applies regardless of whether the messages are marked as Live Region.

[detlevhfischer]

I think it will depend on whether the toast message has information that users will be expected to act upon. If a user activates a "Save" button and the toast message says: "Your changes have been saved", this is what users expect to happen anyway, so I would not think that they must be able to make the appearance of such a message permanent. Another line of approach would be to determine if users will have alternative ways of verifying the change that the toast message communicates. As so often, there will be a grey area where it's a judgment call to decide whether or not the toast msg is basically redundant.

[patrickhlauke]

As so often, there will be a grey area where it's a judgment call to decide whether or not the toast msg is basically redundant.

yup, this. also, most sites/apps that use toasts would essentially, today, be in violation here otherwise...and i don't think that's the case / is being noted in audits. it would in essence outlaw toasts that didn't offer an option/setting to be permanently visible until active dismissal.

[JAWS-test]

I think it will depend on whether the toast message has information that users will be expected to act upon.

I don't agree with that. If I see a message but don't have enough time to read it, it will confuse me, even if it doesn't contain any important information or only the expected information. I'll think, "Maybe I missed something important..."

Another line of approach would be to determine if users will have alternative ways of verifying the change that the toast message communicates.

If these alternative ways add extra effort, that would be an accessibility problem as well

[sasgrw]

Thank you, @JAWS-test, I was going to say the same thing regarding missing a message. One does not need to have a cognitive or dexterity issue for this to be a problem. If you perform some action and the toast message appears but you're distracted by some other notification in another app, and then in your peripheral vision you see the toast message disappear, you might think, "Crap, what did I miss? Was it important?".

Technically, a toast message should be information that doesn't really matter and can be ignored, but if everyone followed best practices and used the appropriate elements all the time, we wouldn't have so many accessibility problems. There are way too many toast messages out there that contain important information and some even (gasp) have interactive elements.

I agree with @patrickhlauke's OP that toast messages are indeed a 2.2.1 issue and with @detlevhfischer's comments that toasts are usually redundant information (if used correctly).

It seems that the only way to have an accessible toast message is to either

1. allow the user to adjust how long a toast message can display, or
2. give the user a warning before the toast disappears and allow the user to extend the time

#2 would be kind of weird for a toast message but technically it satisfies 2.2.1. I didn't include allowing the user to turn off the timing (the first recommendation in the SC) as an option for an accessible toast message because that would essentially make the toast message not a toast message anymore. By definition (although I suppose it depends on whose definition you use), a toast message is supposed to display for a period of time and automatically disappear. If it doesn't automatically disappear, it's not really a toast message anymore. So if you allow the timing to be turned off, you'd have an accessible message, not an accessible toast message. (Yes, that's a bit pedantic).