How to handle Toast notifications with interactive content

[bozdoz]

I want to create a non-modal toast notification that may have actionable content, such as a link or a button. If it does have actionable content, I assume the component should gain focus immediately (like an alertdialog), and I assume in order to help keyboard users engage with this content I should restrict the navigation to the toast (act as if it were a modal).

First: is this expected behaviour? Are there references to alternative behaviour? What I could find was information like the Alert Dialog example. Also, I found a decent implementation with lots of accessibility information on Carbon Design System

Second: how would this work if there were more than one actionable toast? Would all toasts be focusable while they're visible, or would focus move to the next toast once each is actioned or dismissed?

Thanks! :)

[JAWS-test]

That is a difficult question. The first consideration would be: do I really need toats that contain controls? Maybe I can implement it differently. The second question would be whether there is a 100% probability or a very high probability that the controls in the toast will be operated after the toast is displayed. If so, I can make a modal dialogue out of it.

However, if the controls in the toast are optional and the probability of use is low, focussing on the toast would be disruptive and could interrupt the workflow. In this case, it might make more sense if the focus remains on the triggering element and an access key is offered to navigate to the toast. Imagine that after deleting an element, a toast is displayed with the message "Element has been deleted" and the button "Undo deletion". You will rarely need this button. If the button automatically gets the focus, I may have to use the keyboard to get back into the application to delete the next element, for example.

If the toast receives the focus automatically when it is opened, it should be easy to close the toast (e.g. with ESC) and after closing, the focus should be reset correctly (and not just be at the top of the page)

[bozdoz]

Is there any official reference to an access key? Something that may be intuitive, or should that perhaps be read aloud to a screenreader as some custom keyboard command?

[chaals]

Access keys are tricky - browser implementation is somewhere between not very good and terrible: It's hard to discover what keys are offered, and there's no standard de-conflict mechanism so sometimes normal functions get taken over and sometimes they don't :(

Note that while they could be useful to screen reader users, they are far more relevant to keyboard-based users who are mostly sighted.

[bruce-usab]

A viewport with interactive content is a not a "Toast notification". The QuickRef models tag is of some help, but I agree with @JAWS-test that keyboard accessibility and focus are the key challenge for an interactive pop-up.

[mbgower]

I want to create a non-modal toast notification that may have actionable content, such as a link or a button. If it does have actionable content, I assume the component should gain focus immediately (like an alertdialog), and I assume in order to help keyboard users engage with this content I should restrict the navigation to the toast (act as if it were a modal).

I think I'd challenge that notion, that you want it to gain focus immediately. This is a situation where a user's ability to set that preference would go a long way to 'solving' this interaction. A user who says 'yes, bring to focus' gets focus on the toast notices. A user who says 'not, do not bring them into focus, but play a sound', gets that, etc. At IBM, we had this very set up with our SameTime application (a chat client).

If you decide you want everyone to have this take focus, then it suggests you also want them to take action on it. Maybe you are going to face a modal interaction in that situation, but I think that becomes a whole design discussion. A toast notification, by definition tends to be something that pops up alongside a user's main interaction. Many did not persist, further reinforcing that they were not the primary task. See @JAWS-test's points on this.

There are a bunch of other considerations for this. I've seen design systems where there are MANY levels of notifications, even within what might be considered the same interaction pattern, and the relative importance of those weighs on the design.

Finally I also think there are a lot of considerations around dismissal. If you look at some of the discussion in Focus Not Obscured, you'll note that there are questions about the difference between something launched by a user, and system generated messages. Those are just two cases. If a user leaves a overlay without acting on it, can we infer they want to dismiss it? What if we dismiss and provide a list of the those notifications elsewhere? My point is, there are a lot of different considerations for the most elegant way of handling those notifications that do not warrant a modal dialog.