[ToastNotification]: add guidance and styles for rendering action buttons

[vpicone]

Summary

Add action buttons to the ToastNotification component.

The ghost button makes alignment here awkward. Would need design spec/guidance before development.

Justification

Right now, only InlineNotifications are spec'd for Action buttons.

However, there are some circumstances where a ToastNotification might prompt the user for some confirmation/action:

Another example might be a cookie preferences notification.

Inline notifications are designed to "show up in task flows". For application-wide events or notifications where we don't want to totally interrupt the user experience (as with a Modal), a ToastNotification with action would be very helpful.

Desired UX and success metrics

• Add styles/design spec for action buttons in a ToastNotification
• Considering WCAG 2.2 toast notifications with an action should not expire after a time limit. They should only be dismissed after the user manually closes or otherwise interacts with the notification.

Specific timeline issues / requests

Need this feature for carbon-design-system/gatsby-theme-carbon#655

Available extra resources

I can build it!

[jeanservaas]

@vpicone here's the spec. I'm also making an issue on the systems board because the three of us decided to add the info icon to all information notifications... that will allow us to use the ghost button in both the toast and the inline notifications.

ps, those info icon "i" 's should be black in the dark theme, not white

[rgblee]

Could you please have at least two action buttons? Reach out to me at andrew.lee1@ibm.com if you want to discuss why or which services are in need of this.

[jeanservaas]

Just talked to @aagonzales about this... we will need to put something on the board for design to create guidance around this for February / March planning and add it to the kit.

• It will act like the Mac OS system update notification and NOT be time sensitive; we cannot have actions on something that disappears... so we need to make that clear.

[vpicone]

@jeanservaas totally, mentioned the accessibility implications in the initial post. From a design perspective, guidelines could just be "Don't automatically disappear if there's an action."

@aledavila This could be developed and enforced today. If they give us an action, we'd just ignore the default timeout as well as any timeout passed all while warning the developer using custom prop validation.

[joshblack]

We'll hold development on the system side until what @jeanservaas pointed out gets settled. I don't think we can build this into toast since the behaviors are incompatible (timeout versus persist until dismiss). From our guidance:

Usage
Short, time-based messages that slide in and out of a page and provide nondisruptive information

Duration and interaction
Disappear automatically or can be dismissed by user

Would this fall under a "banner" notification per https://www.carbondesignsystem.com/patterns/notification-pattern#notification-types ?

[joshua-vaughn]

I don't see any reason why these behaviors are incompatible. If a toast message automatically dismisses, it will likely be saved to a Notifications page or panel where a history of all notifications appears. The messages and actions can be accessed from this page at a later time, so it's no big deal if a user doesn't see it or act on it when it appears as a toast message.

[joshblack]

@joshua-vaughn we might be speaking from different perspectives/contexts, I think the dominant concern with timed notifications would be this criteria that we have to meet: https://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-no-exceptions.html

With text, we could communicate it using live regions that actively or passively inform the user. With content that is interactive, we would need to provide a way for keyboard and screen reader users to navigate to the notification. This interaction pattern seems distinct from the current usage guidance of toast, although it could be changed if we feel like it falls under this category.

One thing to note, while it may be likely that consumers will store notifications in a dedicated location, it's not a guarantee that all groups do this (or have the capability to do this) and we may have to build things defensively as a result.

[vpicone]

@joshblack just learned that the gatsby service worker now automatically fetched updates on route change: https://twitter.com/gatsbyjs/status/1229589052329881601?s=21

This might not be a blocker if we can just use a service worker silently (this is what gatsby www does.)

[jeanservaas]

@rgblee I'm not sure Carbon is quite ready to add this to core without some more research. I will tag this issue as a proposal and you can go ahead make your business case here in the issue, along with some UI images illustrating the context.

Then after some discussion the team can decide how to proceed...obviously there's a lot of interest in a site-wide status notification with actions. Thanks!

[aagonzales]

Related:
We'll need a two button solution as well.
https://ibm-studios.slack.com/archives/C0M053VPT/p1582734506056900?thread_ts=1582566672.011600&cid=C0M053VPT

This will need a visual pass. I don't think we want to do fluid buttons in this scenario because they could stack.

[vpicone]

@joshblack @aagonzales Gatsby isn't as smart about refreshing as I would have hoped this is still technically a blocker for adding service workers to the theme site.

[tay1orjones]

ActionableNotification was delivered in #8703

The site has also been updated to show new guidance through updates contained under carbon-design-system/carbon-website#2402