Best practice for notification timeouts

Question

The app I'm currently working on has a notification banner that appears when successful or unsuccessful network calls. It says things like "Your address was updated successfully!" or "An error occurred while creating your contact".

These banners are set to disappear after a certain amount of time. I recently attended a web accessibility course recently and they mentioned how we shouldn't assume that everyone reads at the same speed/level and it made me realize that this disappearing content could be problematic.

After some research, I see in many articles the suggestion to implement a setting that allows users to disable the timeout. I don't like this approach for several reasons, but mainly because the user probably doesn't know this option exists and may never end up clicking on the settings page.

Does anyone have a method for handling these notifications that they think will work for all users?

Answer 1

What you're describing is known as a toast.

Here's when to use them and when should you avoid them, taken from the above link from Hewlett Packard's guidelines:

Toasts should be considered when displaying these types of information to the user:

• Low attention messages that do not require user action
• Singular status updates
• Confirmations
• Information that does not need to be followed up

Do not use Toasts if the information contains the following:

• High attention and crtitical information
• Time-sensitive information
• Requires user action or input
• Batch updates

As for your last question, you can simply let users get rid of the toast notification. See image below:

As you can see, you can dismiss and even have additional actions. Or, as in the link I provided above, give users the option to close them manually or make them disappear after a certain amount of time (in HPE's case it's 8 seconds, but this is easily modified using JS)

Answer 2

Summary: Either render the timeout of toasts configurable or remove it, and reconsider other means to inform about errors, like permanent banners or dialogs.

Sources

A great source for (web application) patterns and accessibility is the ARIA Authoring Practices Guide (APG).

It’s a guide created by the Web Accessibility Initiative (WAI) which is part of the W3C.

Take a look at the Alert Pattern on APG. It mentions:

An alert is an element that displays a brief, important message in a way that attracts the user's attention without interrupting the user's task.
[…]
It is also important to avoid designing alerts that disappear automatically […]

Also related are the Web Content Accessibility Guidelines (WCAG), which is the main standard on accessibility of web applications (and even applied to software in general in some states).

They mention in Level-A Success Criterion 2.2.1 Timing Adjustable that any content that changes after a timeout needs to fulfil other criteria.

Adjusting the timeout is one of them.

One of my favorite resources on accessible design systems is the GOV.UK Design System. Their team runs and publishes a lot of research and tests with users with disabilities.

Their the Gov.UX Notification banner does not disappear automatically either.

Remove a green notification banner when the user moves to a new page

Choice of feedback mechanisms

Most Design Systems have decision tables to choose the right kind of user-feedback depending on the message. The different kinds are more or less interruptive.

To make it short: If user intervention is needed, a disappearing toast is not the right feedback mechanism.

If we stay positive, a success message in a toast is ok, since it’s not interrupting the user. In case they missed it, they still probably have the result of their action on screen.

But errors are another subject and need to be looked at individually. If there was an error creating a user, isn’t it in the user’s interest to take action? Why would one dismiss such an error when trying to get a job done? And how helpful is it if the error message disappears?

From Material Design:

Snackbars communicate messages that are minimally interruptive and don’t require user action.

So in case of errors, the better way might be to use a dialog to inform the user and guide them to fixing it. Or, in material design a banner, which basically is like a toast on the top that does not disappear.