Level AAWCAG 2.1

4.1.3 Status Messages

Status messages can be programmatically determined through role or properties such that they can be presented to assistive technology users without receiving focus.

Last reviewed: September 9, 2026

Understanding 4.1.3

This criterion lets screen reader users learn about important updates, such as "3 items added to cart," a form submission confirmation, or a search result count, without needing focus to move to the message and without interrupting their current task. This benefits screen reader users broadly, and is especially important on single-page applications where content updates dynamically without a page reload that would otherwise reset a screen reader's reading position.

How to Meet It

Mark the container that will receive the status update with an appropriate live region role or attribute: role="status" or aria-live="polite" for non-urgent updates like "item added to cart," and role="alert" or aria-live="assertive" for urgent or critical updates like "session expired." Ensure the container exists in the DOM before the message is injected, since adding the aria-live attribute at the same time as the content can cause some assistive technology to miss it, and make sure focus is not forced to move to the message.

Code Examples

INCORRECT

<div id="cart-msg"></div>
<script>document.getElementById('cart-msg').textContent = 'Item added to cart';</script>
<!-- No role or aria-live; screen reader users are never told the cart updated -->

CORRECT

<div id="cart-msg" role="status" aria-live="polite"></div>
<script>document.getElementById('cart-msg').textContent = 'Item added to cart';</script>
<!-- role="status" announces the update to screen readers without moving focus -->

Frequently Asked Questions

Should I use aria-live="assertive" for everything so users don't miss messages?

No. Assertive interrupts whatever the screen reader is currently announcing, which is disorienting if overused. Reserve assertive / role="alert" for time-critical messages like errors or session timeouts, and use polite / role="status" for routine confirmations, which wait until the user pauses.

Does a visible on-screen success banner need a live region if it's already visible?

Yes, if it isn't near the current focus or in the tab order. A sighted user notices the banner appear visually, but without a live region a screen reader user gets no equivalent notification that anything happened.

Related Success Criteria

4.1.1 Parsing 4.1.2 Name, Role, Value

Quick Facts

Criterion4.1.3
LevelAA
IntroducedWCAG 2.1

Automate Compliance

AccessiSight automatically scans and identifies 4.1.3 issues in your codebase.

Try Scanner Free