Lecturing about accessibility with latency so high that you have no idea if any clicks are actually meaningful. I click "banners" and there's no indication anything is happening until 3 seconds later, when it takes me to a page that doesn't directly talk about banners until later. Then there is a link there that says "banners", and takes me to a different page, 3 seconds later. No indication that anything is happening or waiting during that time.
that's just an <a href> link. the only latency is your browser pulling the (admittedly, unnecessarily large) page -- would you prefer some static hydration garbage?
It's not a real link - some JS magic is happening behind the scenes. Otherwise there would be a confirmation something is happening like the browser's usual spinner.
> that's just an <a href> link. the only latency is your browser pulling the (admittedly, unnecessarily large) page
I fail to see the relevance of your comment. So you came up with an explanation of why the page might have awful accessibility. How does this make the accessibility problem any better?
> would you prefer some static hydration garbage?
I think everyone would prefer to not wait 3 seconds to get feedback on what they clicked. We're talking about accessibility, right?
it's a link. if your browser doesn't have some visual cue that a load is occuring (for me it's a favicon indicator and a visual loading bar) you're having a client issue.
>How does this make the accessibility problem any better?
it's not a UX decision to load slowly on poor uplinks (fwiw it's near-instant on my machine). obviously nobody would /choose/ to do that.
toasts, though, are a definitely conscious UX choice.
The :active pseudoclass has been used to change the appearance of links since the beginning. (Probably in part because loading links was considerably slower back then.) Not giving links an :active style is a bizarre oversight.
I think it is likely that there is a slow/high latency part of the connection. This is usually represented to the user by showing a loading spinner or something like that. However, it is using some partial reloading in the background instead of just following a link, and as a result is not letting the browser tell me that it is loading, and it doesn't have any sign of loading presented otherwise.
GitHub primer is an interesting resource to read through, thanks. You don't have to agree with everything that is said to gain something from it and certainly beats winging it based on vibes.
For comparison, Apple and Android have their own documentation:
Toasts are like a tourniquet, for me. You slap them on a problem to stop the bleeding, and they're often preferable to the alternative, but nobody actually likes them and you really shouldn't keep them long-term or apply them frivolously.
E.g. you join a project with little to no error handling or success feedback. Slap some default toasts on everything! And then remove them page by page as you fix the horrible UI you inherited.
GitHub is large enough that they don't benefit from or want such a crutch, but not everyone is GitHub.
>Toasts pose significant accessibility concerns and are not recommended for use.
yeah. OBVIOUSLY. good fucking riddance.
they wouldn't be half as bad if they always came with a notification center for seeing the ones you missed... but the other half is still incredibly bad and isn't worth using at all.
Accessibility is more than just screen readers. Toasts are also not accessible for folks with low vision, low peripheral vision, etc. And the time-based disappearance is unpleasant for many people, as one of many examples of "accessibility improvements are also often usability improvements".
A message that you have to explicitly dismiss, and that's stored in a "message history" somewhere, is much more accessible and usable.
> Toasts are also not accessible for folks with low vision
To make this a little more concrete with one example: if you are using fullscreen magnification, odds are toasts will literally never appear on your monitor. By the time you pan over to their little corner of the screen (if you ever do), the toast will be long gone.
Can confirm. I zoom and pan on lots of websites in my daily browsing and would have no idea if toasts are popping in and out. I'll notice system level toasts though.
That depends on the size of the toast, appearance and frequency. We (an MSP) used a Windows toast notification[1] to encourage people initiate the Win10 > Win11 upgrade at their own convenient time (before it gets forced down on them) - and we got a pretty high uptake. The overall feedback from both the project team and users were good: the toast was unmissable, the text explanation was clear, and the big banner image was eye catching.
a "big banner image", buttons that are required to interact or dismiss, doesn't go away on its own after only a couple seconds, and might(?) also exist in the notification center
I think it's pretty safe to label that "definitely not a toast". That's just a notification, or maybe a "non-modal alert". Toasts are distinct from those by being brief and ephemeral.
It is technically a toast, according to Microsoft. If you check the link in my previous comment, the script is using the Windows Runtime Toast Notification API, specifically the Windows.UI.Notifications namespace and the ToastGeneric XML toast template.
This is sometimes intentional. Some design it that way to ensure that if they are going to do a certain action, that they have seen the toast. Obviously far from being the case all the time, but it happens that it is intentional sometimes.
Okay you are right, timer-adjustable disappearance and history is important too and if it's local to where user's fields of view it's better than a toast every time of the day.
Accessibility doesn't even need to be related to any disability or unusual user requirement. A user-hostile website can be inaccessible even to users with perfect visual and motor functions.
- quick, in response to a clicked button -> why not just show feedback on the button?
- quick, in response to a keyboard shortcut -> ok
- seconds or more after an action, say, if your import/export is done -> fine, but have a more persistent notifications inbox or send the user an email too, because if you dismiss the toast, how do you get back to that result?
- when you've just navigated to a page, as a way to present an alert or advisory about the new page -> if it's important enough, why not show it as a persistent alert on the page itself?
Far too many toasts are used for the last use case. Part of the reason for this, I think, is because if you detect something weird in a React callback, you'd need to wire up a whole new state variable to show it, vs. just calling a global toast() function at the time where you learn about the weird thing. But is it really much more work than toasting to roll something like const {alertElement, addAlert} = useAlerts()? And have it speak your design language?
Your 50-tabs-open multitasking users will appreciate you.
IMO a toast showing up shouldn't be a direct/immediate response to user action at all, ever. Toasts are purposely designed to steal attention. Don't try to steal attention from the user performing an action just to confirm that the action occurred; you already had their attention!
> if it's important enough, why not show it as a persistent alert on the page itself?
Because it's a crutch against bad design in an era when many companies don't employ designers, or arguably even as an exploit to be leveraged by marketing to try to brute-force the conversion of users to sales.
While there's nothing inherently wrong with them, I've become so accustomed to toasts being misused/abused that my instinctual response to that visual stimuli is that it's focus-friction and tantamount to being spammed, even when they're being used in benign or debateably useful ways.
I always just used it to confirm your last action on a POST —> GET sequence. Eg confirming that your save went through/rejected (the error itself embedded & persisted in the actual page). Or especially if saving doesn’t trigger a refresh so success would be otherwise silent (and thus indistinguishable from failing to click).
You could have the button do some fancy transformation into a save button but I prefer the core page being relatively static (and I really don’t like buttons having state).
It’s the only reasonable scenario for toasts that I can think of though.
> 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.
^ this is a great idea and please add it to github actions where it takes like 10 seconds for the new thing to show up on the list after you trigger one
I wonder if it is time to look into some more native support for toasts in browsers.
Some implementation that allows for browser level customization(timing, etc), as well as a notification center in the browser, and that integrates well with screen readers.
I like toasts from a visual perspective. They can look good(not always, of course), and they can convey small bits of information that could otherwise be displeasing to view in some designs. However, god have I missed a ton of notifications because of them disappearing too quick, and no way to view previous ones, or anything like that. I'm not visually impaired or anything, so I can't really comprehend the extent and issues people who do may have with toasts, and see what would be needed to make them accessible for them(if it's even possible), but would love to hear about it.
> once set up, very easy to build, no “design” required
Which is why they then get thrown around thoughtlessly. It becomes easy to pretend to have solved a problem using a toast instead of actually solving it.
Generally I have treated toasts as reassurance rather than important information
Like little 'saved' notifications when clicking through tabs, or email sent after clicking a send email button that might leave you on the same page
Web sites tend to over inform you of what's happening I like toasts (though I no longer use them since they're it of fashion) simply because you can disregard them
This is a terrible overview. The actual primary benefit of toasts is that they provide feedback on low-importance events without requiring the user to interact with them and without permanently taking up UI space. The web application I use most frequently would be infuriating if I had to deal with a modal window every time a toast would have been used, and UI space is at a premium for useful functionality, so occupying a permanent spot to relay those messages isn't a good solution either.
I wish software developers could drop this dogmatism. Same as the old Goto considered harmful trope outliving its usefulness and all that. It's always black and white - "people can misuse this tool, so this tool is inherently bad and should be eliminated from usage completely" - rather than acknowledging that many tools have great use cases even if they can also be abused.
Modals are different from toasts. Modals take over your screen; you go into a separate "mode" for them. Toasts are non-modal; they just take up screen space but you don't have to interact with them.
"Toast" usually implies something that goes away on its own, though that's generally considered bad UX.
It's just jargon. Every field does that. In this case, you can really tell that it's two bits of jargon made up at different times, because one is dry and technical, and the other is a pun on "pop-up".
Modals are, IMO, the literal worst UX element you can hate your users with. There are certainly valid use cases, but _absolutely not_ should be the default.
How come? I find them nice to allow for certain actions that don't really require navigation, and may want the user to easily return whenever they do anything in the modal or not. I understand it is historically bad due to accessibility, but there's more native support for it now. Assuming it is implemented with that in mind, is it still bad?
I personally don't find modals inherently all that bad, though they can definitely be implemented poorly. Does anyone have specific reading material on the problems with modals?
Thank god, toasts are so annoying. Every little action in Google Calendar has an associated toast/snackbar to go with it that tells you exactly what you just did and asks if you want to undo it. Like wtf? I can’t use my calendar app without these stupid toasts flying in and out and trying to draw my attention to read some irrelevant text. They go away too quickly for anyone not technically literate to click on them, and they are too slow to keep up when you’re creating a ton of events (they just fly in and out). I hope these go away, they add nothing to the application.
They say to replace them with Banners, which are just a different style of a "Toaster", just usually stay longer, or are permanent until the user takes an action.
No, it's different. A "toast" is a floating element, a "push notification" which is detached from the panel, e.g. can disappear quite quickly. The banner is placed closest to the context where the action is triggered, e.g. might require the user to close it. If you have some disability, e.g. cognitive, visual or motor, it's likely to be easier to perceive the information. When a user creates an "issue", the "issue item" is displayed in the list, meaning that you won't need a secondary notification process.
The main problem with toasts is that they disappear with no hope of recovery before you get a chance to read them, obscuring other content in the process. Banners don't obscure other content, don't disappear without user action, and could theoretically have a message history.
A strange take. Toasts don't work so GitHub (and by extension MS) should have gone through W3C to implement a browser-wide solution instead of replacing them with alternatives in their products?
From the GitHub doc:
> 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.
The alternative proposes:
> Doing something, even as simple as adding a Jira ticket to a backlog, is not something I want to assume happened. I need to know it happened.
I fail to understand how seeing the created item in context does not let me know beyond any reasonable doubt that it was indeed created. Showing an additional toast adds nothing but noise and only showing a toast even more so.
Honestly, the JIRA example points out one of the main cases where I'm not exactly sure how to replace a toast. You don't have to be on the board to create a ticket in JIRA—so it may not be obvious in context.
I understand there are accessibility issues, but if the thing I am attempting to create will not be visible on the current view, what's the best approach?
Honestly, the same could be set for a large list or Kanban board. Just because of the number of records it may not be evident that the intended action occurred.
I am lucky in that I haven't used Jira in many years, so here are some examples of how GitHub does it:
- create an issue: redirect to the created issue
- create an issue from a project view (kanban board): close the creation modal, stay on the view, and let the newly created issue show up in the list
- create a sub-issue from within an issue open in a side panel of project view: close the creation modal, stay on the parent issue and render the newly created sub-issue in the section called "sub-issues"
Within the awkward constraints where GitHub projects clash with the old UX of issues this is works very well and I know way beyond any reasonable doubt that the desired action has indeed been performed. Error states like failure to create an issue can be rendered in the modal and I can retry right in context too. I fail to see how toasts would add anything.
In a product based on different principles this might not be possible but then the GitHub doc is internal guidance and not a universal rule.
As an aside, GitHub's issue creation modal used in the project view is well executed.
The standard way in desktop GUIs is a status line or similar. In other words, a dedicated area that displays the results of the last action. It has the important property that it doesn’t disappear without user action, and also doesn’t get in the way of what the user may want to see or do.
Lecturing about accessibility with latency so high that you have no idea if any clicks are actually meaningful. I click "banners" and there's no indication anything is happening until 3 seconds later, when it takes me to a page that doesn't directly talk about banners until later. Then there is a link there that says "banners", and takes me to a different page, 3 seconds later. No indication that anything is happening or waiting during that time.
that's just an <a href> link. the only latency is your browser pulling the (admittedly, unnecessarily large) page -- would you prefer some static hydration garbage?
It's not a real link - some JS magic is happening behind the scenes. Otherwise there would be a confirmation something is happening like the browser's usual spinner.
> that's just an <a href> link. the only latency is your browser pulling the (admittedly, unnecessarily large) page
I fail to see the relevance of your comment. So you came up with an explanation of why the page might have awful accessibility. How does this make the accessibility problem any better?
> would you prefer some static hydration garbage?
I think everyone would prefer to not wait 3 seconds to get feedback on what they clicked. We're talking about accessibility, right?
it's a link. if your browser doesn't have some visual cue that a load is occuring (for me it's a favicon indicator and a visual loading bar) you're having a client issue.
>How does this make the accessibility problem any better?
it's not a UX decision to load slowly on poor uplinks (fwiw it's near-instant on my machine). obviously nobody would /choose/ to do that.
toasts, though, are a definitely conscious UX choice.
The :active pseudoclass has been used to change the appearance of links since the beginning. (Probably in part because loading links was considerably slower back then.) Not giving links an :active style is a bizarre oversight.
All of the links respond instantly for me, even on a slow 4G connection.
Is it possible that your browser or internet connection are slow?
I think it is likely that there is a slow/high latency part of the connection. This is usually represented to the user by showing a loading spinner or something like that. However, it is using some partial reloading in the background instead of just following a link, and as a result is not letting the browser tell me that it is loading, and it doesn't have any sign of loading presented otherwise.
It does not appear to be doing partial reloading, it's just serving a page.
Then very strange behavior. It does not show active loading.
GitHub primer is an interesting resource to read through, thanks. You don't have to agree with everything that is said to gain something from it and certainly beats winging it based on vibes.
For comparison, Apple and Android have their own documentation:
https://developer.apple.com/design/human-interface-guideline...
https://developer.android.com/design
Toasts are like a tourniquet, for me. You slap them on a problem to stop the bleeding, and they're often preferable to the alternative, but nobody actually likes them and you really shouldn't keep them long-term or apply them frivolously.
E.g. you join a project with little to no error handling or success feedback. Slap some default toasts on everything! And then remove them page by page as you fix the horrible UI you inherited.
GitHub is large enough that they don't benefit from or want such a crutch, but not everyone is GitHub.
Finally, I hope that trend catches on. God knows how many messages are missed thanks to toasts.
>Toasts pose significant accessibility concerns and are not recommended for use.
yeah. OBVIOUSLY. good fucking riddance.
they wouldn't be half as bad if they always came with a notification center for seeing the ones you missed... but the other half is still incredibly bad and isn't worth using at all.
>yeah. OBVIOUSLY. good fucking riddance.
Are they really? Isn't it pretty normal "role status aria something something polite" thingy to announce feedback to user?
Accessibility is more than just screen readers. Toasts are also not accessible for folks with low vision, low peripheral vision, etc. And the time-based disappearance is unpleasant for many people, as one of many examples of "accessibility improvements are also often usability improvements".
A message that you have to explicitly dismiss, and that's stored in a "message history" somewhere, is much more accessible and usable.
> Toasts are also not accessible for folks with low vision
To make this a little more concrete with one example: if you are using fullscreen magnification, odds are toasts will literally never appear on your monitor. By the time you pan over to their little corner of the screen (if you ever do), the toast will be long gone.
Can confirm. I zoom and pan on lots of websites in my daily browsing and would have no idea if toasts are popping in and out. I'll notice system level toasts though.
That depends on the size of the toast, appearance and frequency. We (an MSP) used a Windows toast notification[1] to encourage people initiate the Win10 > Win11 upgrade at their own convenient time (before it gets forced down on them) - and we got a pretty high uptake. The overall feedback from both the project team and users were good: the toast was unmissable, the text explanation was clear, and the big banner image was eye catching.
https://www.imab.dk/windows-10-toast-notification-script/
If it has all of:
a "big banner image", buttons that are required to interact or dismiss, doesn't go away on its own after only a couple seconds, and might(?) also exist in the notification center
I think it's pretty safe to label that "definitely not a toast". That's just a notification, or maybe a "non-modal alert". Toasts are distinct from those by being brief and ephemeral.
It is technically a toast, according to Microsoft. If you check the link in my previous comment, the script is using the Windows Runtime Toast Notification API, specifically the Windows.UI.Notifications namespace and the ToastGeneric XML toast template.
You can see the API reference here: https://learn.microsoft.com/en-us/uwp/api/windows.ui.notific...
They also often show up in bad locations, requiring you to dismiss them explicitly so you can continue using other UI elements.
This is sometimes intentional. Some design it that way to ensure that if they are going to do a certain action, that they have seen the toast. Obviously far from being the case all the time, but it happens that it is intentional sometimes.
That would make it an Alert or Dialog masquerading as a toast, no?
Okay you are right, timer-adjustable disappearance and history is important too and if it's local to where user's fields of view it's better than a toast every time of the day.
Accessibility doesn't even need to be related to any disability or unusual user requirement. A user-hostile website can be inaccessible even to users with perfect visual and motor functions.
There's no such thing as accessibility. Accessibility is just usability.
Toasts have poor usability because its easy to miss them. This makes them bad for everyone, regardless of screen reader.
This is not strictly true some accessibility choices can harm usability for those that don’t need that affordance, if it is not configurable.
I like toasts as a non-obtrusive confirmation of an action, but not as a method to present important information.
Among the various potential uses of a toast, IMO:
- quick, in response to a clicked button -> why not just show feedback on the button?
- quick, in response to a keyboard shortcut -> ok
- seconds or more after an action, say, if your import/export is done -> fine, but have a more persistent notifications inbox or send the user an email too, because if you dismiss the toast, how do you get back to that result?
- when you've just navigated to a page, as a way to present an alert or advisory about the new page -> if it's important enough, why not show it as a persistent alert on the page itself?
Far too many toasts are used for the last use case. Part of the reason for this, I think, is because if you detect something weird in a React callback, you'd need to wire up a whole new state variable to show it, vs. just calling a global toast() function at the time where you learn about the weird thing. But is it really much more work than toasting to roll something like const {alertElement, addAlert} = useAlerts()? And have it speak your design language?
Your 50-tabs-open multitasking users will appreciate you.
Agreed.
IMO a toast showing up shouldn't be a direct/immediate response to user action at all, ever. Toasts are purposely designed to steal attention. Don't try to steal attention from the user performing an action just to confirm that the action occurred; you already had their attention!
> if it's important enough, why not show it as a persistent alert on the page itself?
Because it's a crutch against bad design in an era when many companies don't employ designers, or arguably even as an exploit to be leveraged by marketing to try to brute-force the conversion of users to sales.
While there's nothing inherently wrong with them, I've become so accustomed to toasts being misused/abused that my instinctual response to that visual stimuli is that it's focus-friction and tantamount to being spammed, even when they're being used in benign or debateably useful ways.
I always just used it to confirm your last action on a POST —> GET sequence. Eg confirming that your save went through/rejected (the error itself embedded & persisted in the actual page). Or especially if saving doesn’t trigger a refresh so success would be otherwise silent (and thus indistinguishable from failing to click).
You could have the button do some fancy transformation into a save button but I prefer the core page being relatively static (and I really don’t like buttons having state).
It’s the only reasonable scenario for toasts that I can think of though.
> 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.
^ this is a great idea and please add it to github actions where it takes like 10 seconds for the new thing to show up on the list after you trigger one
Toasts as an audit trail of actions taken across the UI seems nice to me though, otherwise the alternative affordances disappear as you click around.
Sonner does it quite well (https://sonner.emilkowal.ski/)
I wonder if it is time to look into some more native support for toasts in browsers.
Some implementation that allows for browser level customization(timing, etc), as well as a notification center in the browser, and that integrates well with screen readers.
I like toasts from a visual perspective. They can look good(not always, of course), and they can convey small bits of information that could otherwise be displeasing to view in some designs. However, god have I missed a ton of notifications because of them disappearing too quick, and no way to view previous ones, or anything like that. I'm not visually impaired or anything, so I can't really comprehend the extent and issues people who do may have with toasts, and see what would be needed to make them accessible for them(if it's even possible), but would love to hear about it.
Toast pros:
- once set up, very easy to build, no “design” required
Toast cons:
- easy to miss
- at risk of layout issues (overlaying other information)
The tradeoff is real, but if the resources allow, I’d drop all toasts.
> once set up, very easy to build, no “design” required
Which is why they then get thrown around thoughtlessly. It becomes easy to pretend to have solved a problem using a toast instead of actually solving it.
Generally I have treated toasts as reassurance rather than important information
Like little 'saved' notifications when clicking through tabs, or email sent after clicking a send email button that might leave you on the same page
Web sites tend to over inform you of what's happening I like toasts (though I no longer use them since they're it of fashion) simply because you can disregard them
This is a terrible overview. The actual primary benefit of toasts is that they provide feedback on low-importance events without requiring the user to interact with them and without permanently taking up UI space. The web application I use most frequently would be infuriating if I had to deal with a modal window every time a toast would have been used, and UI space is at a premium for useful functionality, so occupying a permanent spot to relay those messages isn't a good solution either.
I wish software developers could drop this dogmatism. Same as the old Goto considered harmful trope outliving its usefulness and all that. It's always black and white - "people can misuse this tool, so this tool is inherently bad and should be eliminated from usage completely" - rather than acknowledging that many tools have great use cases even if they can also be abused.
There are many alternatives, OP lists some (banners, modals), but also inline messages, button states, next steps screens - not just modals.
There are also a lot of professional guis (think medical software), that use no toasts.
Any toast can be an inline message in my experience
Or a modal, for certain infrequent but important cases.
Refined GitHub [1] still does (for things like PR approvals & automations), and it feels odd indeed. Still worth adding on top of the stock UI.
[1] https://github.com/refined-github/refined-github
This article could have been one quarter the length.
what's an example website that doesn't require login that gets UX/UI right in most respects?
https://www.w3.org/WAI/ARIA/apg/
Yeah, probably a good idea to remove it since i use github everyday and have no idea what a toast is .
Modals, toasts. The UX set got very good at coming up with new words for pop-ups.
Modals are different from toasts. Modals take over your screen; you go into a separate "mode" for them. Toasts are non-modal; they just take up screen space but you don't have to interact with them.
"Toast" usually implies something that goes away on its own, though that's generally considered bad UX.
It's just jargon. Every field does that. In this case, you can really tell that it's two bits of jargon made up at different times, because one is dry and technical, and the other is a pun on "pop-up".
Same as modals?
Modals are, IMO, the literal worst UX element you can hate your users with. There are certainly valid use cases, but _absolutely not_ should be the default.
How come? I find them nice to allow for certain actions that don't really require navigation, and may want the user to easily return whenever they do anything in the modal or not. I understand it is historically bad due to accessibility, but there's more native support for it now. Assuming it is implemented with that in mind, is it still bad?
Modals are... modal. Popping up a dialog that requires interaction, while blocking access to the rest of the application.
Again, this is sometimes appropriate, but it's desperately wrong in so many places it gets used.
I personally don't find modals inherently all that bad, though they can definitely be implemented poorly. Does anyone have specific reading material on the problems with modals?
Thank god, toasts are so annoying. Every little action in Google Calendar has an associated toast/snackbar to go with it that tells you exactly what you just did and asks if you want to undo it. Like wtf? I can’t use my calendar app without these stupid toasts flying in and out and trying to draw my attention to read some irrelevant text. They go away too quickly for anyone not technically literate to click on them, and they are too slow to keep up when you’re creating a ton of events (they just fly in and out). I hope these go away, they add nothing to the application.
https://archive.ph/2025.12.08-211115/https://primer.style/ac...
Good. Now maybe GitHub will be able to work with JavaScript disabled?
They say to replace them with Banners, which are just a different style of a "Toaster", just usually stay longer, or are permanent until the user takes an action.
No, it's different. A "toast" is a floating element, a "push notification" which is detached from the panel, e.g. can disappear quite quickly. The banner is placed closest to the context where the action is triggered, e.g. might require the user to close it. If you have some disability, e.g. cognitive, visual or motor, it's likely to be easier to perceive the information. When a user creates an "issue", the "issue item" is displayed in the list, meaning that you won't need a secondary notification process.
The main problem with toasts is that they disappear with no hope of recovery before you get a chance to read them, obscuring other content in the process. Banners don't obscure other content, don't disappear without user action, and could theoretically have a message history.
An alternate take:
Why GitHub’s War On Toasts Is Bad News For Accessibility
https://medium.com/offmessageorg/why-githubs-war-on-toasts-i...
https://archive.ph/QMMye
A strange take. Toasts don't work so GitHub (and by extension MS) should have gone through W3C to implement a browser-wide solution instead of replacing them with alternatives in their products?
From the GitHub doc:
> 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.
The alternative proposes:
> Doing something, even as simple as adding a Jira ticket to a backlog, is not something I want to assume happened. I need to know it happened.
I fail to understand how seeing the created item in context does not let me know beyond any reasonable doubt that it was indeed created. Showing an additional toast adds nothing but noise and only showing a toast even more so.
Honestly, the JIRA example points out one of the main cases where I'm not exactly sure how to replace a toast. You don't have to be on the board to create a ticket in JIRA—so it may not be obvious in context.
I understand there are accessibility issues, but if the thing I am attempting to create will not be visible on the current view, what's the best approach?
Honestly, the same could be set for a large list or Kanban board. Just because of the number of records it may not be evident that the intended action occurred.
I am lucky in that I haven't used Jira in many years, so here are some examples of how GitHub does it:
- create an issue: redirect to the created issue
- create an issue from a project view (kanban board): close the creation modal, stay on the view, and let the newly created issue show up in the list
- create a sub-issue from within an issue open in a side panel of project view: close the creation modal, stay on the parent issue and render the newly created sub-issue in the section called "sub-issues"
Within the awkward constraints where GitHub projects clash with the old UX of issues this is works very well and I know way beyond any reasonable doubt that the desired action has indeed been performed. Error states like failure to create an issue can be rendered in the modal and I can retry right in context too. I fail to see how toasts would add anything.
In a product based on different principles this might not be possible but then the GitHub doc is internal guidance and not a universal rule.
As an aside, GitHub's issue creation modal used in the project view is well executed.
The standard way in desktop GUIs is a status line or similar. In other words, a dedicated area that displays the results of the last action. It has the important property that it doesn’t disappear without user action, and also doesn’t get in the way of what the user may want to see or do.
"Toasts are inherently bad for accessibility and bad UX, therefore GitHub is bad for not canonizing them into browsers"
... that's a somewhat odd stance to take.