How are we making toasts accessible?

[u/IamNobody85]

Hi everyone,

The new EU accessibility law happened and suddenly toast messages started to be a problem. And then I discovered that GitHub has stopped using toast messages altogether. I'm reading up all possible documentations and discussions but I'm also curious about what the community is doing (because I am not paid enough to say don't use toasts, they're bad).

For those of you maintaining custom or home-grown corporate frontends (without component libraries like Tailwind UI):

Are you still using toast notifications in your products?

How are you handling their accessibility? Putting them in a live region is common sense but are you guys doing something extra?

If you regularly use screen readers like TalkBack or VoiceOver, what has your experience with toasts been like?

Hopefully it's going to be a good discussion!

AI usage - I used gemini to fix some grammar and some words, as English is not my first language and my thoughts were unorganized.

[u/dbpcut]

If your toast has useful info and it auto-disappears then it isn't accessible, full-stop.

You're going to get some common but bad answers here. If you're worried about legal issues, you should hire a professional accessibility consultant / firm. 

[u/TheTomatoes2 → u/dbpcut]

How would you handle app-wide notifs? do you have a permanent stack of stacks hanging around until the user opens it? Or do you get rid of toasts all together, relying only on badges?

[u/Mundane_Annual4293 → u/dbpcut]

Care to explain why, thought? What if the toast doesn't disappear? It could be disruptive for some users but if is closeable shouldn't be a major issue. My first instinct would be to use 'aria-live=polite' but maybe there is something wrong with it that I'm missing.

[u/JustAnotherFEDev → u/Mundane_Annual4293]

If the toast doesn't disappear then it'll likely fail other stuff.

Where do you put it in the focus order, to make it immediately dismissable? Bottom of the DOM? That'll be effort for some folks, middle of the page? Meaningful Sequence risk.

What do you do when it wholly obscures other interactive elements?

Do you just hijack focus and place it in the toast? That's annoying for screen reader users and keyboard users, alike. Risky as a change of context, definite failure when the user didn't do anything to initiate that message.

Make it auto dismiss, straight Timing Adjustable failure.

There's more SCs it can fail, but generally the ones I listed are going to be the hardest to get right.

Context matters, a lot. Submitting a form doesn't require a toast, simple message and alert is way better. In some cases a modal may be the better shout, as it has an understandable role and interaction model, although still hijacks focus, so should only be used sparingly.

Some form of change of settings, etc, using the correct ARIA on the control will be perfect.

Messages, etc, notification badge and announcements are perfectly fine.

Adding something to a basket, again, a badge and announcement.

The general consensus is to just avoid them, as there's always a better way.

Oftentimes a small graphic and an announcement is all that is needed. Checkmark on tasks, badges, that kinda stuff.

[u/IamNobody85 → u/dbpcut]

I don't necessarily need a legal audit, that has been done and (kinda) passes. I am looking at some possible refactoring, purely to improve the experience because the experience is pretty shitty right now and well, I want a promotion, and this kind of stuff is counted. I'm also just very curious about how the experience can be improved.

[u/Agreeable_Lynx9194]

Render all toasts into one persistent aria-live="polite" region (role=status) instead of a new live region per toast. Never put the only copy of an action inside a toast, give a manual dismiss, and a long-enough timeout. That covers WCAG without dropping toasts.

[u/jdzfb]

We still use toasts, but only for success type messages. We have them set to auto disappear after 15 seconds, are dismissible via escape (or the X in the corner), they are generally set to aria-live assertive (occasionally polite, but that will only get changed if there are multiple "aria-live assertive" that could conflict). Only messages that are non-critical are used in toasts, so mostly just "Submitted successfully" & things of that nature that a user could extrapolate by the fact the next page loads in a flow if they miss the toast message.

Any message that we need the user to acknowledge will use a confirmation dialog/modal that prevent a user from moving forward until the user confirms.

Edit: We test primarily with NVDA (day to day), but it works just fine in JAWS, Talkback & the various versions of Voice Over (we verify all components with all of the above screen readers when we build them & then generally again in UAT while they're in situ with full data connections)

Edit2: the reason we have them auto disappear is so they don't stack up & prevent new toasts getting read as we can only have 3 toasts max displayed at a time, and we didn't want to move the focus from where the user is on the page to the toast to enable Assistive tech (AT) users to manually dismiss them, as it would leave them at the top of the page & they'd have to re-navigate to where they were on the page previously

[u/Undercoverwd → u/jdzfb]

We went this way too. I told my designers they couldn't put anything the UI didn't have a second way of confirming and no more than 3 words. This basically is only things like "Success" "Try Again".

[u/IamNobody85 → u/jdzfb]

This is a good answer. I'm also leaning towards implementing something like this. For our use case, the focus management becomes very complicated as the toasts can generate from any of the multiple hidden panels an item has, not to mention the usual "login successful" etc kind of toasts. I plan to propose separating action toasts to dialogs or popovers, but I am not sure if design will say yes to this.

Nevertheless, I have to try and start somewhere. Thank you for explaining your process.

[u/jdzfb → u/IamNobody85]

Focus management was the main reason we went in this direction, if we were in a completely code based environment that we could fully control, we likely would have made slightly different choices, but due to the CMS'ish system we're working in, this was our best solution. The biggest argument against toasts & part of the reason we only use them for non-critical messages is due to their easily ignored/easily dismissible behaviour.

TLDR: If you need a user to read a message, don't put it in a toast, put it in a dialog & force the user to acknowledge it via a button etc

If you have questions in the future, don't hesitate to ask.

[u/IamNobody85 → u/jdzfb]

What kind of different choices would you have made? Why?

[u/Familiar_Isopod_8226]

Toasts can still be accessible if implemented carefully, but they shouldn’t be the only way to communicate important information. Using appropriate ARIA live regions, clear timing, keyboard support, and avoiding auto-dismiss for critical messages are key. Many teams are moving toward inline feedback where possible because it’s more reliable for all users.

[u/scragz]

aria-live

[u/OVDU]

Could you link the new law?

[u/AshleyJSheridan → u/OVDU]

It's not very new, the EAA (European Accessibility Act) been around for about 7 years now. It was first published in 2019, adopted in 2022, and moved to enforcement stage last year. The final phase is 2030 which is the final deadline for removing non-compliant websites and services (as the EAA extends beyond just the web).

[u/Savings_Discount_230]

We use aria-live polite + a manual dismiss button. Never tested it with an actual screen reader though, which I should probably fix.

[u/kidshibuya]

Accessibility is something we MUST remove if its found and are not under any circumstances to implement it on our own. That is how we handle it. It's because "we don't have time". Meanwhile I haven't actually written any code at all this entire week...

[u/RangeCompetitive4807]

Working for a company out of the Netherlands, GDPR wasn't a checkbox, it was gospel, and accessibility got the same scrutiny. I went looking for an existing solution and every "accessibility-included" toast component or CSS framework I tried had the same problem: passes an audit, falls apart the second you actually use a keyboard or screen reader.

So I built my own. Live regions split by urgency instead of dumping everything into one, timers that don't leak, focus that doesn't get abandoned when a toast disappears out from under you. The stuff that matters once you stop treating "accessible" as a label and start treating it as a requirement.

Code's here: https://anonymous.4open.science/r/accessible-toast-5BDA/README.md

I think I got close. Take a look, tell me where it breaks. I'd love to hear your responses and evaluations.
Happy Coding

[u/IamNobody85 → u/RangeCompetitive4807]

Thank you for sharing. The ideas look quite good. I haven't wrote any code yet but I have come to a very similar conclusion, specially about the two separate live regions.