Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revise the Introduction of the Snackbar Component #16391

Ryokuhi opened this issue Jul 2, 2019 · 5 comments


Copy link

commented Jul 2, 2019

On June 28th, 2019, during the weekly accessibility meeting on Slack (see, potential accessibility issues were pointed out regarding the introduction of the Snackbar component in Gutenberg 5.9. During the discussion about these issues, a much wider range of problem areas were highlighted and some members proposed to revise whether the Snackbar component should be kept inside the editor interface or if it should be removed.

Concerns about Snackbars apply both to their current use (at the moment, they're used to display a message after a post is saved/updated) and to their future use in other parts of the editor. Following is a list of potential issues concerning both accessibility and UI/UX that were pointed out during the meeting.

Accessibility issues

  • The Snackbar appears at the bottom left of the screen: this placement is out of view for users with limited vision field, users who use screen magnification, and users who zoom at high levels.

  • The Snackbar disappears after 10 seconds, violating the WCAG requirement related to time-based operation (see

  • Currently, the Snackbar is used only to show a message when a post is first published and when it's updated; while in the latter case the Snackbar is only a few tabs away from the update button, in the former case the Snackbar is very far in the DOM and, when using tabbing navigation, it's almost impossible to reach it before it disappears.

UI/UX issues

  • Snackbars are very efficient on mobile devices, where the entire screen is visible at once; on larger screens, Snackbars are very small and they can be missed.

  • According to the design guidelines for the Snackbar component (see,

    A Snackbar displays a succinct message that is cleared out after a small delay. It can also offer the user options, like viewing a published post but these options should also be available elsewhere in the UI.

    In case no option is added, since the message disappears after 10 seconds, the user might unintentionally overlook it.
    In case an option is added, it should (but it doesn't have to) be available elsewhere in the UI; if the option is already included in the UI, potentially there is no need to add it a second time.

  • The current position of the snackbar "violates" the principle of proximity of controls. Both the Publish and the Update button are in the top right part of the screen, but after the post is published/updated, the snackbar appears in the bottom left part of the screen. The current Notice on top of the page is closer to the button and, as such, is more perceivable by users.

  • Snackbars (according to design guidelines) should be used

    to communicate low priority, non-interruptive messages to the user.


    To create a prominent message that requires a higher-level of attention, use a Notice.

    On the one hand, creating a hierarchy of notifications might be useful. On the other, there are potential drawbacks:

    • without guidelines to determine if a message has high or low priority, the choice to use either a Notice or a Snackbar would be left to the single developer and this might confuse end users;
    • in case of low priority notifications that may be ignored by the user, deciding not to add a notification at all might also be an option and, in this case, the Snackbar would be useless;
    • even if distinguishing between high and low priority notifications might be useful, having a Notice and a Snackbar components so different from one another might add to the problem instead of solving it.


During the accessibility meeting, it was decided that the first issue to be addressed is whether the Snackbar component is valuable and, as such, should be kept in future versions of the Gutenberg plugin and finally merged into the core. After reaching consensus about keeping the component in the editor, another GitHub issue will focus on how to improve accessibility for the Snackbar component.


This comment has been minimized.

Copy link

commented Jul 3, 2019

In order to keep the discussion here focussed, let’s start by evaluating the use case for the Snackbar component. The identified accessibility and UX issues are ones we can fix. Before we address the specifics, let’s focus on the key question:

Does WordPress need a hierarchy of notifications?

WordPress, by virtue of its extensibility, can often overwhelm users with notifications:

The WordPress admin dashboard, with different notifications in different places covering the UI.

Establishing a hierarchy of notifications can help reduce this mental fatigue and allow users to approach their work in a more focussed way.

From Inclusive Components’ Notifications article:

Over-sharing may be considered a nuisance, but under-sharing might make the user feel they are missing critical information.

By introducing a lower-priority form of notification, we’re able to have more control over how notifications are sent in WordPress. A multiplying array of notifications that require user interaction can quickly veer into over-sharing territory, but avoiding sending notifications when processes are complete can mean that users lack certainty about those processes.

The article distinguishes between low-priority (“just FYI messages”) messages, and high-priority (“messages asking users to take action”) messages, and recommends that lower-priority messages disappear on their own.

WordPress notifications (the current Notice component) traditionally require user interaction to be dismissed. This makes sense for high-priority messages that require the user to take action, but is inappropriate for those that are simply notifying the user of a successful process (“Your upload is complete.”), or are just meant as a quick heads up (“You’ve changed your theme, but you can undo this if you need to.”).

The goal of snackbar notifications is to offer a less-obtrusive alternative for those sorts of low priority messages.


To illustrate the difference here, let’s first take a look at a great example of a traditional WordPress notification: the one that lets you know a plugin update is available. In this case, the user needs to take action, and the notification remains present until that action is completed. Once they manually upgrade their plugin, the notification will be dismissed.

A yellow plugin update notification showing "There is a new version of Atomic Blocks available. View details or update now."

On the other hand, the “Post updated” notification doesn’t necessarily require the user to take any action. Even so, it’s usually been displayed in a similar manner to the example above:

A green notification banner, reading "Post updated. View post." at the top of a post.

This notification is informing the user of a successful action. The message remains on the screen until the user specifically takes action to dismiss it, or triggers a new action to replace it. In this case, the message is inherently temporary though: Yes, the post was updated, but if the user continues making edits on the page, the notification becomes obsolete. Over time, the notification remains on the screen, but it becomes less useful and less accurate.

A black notification banner reading "Post updated. View post." at the bottom left of a post.

In the latest versions of Gutenberg, this message has been transitioned into a snackbar notification. The snackbar appears briefly to alert the user to the success of their button press, provides them with an optional next step, and dismisses itself automatically. This is a more appropriate treatment for this particular message: it is less intrusive, temporary, and doesn’t require the user to take any action.

Benefits of establishing a notification hierarchy

Establishing a hierarchy to Wordpress notifications allows us to do the following:

  • Help users focus on tasks.
  • Help users distinguish between actionable (higher priority) and non-actionable (lower priority) messages.
  • Aid some users who struggle with notification fatigue.
  • Provide positive, but non-interruptive feedback about successful processes.
  • Solve problems identified in #1309, #11807, #12127, #15132, as well as solve a specific accessibility problem identified during the accessibility walkthrough of the navigation menu block.
  • Provide user settings to have more fine-grained and customisable control over notifications.
  • Avoid problems where the notifications push down content.
  • Clear guidelines will help developers and third-party plugin authors make better decisions and have better control over notifications.

Let’s continue to iterate

The current iteration of snackbars may not be the ideal one, and Gutenberg may not be using them correctly all the time just yet. Placement, timing, usage, and visual treatment are all aspects that can definitely be iterated on.

For instance, we could introduce a user setting to control the timeout or even hide them altogether for users who find notifications distracting. Or we redefine the rules such that a lower-priority notification cannot have an associated link or control, thereby forcing developers to only use these for non-actionable system messages.

From a design perspective, these notifications are a first step toward establishing a hierarchy of notifications in the system, which serves a very real problem.


This comment has been minimized.

Copy link

commented Jul 11, 2019

@sarahmonster I believe you nailed the design feedback. I'm removing the label. 👍


This comment has been minimized.

Copy link

commented Jul 11, 2019

A hierarchy of notifications appears valid. To help further this discussion we should define which notifications are high-priority and which or low-priority. We can do so in this issue, and move the a11y concerns to another issue entirely for more focused actions.

I'll attempt to classify some notifications below to help move the discussion forward. This is not an exhaustive list, nor is it set in stone. I'm open to alternative suggestions.

High-priority Notifications

  • When a post/page is published.
  • Post/page scheduled.
  • All errors.

Low-priority Notifications (snackbars)

  • When a post/page is updated.
  • Post/page reverted to draft.
  • All content copied.

I doubt I covered them all. @youknowriad, do you know where I might find a list of all these notifications that are being used in snackbars?


This comment has been minimized.

Copy link

commented Jul 12, 2019

When a post/page is published.
Post/page scheduled.

I'd argue that these two notifications are not high-priority notifications especially with the revamp of the publish flow being considered (modal)


This comment has been minimized.

Copy link

commented Jul 12, 2019

I doubt I covered them all. @youknowriad, do you know where I might find a list of all these notifications that are being used in snackbars?

Try searching for type: 'snackbar' in the code. That's how I find them 🤷‍♂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
6 participants
You can’t perform that action at this time.