←back to thread

117 points FragrantRiver | 1 comments | | HN request time: 0.216s | source
Show context
robin_reala ◴[] No.46182756[source]
Meanwhile, GitHub is removing Toasts from Primer, their design system.[1] They’re next to impossible to implement in a way that retains accessibility across all needs, and if you try to restrict their usage to places where accessibility doesn’t matter so much (simple ephemeral confirmations) people misuse them anyway.

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

[1] https://primer.style/accessibility/toasts/

replies(5): >>46183323 #>>46184146 #>>46186685 #>>46187013 #>>46189172 #
CharlesW ◴[] No.46183323[source]
> 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."

replies(3): >>46184464 #>>46185290 #>>46198911 #
1. thunderfork ◴[] No.46184464[source]
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)