Toasts

GitHub no longer uses toasts because of their accessibility and usability issues.

Overview

Toasts are small, rectangular notifications that pop up on the screen, triggered either by a user or system behavior. They commonly show up on the bottom left or right-hand side of the viewport and disappear after a preset amount of time.

While it can be tempting to use toast UI as a solution for your task, know that there are many accessibility and usability issues inherent with this pattern. Because of this, GitHub recommends using other more established, effective, and accessible ways of communicating with users.

What to use instead of toasts

Primer offers a variety of solutions for informing users about updates. Consider:

What kind of outcome you want to achieve, and
How the UI will best enable a user to do that.

Are you attempting to highlight a successful or unsuccessful form submission? Give feedback that an action was successfully undertaken? Alert someone that a long-running task has finished?

Thinking through your use case can help select a UI treatment that not only best serves our users, but also reinforces the internal consistency of experience within the overall GitHub platform.

Successfully-completed simple actions

User and system initiated actions that are direct and straightforward should be successfully completed as a matter of course. An example of this is creating an Issue, and then seeing the Issue show up on the list of Repo Issues.

There does not need to be a secondary form of reinforcement to communicate success, as it should be self-evident—including a toast to communicate this success may ironically lessen a sense of trust.

Successfully-completed complex actions

User and system-initiated actions that require more complicated interaction may need additional feedback mechanisms to help inform the user that their request was successfully enacted. An example of this is the bulk creation of Issues.

Complex interactions may benefit from a secondary form of feedback to communicate success. The manner in which this secondary feedback is expressed depends on the design, but two common approaches are:

Using banners to provide a summary of what was performed.
Progressively showing content as it is formed as part of a multi-step or progressive disclosure process.

Note that both approaches persist feedback information and do not auto-dismiss it.

Unsuccessful simple and complex actions

Banners and dialogs can provide feedback about user and system error as a result of an undertaken action. Banners are useful when the error information needs to be passively available, while dialogs are useful for deliberately interrupting the user to get their attention.

Successfully-completed forms

Simple forms may not need any other confirmation state other than creating and displaying what the user requested.

More complicated forms can utilize an interstitial confirmation page or banner that informs the user about what is being done with the data they submitted.

Other form validation

Primer already has a robust set of components and guidance for handling input validation. Using these offerings helps GitHub to feel consistent across the entire surface area of the site.

Long-running tasks

Actions that take a long time to complete should utilize banners to inform the user of task completion or failure. Also consider ways to notify the user in other communication channels such as email, notifications, or a push notification in the GitHub app.

Application state

There is the potential for a client’s session to become desynchronized, especially if a browser tab has been left open for a long time on a part of GitHub where a lot of dynamic updates are present. Dialogs and banners can be used to inform the user that a refresh is needed to resynchronize the client and server.

Accessibility considerations

Toast UI risks violating the following Web Content Accessibility Guideline (WCAG) Success Criteria (SC). Each of these SCs represent friction or a hard barrier for our users, as well as map to one or more MAS C considerations.

Primary considerations

These are aspects of toast UI that potentially represent large barriers for our users:

2.2.1: Timing Adjustable

Understanding SC 2.2.1: Timing Adjustable (Level A)

A mechanism needs to be present to extend the toast UI’s presence indefinitely until manually dismissed by the user. This is a guarantee that the toast’s duration is a length that allows all users to be able to navigate to, read, and potentially take action on the toast UI content.

1.3.2: Meaningful Sequence

Understanding 1.3.2: Meaningful Sequence

Toast message code is commonly placed at the start or the end of the DOM. Many forms of assistive technology work by reading the DOM in sequence, so there will be a disconnect between what triggers the toast UI and the toast UI itself. This impedes discovery and understanding.

2.1.1: Keyboard

Understanding 2.1.1: Keyboard

Toasts UI started as a mechanism to display passive notifications, but evolved to include interactive controls.

All interactive controls placed inside a toast UI need to be operable via keyboard, as well as accessing the toast UI container itself. This includes a mechanism for dismissing the toast, as well as managing focus when it is removed from the DOM.

4.1.3: Status Messages

Understanding 4.1.3: Status Messages

Toast UIs should make their presence known to assistive technology in a way that is not disruptive to a user’s regular workflow or working context.

Secondary considerations

These are other potential success criteria that using toast UI may violate depending on its context:

1.4.4: Resize text

Understanding 1.4.4: Resize text

Increasing the text size on the browser or operating system level runs into three potential risks for toast UI.

First is making the toast so large that it obscures the rest of the page content. Second is creating horizontal overflow in an attempt to prevent obscuring the underlying page content. Third is attempting to block text resizing on a toast component to prevent both of the previous risks.

1.4.10: Reflow

Understanding 1.4.10: Reflow

If horizontal overflow is created as a result of using toast UI, it needs to be able to be scrollable via keyboard interaction.

2.4.3: Focus Order

Understanding 2.4.3: Focus Order

A toast that contains interactive elements needs those elements to be able to receive keyboard focus. Additionally, the toast’s position in the DOM may make the order of focus not make sense compared to the interactive content that comes before or after it.

3.2.4: Consistent Identification

Understanding 3.2.4: Consistent Identification

The underlying code for toast notifications should be the same, regardless of where they are used or what team owns the service.

Usability considerations

In addition to accessibility issues, there are also usability issues to consider for toasts:

Large displays

Many developers work on a larger display, in order to have more screen real estate to work with. Toasts could be placed in such a way that they go unnoticed, in that they sit outside of a user’s immediate field of view.

Distractions and multitasking

Toasts that automatically dismiss themselves risk being unread if a user is distracted or is actively switching between tabs and applications.

Blocking UI

Since toasts “float” above the rest of the UI, there is a chance that they can obscure underlying content.

This obscuring effect is especially worth considering given that important UI such as form submission buttons tend to also be placed at the bottom corner of the viewport. The effect also becomes more pronounced if multiple toasts stack on top of each other.

Screen magnification

Some users rely on a software or hardware-based magnification solution in order to be able to use a computer. Toast notifications may not be seen by the user, in that they are displayed outside of the range of the magnification window.

Working memory

Toasts that both display important information and automatically dismiss themselves may create a situation where a user is given important information, but then has no way to go back and review the information.

Toasts are an over-used interaction pattern on the web. This leads to a phenomenon where users are taught to ignore and avoid their content, as it is often low-quality or unrelated to their immediate task at hand.

Disconnection

A toast’s placement may be far away from the UI that triggered it. This violation of the gestalt principle of proximity means there is more of a chance a user does not understand the relationship between the toast message and its related piece of content.

Accidental dismissal

Users pressing Esc to dismiss a toast may accidentally dismiss another piece of UI, if multiple keyboard-dismissable pieces of content are present. The opposite also applies, where a user may dismiss a toast containing important information while trying to dismiss an unrelated piece of UI.