WCAG 4.1.3 Status Messages

Success criterion 4.1.3 makes sure screen reader users hear the short messages that sighted users see appear on the page. When a customer presses "Add to cart" and a small "Added to cart" note appears in the corner, a blind customer may hear nothing and press the button again. It is level AA and appears in EN 301 549 as clause 9.4.1.3.

What the criterion requires

In content implemented using markup languages, status messages can be programmatically determined through role or properties, so that assistive technologies can present them without the message receiving focus.

A status message is a change in content that is not a change of context and that informs the user about:

• the success or result of an action ("Added to cart", "Coupon applied", "12 products found");
• a waiting state ("Loading…");
• the progress of a process ("Uploading 40 %");
• the existence of errors ("3 fields need attention").

Not covered: messages delivered by moving focus (such as a modal dialog), and content shown by opening menus, tabs or accordions — those are announced through focus or state changes. The results list itself is not a status message; the count of results is.

Typical failures on an online shop

• "Added to cart" toast or mini-cart count update that is not in a live region;
• filters that update the product grid and the "24 products" count silently;
• a coupon field that shows "Code applied" or "Code expired" without a role;
• form error summaries that appear after submit while focus stays on the button, with no role="alert";
• "Loading more products…" for infinite scroll that is only a spinner image;
• the opposite problem: role="alert" or aria-live="assertive" on routine messages, which interrupts users constantly.

How to check it

Automated: our checker has no rule for this criterion. It does not trigger the actions that make status messages appear, so this needs a manual check.

By hand: turn on a screen reader (NVDA, VoiceOver). Add a product to the cart, apply and remove a filter, enter a wrong coupon, submit a form with errors, load more products. Without moving focus, listen whether each visible message is announced. In developer tools, check that the message container has role="status", role="alert", role="log" or aria-live, and that it exists in the page before the text is inserted.

How to fix it

• Add an empty container with role="status" (or aria-live="polite") when the page loads, and insert the message text into it.
• Use role="alert" only for errors and urgent messages.
• Announce the whole message, for example "3 items in cart", using aria-atomic="true" if only part of it changes.
• Give spinners a text equivalent such as "Loading products" inside the live region.

Related criteria

• 3.3.1 Error Identification — errors described in text.
• 3.2.2 On Input — update content instead of changing context.
• 4.1.2 Name, Role, Value — controls expose their state to assistive technology.

Frequently asked questions

What is a status message in WCAG?

A change in content that is not a change of context and tells the user about the success or result of an action, a waiting state, the progress of a process or the existence of errors. Examples: "Added to cart", "12 results", "Saving…".

Should I use role="status" or role="alert"?

Use role="status" (a polite live region) for most messages such as cart updates and result counts. Keep role="alert" for important, time-sensitive messages such as errors, so screen readers are not interrupted all the time.

Is a dialog that takes focus a status message?

No. When focus moves to the message, as with a modal dialog, it is already announced and 4.1.3 does not apply. The criterion is about messages that appear while focus stays where it is.

Can an automated checker test 4.1.3?

No. The checker sees the page after load but does not add products to the cart or submit forms, so it does not see the messages appear. This needs a manual check with a screen reader.