WCAG 4.1.3 — Status Messages

What this requires

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. The criterion targets toast notifications, inline confirmation messages, search-result counts, upload-progress updates, and validation feedback — anything that communicates state without requiring the user to navigate to it.

How AI coding tools fail this

When asked to "show a confirmation toast after save", AI tools render a <div> with the message and animation styling but no ARIA live region. Sighted users see the toast; screen-reader users get no announcement and never learn the save succeeded.

The second pattern: role="alert" used for everything, including mundane confirmations. role="alert" interrupts whatever the screen reader is saying — useful for errors, disruptive for "saved". Use aria-live="polite" instead.

The third: live regions wrapping content that mounts dynamically. The screen reader needs the live region to exist before the content lands inside it. A <div aria-live="polite">{message}</div> that renders only when a message is present doesn't get announced — the live region itself was just added.

Failing examples

A toast with no ARIA:

{toast && (
  <div className="fixed bottom-4 right-4 rounded-md bg-green-700 px-4 py-2 text-white">
    {toast.message}
  </div>
)}

A late-mounted live region:

{message && (
  <div aria-live="polite">{message}</div>
)}

Passing examples

A persistently mounted live region, with the message inserted on state change:

<div
  aria-live="polite"
  aria-atomic="true"
  className="sr-only"
>
  {message}
</div>

Plus visual confirmation that doesn't depend on the live region:

<>
  <div
    role="status"
    aria-live="polite"
    aria-atomic="true"
    className="sr-only"
  >
    {message}
  </div>
  {toast && (
    <div
      aria-hidden="true"
      className="fixed bottom-4 right-4 rounded-md bg-green-700 px-4 py-2 text-white"
    >
      {toast.message}
    </div>
  )}
</>

For errors that should interrupt, use role="alert":

{error && (
  <div role="alert" className="text-destructive">
    {error.message}
  </div>
)}

Edge cases

role="status" vs role="alert". status is polite; alert interrupts. Use status for non-urgent updates; alert for errors and time-sensitive messages.
aria-live="polite" vs aria-live="assertive" map to the same distinction (polite = status, assertive = alert).
The container has to exist before the message lands. Mount the live region empty on first render, then update its contents.
aria-atomic controls whether the screen reader announces the whole region or just the change. For toasts, aria-atomic="true" reads the new message in full.
Loading states ("Searching...", "Loaded 12 results") are status messages too. Wrap them in a live region.

How Jeikin handles this

axe-core flags toast components and confirmation surfaces that lack a live region. The dashboard maps each finding to WCAG 4.1.3. The deeper question — "is the message actually announced?" — needs runtime testing with a screen reader, captured as a guided review.