> It’s notable that accessibility isn’t mentioned once in this post, or, in fact, in the component’s documentation.

It's a red flag for sure. That said, there's nothing preventing toasts from being accessible: https://react-spectrum.adobe.com/react-aria/useToast.html

I think it would be accurate for GitHub to say, "GitHub no longer uses toasts because we didn't want to make the effort to make them accessible or usable."

▲

bitbasher 2 hours ago | parent | next [-]

> It's a red flag for sure.

The first red flag was the repeated screenshots featuring Theo Browne, as if his thoughts or ideas carry any kind of authority.

▲

robin_reala a day ago | parent | prev | next [-]

Spectrum’s Toast docs don’t mention how they make Toasts accessible with screen magnifiers (more widely used than screen readers based on the last WebAIM surveys I saw), so I guess they didn’t consider them?

	▲	MrJohz 21 hours ago \| parent [-]
		Everyone knows accessibility is just throwing aria tags at any element you see. The more aria tags there are, the more accessible it must be, right? /s

▲

thunderfork a day ago | parent | prev [-]

I think that toasts are kind of an attractive nuisance when it comes to accessibility.

They can technically, with ample constraints and a great deal of restraint, maybe end up complying with WCAG, etc., but all it takes is one developer saying "well a toast is easy" or "this isn't that important, make it auto-dismiss" and you're back in bad pattern town.

You see this with government web design systems - they have a very limited and constrained palette of patterns, because it allows for more consistency and reliable accessibility, versus having a bunch of tools that you just generally shouldn't use.

(The GitHub page linked above also makes a great case for how "making toasts accessible" isn't as simple as just having the right aria roles - lots of details the Adobe design doesn't seem to completely cover, unfortunately)