WCAG 4.1.3 — Status Messages
"Your changes have been saved." A sighted user sees a small green confirmation in the corner. A screen-reader user hears nothing — unless the message was announced through a live region. Status messages have to reach everyone.
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.
Edge cases
role="status"vsrole="alert".statusis polite;alertinterrupts. Usestatusfor non-urgent updates;alertfor errors and time-sensitive messages.aria-live="polite"vsaria-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-atomiccontrols 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.