Reconsider design of alerts

[mcarrano]

Stacking two status colors on top of each other creates a difficult accessibility issue when ensuring the items meet the required contrast ratios.

cc @mceledonia

[mceledonia]

@mcarrano
Here's my current proposal, I'll list some notes below

Light

Dark? Very similar to carbon, not a bad thing.

Grouped

• New color scheme uses side bar, state text (success/failure), and icon as ways to introduce color
• Maybe don't need state text, but it does improve accessibility though not required since the icons meet contrast.
• Scalable design shows how you can mix and match certain elements, potentially have an expansion action
• Took a page from Material Design to show potentially stackable/grouped alerts
• I think we should go with our plain text button style and not worry about introducing full buttons here, I think both the proximity, position, and text of the items themselves do plenty in terms of communicating importance to the user.
• Potentially have timestamp top right, maybe bottom like carbon?
• Grouped notifications work similarly to Material Design, grouping by status and time helps to keep things neat and tidy. I tried grouping different status but it got pretty complex fairly quickly. Let me know if you want to see that.
• Content is mainly placeholder. In the grouped notifications I just show a count, but it could be more descriptive. The grouped actions expand/dismiss also could be anything relevant to the group of notifications.
• Overall sort of combining Material + Carbon approach with a focus on communicating status.

[mcarrano]

@mceledonia I like the new visual direction. Just a couple of things to keep in mind...

• I'm not sure a timestamp on a toast alert is useful. These are immediate, transient events so they don't live very long on the screen in most cases. Maybe use that area for a simple "X" to dismiss the alert.

• I like the idea of placing actions below. It will solve our responsive problem, I think. Not sure if we should ever have more than one action associated with an alert. We had a long discussion about accessibility of actions in toast alerts and it gets pretty complex. @jessiehuff it might be good for you to take a look at this.

• The grouping idea is pretty interesting. This gets beyond styling though, and we'd need to figure out how to functionally group alerts like this. That would be a new feature to be considered.

• This is getting pretty close to the look of what we call an inline alert. Take a look here: https://www.patternfly.org/v4/documentation/react/components/alert#inline-variations I don't think that's a bad thing. But if we go that way then perhaps we need to unify the two.

[mceledonia]

Thanks for the feedback Matt, it all sounds good! I'll try to reply per-bullet:

• I agree about the timestamp. It would also be one less element we have to juggle. Perhaps the timestamp can be a POC for how these might look in a notification drawer where they're more persistent.
• +1 on getting an a11y review here
• Agreed, I think it's worth considering at least as I've heard a need from the OpenShift team around grouping like alerts.
• Definitely agreed on the alignment here. I realized about halfway through that I was just remaking the inline alert styling, so we should definitely align or take another look at inline alerts. I think this style works well as toast alerts but we've seen issues with inline not feeling like they have enough presence, so it might be worth looping back around with Mary on her latest work on inline and see if we can sync the two.

[mcarrano]

Renamed this issue based on discussion between @mceledonia and @kybaker we want to reconsider both toasts and inline alerts together.

[mceledonia]

Final designs shown here in marvel.

@mcarrano @mcoker

[mcarrano]

Thanks for posting these @mceledonia . In comparing against the current variants here: https://www.patternfly.org/v4/documentation/react/components/alert we seem to have lost the close (X) button. Can that be added to the upper right? Wondering if we should ever have multiple actions on an Alert. We do not now.

@mcoker do you have everything you need here? Any more specifics on color? Assume they map to current colors used. @jessiehuff can you also take a look from an accessibility perspective?

[jessiehuff]

I really like the new styling, it looks great so far! :) A few points to consider accessibility wise:

• When running the colors through an a11y contrast checker, I noticed some potential things to look at with the icons, particularly with the warning orange and the blues. Checking with Jenn to see how we've handled this with PF, but technically icons should have a ratio of 3:1 between the inner symbol and the background: https://www.w3.org/WAI/WCAG21/Techniques/general/G207.html
• In terms of the actions, I think it's worth considering how the user gets to the actions by keyboard. Typically when a toast alert is triggered, keyboard focus does not shift to the alert, they need to navigate through the DOM by keyboard or move their pointer to the toast alert. I think moving the actions to the bottom is totally fine as long as the user has plenty of time to get to it or it's not an urgent action.
• When it comes to screen readers, I'd just say to make sure that the actions are understandable by assistive technology. Maybe put the action labels in the context of a statement for the screen reader/explain how the user can take these actions. It would be great if it's incorporated into the message in a way that users would know how to access that link/action, especially if that dynamic alert is set to disappear.
  For example:

  • Ideally avoid:

    The build is complete. Download

  • Do This Instead:
    using <button class="pf-c-button pf-m-link pf-m-inline>Download</button>

    The build is complete. Go to the Builds page to download.

  • Or Do This:
    using <a href="url">Builds</a>

    The build is complete. Go to the Builds page to download.

[mcarrano]

Thanks for the comments @jessiehuff . I recall that we previously discussed all of the issues with actions in toast alerts and what you describe here sounds consistent with what we put in written guidelines.

[jessiehuff]

No problem at all! :) Just checked with Jenn on the icon colors. These were her thoughts:

If icons are redundant, then I don’t think the color contrast rules apply to them. But if icons are the only way that we provide meaning on a page, then they should meet color contrast.

In this section: https://webaim.org/articles/contrast/#sc141, they explain how color can’t be used as the only way to communicate information. So we can’t use color alone to indicate the type of alert to people. And therefore we have an icon to also communicate that information. This means that the icon for some users, i.e. color-blind users, is the only means of communicating alert type. And if the icon is the only method to communicate type, then we should make sure the icon meets color contrast requirements.

[mcoker]

@mcarrano @mceledonia looks good to me! The specifics on color and spacing would be great as a reference.

[mcarrano]

Thanks for all your work on this @mceledonia . I have posted your designs to patternfly/patternfly#2659 and will mark this as complete.

[mcarrano]

Thanks for all your work on this @mceledonia . I have posted your designs to patternfly/patternfly#2659 and will mark this as complete.

[gdoyle1]

This has been merged into the library! Will create a follow up issue to update template file. Closing this issue