Toasts are small, rectangular notifications that pop up on the screen, triggered by user or system behavior. They usually appear at the bottom left or right of the viewport and disappear after a predetermined time.
While it may be tempting to use Toast UI as a solution to your task, know that there are many accessibility and usability issues inherent in this pattern. Due to this, GitHub recommends using other more established, effective, and accessible methods of communicating with users,
Primer offers a variety of solutions to notify users about updates. Consider:
- What type of result do you want to achieve, and
- How would the UI best enable a user to do this?
Are you trying to highlight successful or unsuccessful form submissions? Provide feedback that an action was successfully performed? Alert someone that a long-running task has finished?
Considering your use case can help select a UI treatment that not only best serves our users, but also strengthens the internal consistency of the experience within the overall GitHub platform.
Simple operations completed successfully
User and system initiated actions that are direct and simple must be completed successfully. An example of this is creating an issue, and then showing that issue in the repo issues list.
Communicating success does not require a secondary form of reinforcement, as this should be self-evident – including a toast to communicate this success may, ironically, reduce the feeling of trust.
successfully completed complex tasks
Actions initiated by the user and the system may require more complex interactions, requiring additional feedback mechanisms to help inform the user that their request was successfully implemented. An example of this is the wholesale creation of issues.
Complex interactions may benefit from a secondary form of feedback to communicate success. The way this secondary response is expressed depends on the design, but there are two general approaches:
- Using banners to provide a summary of what was performed.
- Progressively expose content created as part of a multi-step or progressive disclosure process.
Note that both approaches retain feedback information and do not automatically discard it.
unsuccessful simple and complex verbs
Banners and dialogs can provide feedback to the user and system errors that result from an action. Banners are useful when error information needs to be provided passively, while dialogs are useful for intentionally interrupting the user to get his or her attention.
Successfully filled forms
Simple forms may not require any confirmation status other than creating and displaying what the user requested.
More complex forms may use an interstitial confirmation page or banner that informs the user about what is being done with the data they submitted.
Other Form Verification
Primer already has a robust set of components and guidance to handle input validation. Using these offerings helps GitHub feel consistent across the entire surface area of the site.
long running tasks
Actions that take a long time to complete should use banners to notify the user of task completion or failure. Also consider ways to notify the user in other communication channels such as email, notifications, or push notifications in the GitHub app.
application status
The client’s session is likely to become desynchronized, especially if a browser tab is 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.
Toast UI risks violating the following web content accessibility guidelines (WCAG) success criteria (scheduled casteEach of these SCs has one of three levels of support, and represents friction or a difficult barrier for our users. GitHub respects the first two levels: A and AA.
primary idea
These are the aspects of the Toast UI that potentially represent major hurdles for our users:
2.2.1: Time adjustable
A mechanism must exist to extend the presence of the Toast UI indefinitely until manually dismissed by the user. It is guaranteed that the toast duration is a length that enables all users to navigate, read, and potentially take action on the toast UI content.
1.3.2: Meaningful sequence
The toast message code is usually placed at the beginning or end of the DOM. Many forms of assistive technology work by reading the DOM sequentially, so there will be a disconnect between the Toast UI and what triggered the Toast UI. This hinders discovery and understanding.
2.1.1: keyboard
The Toasts UI began as a mechanism for displaying passive notifications, but evolved to include interactive controls.
All interactive controls placed inside the Toast UI need to be operated via the keyboard, as well as access to the Toast UI container. It includes a mechanism for managing focus when the toast is dismissed as well as removed from the DOM.
4.1.3: Status messages
The Toast UI should make its presence known to assistive technology in a way that is not disruptive to the user’s regular workflow or working context.
secondary consideration
These are other possible success criteria that use of the Toast UI may violate depending on its context:
1.4.4: Change text size
Increasing text size at the browser or operating system level poses three potential risks to the Toast UI.
First, make the toast so large that it obscures the rest of the page content. The second is to create horizontal overflow in an effort to prevent the underlying page content from being obscured. The third is trying to block the text size on the toast component to prevent both of the previous risks.
1.4.10: Reflow
If horizontal overflow is created as a result of using the Toast UI, it should be able to scroll through keyboard interactions.
2.4.3: Focus sequence
A toast that contains interactive elements needs those elements to be able to receive keyboard focus. Additionally, due to the position of the toast in the DOM the order of focus does not make sense compared to the interactive content that comes before or after it.
3.2.4: Persistent Identification
The underlying code for toast notifications should be the same regardless of where they are used or which team the service belongs to.
In addition to accessibility issues, there are also usability issues to consider with toasts:
large display
Many developers work on larger displays, so they have more screen real estate to work with. Toasts can be placed in such a way that they remain unnoticed, as they remain out of the user’s immediate visual field.
Distracting and multitasking
If a user is distracted or actively switching between tabs and applications, toasts that automatically dismiss themselves run the risk of going unread.
blocking the ui
Since toasts “float” above the rest of the UI, there is a possibility that they may obscure the underlying content.
This obscuring effect is especially worth considering since important UI such as form submission buttons are also placed at the bottom corner of the viewport. The effect is even more pronounced if several toasts are stacked on top of each other.
screen magnification
Some users rely on software or hardware-based magnification solutions to be able to use the computer. Toast notifications cannot be seen by the user, as they are displayed outside the bounds of the magnification window.
working memory
Toasts that display important information and automatically dismiss themselves can create a situation where the user is given important information, but then has no way to go back and review the information.
banner blindness
Toast is a highly 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.
disconnection
The location of the toast may be far away from the UI that triggered it. This violation of the Gestalt principle of proximity means that it is more likely that the user does not understand the connection between the toast message and its associated content.
sudden dismissal
users are exerting pressure ESC If multiple keyboard-dismissable pieces of content exist, dismissing the toast may accidentally dismiss another piece of the UI. The opposite also applies, where the user may dismiss a toast containing important information while attempting to dismiss an unrelated piece of the UI.
<a href