An alternate take:

Why GitHub’s War On Toasts Is Bad News For Accessibility

https://medium.com/offmessageorg/why-githubs-war-on-toasts-i...

gherkinnn 15 hours ago | parent | next [-]

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.

▲

samsolomon 14 hours ago | parent [-]

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.

	▲	gherkinnn 13 hours ago \| parent \| next [-]
		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.
	▲	layer8 14 hours ago \| parent \| prev [-]
		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.

▲

Groxx 13 hours ago | parent | prev [-]

"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.