Live Regions: What aria-live Actually Does When Your Toast Appears
Your customer adds a product to the cart and a small toast slides in: added to cart. A sighted shopper sees it. A screen reader user hears nothing, because the toast was never announced. The cart icon changed, the page moved on, and the one person who needed the confirmation got none of it.
Polite, assertive, and the difference that matters
Success Criterion 4.1.3, Status Messages, is Level AA. It says status messages must be programmatically determinable so assistive technology can present them without the message taking focus. The mechanism is the live region, and the choice that matters is politeness. aria-live="polite" waits for the screen reader to finish what it is saying, then announces the update. aria-live="assertive" interrupts whatever is being read. role="status" is polite by default; role="alert" is assertive.
Most toasts should be polite. Added to cart, saved, and your message was sent are all polite. The assertive slot is for things that change what the user should do next: a payment failed, a session is about to expire, a form submission was rejected. Teams that mark everything assertive train users to ignore interruptions, and teams that mark everything polite leave errors unheard. Pick per message, not per component.
The choice is worth making per message because the screen reader treats the two very differently. A polite message waits for a gap in the speech, which means a confirmation that arrives while the reader is mid-sentence gets queued and spoken a few seconds later, and that is fine. An assertive message cuts in immediately, which is right for a payment failure and wrong for a newsletter signup, because the interruption costs the user their place in whatever they were reading. The rule of thumb is simple: if the message changes what the user should do next, it is assertive. If it only confirms what already happened, it is polite.
The region must exist before the message
The mistake that silences the most toasts is timing. A live region only announces changes to content inside a region that already exists when the change happens. If your code creates the toast element and its text in the same moment, many screen readers never register the region at all, and the message is never spoken. The region has to be in the page, empty, before the event fires. Create it once at page load, then write text into it.
The second mistake is reusing one region for messages that arrive in a burst. Three toasts in two seconds become one garbled announcement or the last one only. If your checkout can fire several status updates at once, clear the region between messages or queue them. A screen reader user who hears only the last of three messages has missed two facts. For the error side of this, see Accessible Error Suggestions on Checkout Forms.
Toasts, timers, and the auto-dismiss trap
A toast that vanishes after four seconds is a second failure hiding behind the first. A slow reader, a user with a cognitive disability, or anyone who tabbed away for a moment loses the message entirely, and WCAG 2.2.1 requires that timing be adjustable or extendable. Give the toast a close button, keep it on screen until dismissed or for a generous window, and never let it steal focus. A status message that moves focus is worse than one that stays silent: it yanks the user out of the task they were doing.
The honest test is a screen reader and a keyboard, not a scan. Load the page, add to cart, and listen. Then trigger an error and listen again. If the error interrupts and the confirmation waits its turn, the regions are right. If nothing is announced at all, the region was created too late, and that is a thirty-minute fix, not a redesign. Our post on the deadline that moved, The ADA Title II Deadline Moved Again. The Obligation Did Not., is a reminder that the standard behind these fixes is not going away.
Frequently asked questions
What is the difference between aria-live polite and assertive?
Polite waits until the screen reader finishes its current speech, then announces the update. Assertive interrupts immediately. Use polite for confirmations and assertive only for errors or time-sensitive warnings.
Does role=status do the same thing as aria-live polite?
Yes. role="status" carries an implicit aria-live="polite", so either works. role="alert" carries an implicit aria-live="assertive" and should be reserved for urgent messages.
Why does my toast show on screen but never get announced?
The live region was probably created at the same moment as the message. Screen readers only announce changes inside a region that already exists, so the region has to be in the page, empty, before the event fires.
Can a toast auto-dismiss after a few seconds?
It can, but the message must stay long enough to be read and announced, and WCAG 2.2.1 requires timing to be adjustable or extendable. A close button and a generous display window are the safer pattern.