Users need to know when their actions have succeeded or failed. This feedback must be perceptible to everyone, including screen reader users who might not be looking at the part of the screen where a message appears.

Regulatory Context

Status Messages (WCAG 4.1.3): In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

Timing Adjustable (WCAG 2.2.1): Users must have enough time to read and use content.

1. Status Messages (Toasts)

Transient messages like "Changes saved" should be announced by screen readers immediately, but should not move keyboard focus. Use `role="status"` (polite) or `role="alert"` (assertive).

Live Demo

Toast Notifications

Accessible toast notifications that announce to screen readers via aria-live regions.

Success / Info

<div role="status"> Changes saved successfully. </div>

Screen reader waits for silence, then speaks. Good for non-critical updates.

Errors / Critical

<div role="alert"> Connection lost. Retrying... </div>

Screen reader interrupts immediately. Use sparingly.

2. Non-Modal Overlays

Popovers, dropdowns, and drawers that are not modal (i.e., you can still interact with the rest of the page) require careful focus management.

Focus Order: If opening a dropdown moves focus into it, closing it must return focus to the trigger.
Esc Key: The Escape key should always close the overlay and return focus.
Outside Click: Clicking outside should close the overlay.

3. Timing & Persistence

Do not make messages disappear automatically if they contain critical information or require action, unless the user can adjust the timing.

Best Practice: Make error messages persistent (require a user click to dismiss). Make success messages disappear after ~5 seconds, but ensure they are still available in a notification center or log if relevant.