Accessible toasts with ARIA live regions

WHAT THIS TESTS This checks whether you understand live regions, the mechanism for announcing dynamic content to assistive tech without changing focus, and their timing pitfalls.

A GOOD ANSWER COVERS The core idea is a live region: an element already in the DOM whose content changes are automatically announced by screen readers, no focus move required. Render the toast container, or a dedicated visually present announcer, on mount so it exists before any message; then update its text content when a toast fires. Choose politeness by urgency: aria-live polite, or role status which is implicitly polite, for ordinary notifications so the announcement waits for a pause; aria-live assertive, or role alert which is implicitly assertive, only for urgent, time-sensitive messages because it interrupts. Critically, do not move focus to the toast, which would yank keyboard users out of their task; the whole point is a non-disruptive announcement. Handle timing: queue or debounce rapid messages so a new one does not overwrite the previous before it is read, and keep messages on screen long enough or provide a persistent log.

COMMON WRONG ANSWERS Creating the live region element at the moment the toast appears, which many screen readers will not announce because the region was not present to observe. Using assertive for everything, constantly interrupting users. Moving focus to the toast. Auto-dismissing so fast the message is gone before it is read.

LIKELY FOLLOW-UPS When do you use assertive versus polite. Why must the region pre-exist. How do you handle a flood of notifications.

ONE CONCRETE EXAMPLE A persistent div with role status sits in the layout; when a save succeeds, the toast text Saved is written into it and a screen reader announces Saved without focus moving, while a critical error toast uses role alert to interrupt immediately, and both leave the user's keyboard position untouched.