When the Cart Count Changes, Who Hears About It?

November 7, 2026

A cart badge that updates visually and says nothing to a screen reader leaves a blind shopper guessing. WCAG 2.2 criterion 4.1.3, Status Messages, is the rule that covers it, and the fix is a polite live region.

A shopper adds a pair of shoes to her cart. The little badge on the cart icon ticks from 0 to 1, and sighted shoppers see it instantly. A screen reader user hears nothing at all, because the badge updated without any announcement. She tabs to the cart to check, finds one item, and tabs back. Every add-to-cart becomes a round trip she should not have to make.

WCAG 2.2 Success Criterion 4.1.3, Status Messages, exists for exactly this case. Changes in content that are not the focus of the user's attention still have to be announced, through a live region, without moving focus. The cart count is the classic example, and most stores fail it.

What 4.1.3 asks for, and what it does not

Status Messages is a Level AA criterion. It says that when content changes to report the result of an action, or the state of an application, the change must be announced to assistive technology without receiving focus. The announcement goes through a live region, an element with aria-live set to polite or assertive, or a native element with an implicit live region role like status or alert.

Polite is the right level for a cart count. The announcement waits for a pause instead of cutting across what the screen reader is already saying. Assertive is for errors that block the task, like a payment failure. A cart badge announced assertively would interrupt the shopper mid-sentence every time she adds an item, which is worse than silence.

The criterion does not require announcing everything. A countdown timer that ticks every second, a stock ticker, a rotating banner, none of those are status messages. The test is whether the change reports the outcome of something the user just did, or a state she needs to know about to continue. Add to cart, yes. A live clock, no.

How stores get it wrong

The most common failure is updating the badge text and nothing else. The DOM changed, but no live region exists, so the screen reader has no reason to speak. The second failure is announcing too much: the live region contains the whole header, so adding an item re-reads the navigation, the search box, and the phone number. The shopper hears thirty seconds of header for a one-word change.

A subtler failure is the badge that announces but lies. The count updates in the header while the cart drawer still shows the old total, because two components read from different state. The announcement says 2 items, the drawer says 1, and the shopper no longer trusts either number. One source of truth for the count, rendered in both places, fixes it.

The fix, and how to test it

Give the badge a visually hidden status element, or put aria-live="polite" on a small status container that holds the count text. Keep the announced text short: "2 items in cart." Do not announce the whole product name and price unless the shopper asked for it; the add-to-cart button already told her what she added.

Test with a screen reader and a keyboard, not by watching the badge. Add an item, remove an item, and add the same item twice. Each change should produce one short announcement and nothing else. Then test the noisy case: add three items quickly and confirm the announcements queue instead of talking over each other. If your framework re-renders the live region on every keystroke elsewhere, scope it to the count alone.

Related reading: Focus Not Obscured: When a Sticky Header Hides the Keyboard, Error Suggestions That Actually Help: WCAG 3.3.3 in Checkout, Touch Targets That Are Too Small: Size, Spacing, and the 24 Pixel Floor.

Frequently asked questions

Does a cart count really need a live region?

Yes, when the count changes as a result of the shopper's action and she is not looking at the cart. WCAG 2.2 criterion 4.1.3 requires status changes like this to be announced without moving focus, and a polite live region is the standard way to do it.

Should the cart announcement be polite or assertive?

Polite. The count is useful information, not an emergency, and an assertive announcement would interrupt whatever the screen reader is already saying. Reserve assertive for errors that block the task, like a failed payment.

What if the badge announces the whole header?

That happens when the live region wraps too much content. Scope the live region to the count text alone, and keep the announced text to a few words, such as 2 items in cart. The shopper does not need the navigation re-read on every add.

How do I test a cart announcement?

Use a screen reader and a keyboard. Add an item, remove one, and add the same item twice, listening for one short announcement per change. Then add three items quickly and check the announcements queue instead of overlapping.

Find out where your store stands

Get a free accessibility audit

Frequently asked questions

What is the main takeaway from What should an agency check in a Shopify theme before promising accessibility??

The main takeaway is to work through the basics in order, check each step as a real user would experience it, and fix patterns at their source rather than patching a single example. A short written record of what you checked makes the next review faster and more reliable.

How should I apply this guide in practice?

Pick one page, product, or routine and apply the steps there first. Note what changes, keep the change if the result improves, and only then roll the same pattern wider. Small verified changes beat a large unverified overhaul every time.

What should I check again later?

Recheck after any template, product, app, or routine change, and on a regular monthly rhythm in between. Conditions drift over time, so a dated check is what tells you whether a fix held or quietly broke again.