AgentKit

Posted on May 18 • Originally published at blog.a11yfix.dev

Why Your 'Added to Cart' Toast Notification Never Reaches Screen Reader Users (And the Two-Line Fix)

#a11y #webdev

You add something to your cart on a Shopify store and a small message slides in from the top right of the screen. "Item added to cart." It stays for three seconds, then fades away. The product page never reloaded. The cart icon updated a count. Everything feels smooth.

Now do the same thing with a screen reader running. The screen reader announces the button you clicked — "Add to cart, button" — and then nothing. No confirmation. No announcement that the item was added. No indication that anything happened at all. The cursor stays where it was. Three seconds later the visual confirmation has already disappeared from the screen, but the screen reader user never knew it existed.

This pattern is everywhere now. Cart confirmations. "Changes saved" banners in dashboards. "Message sent" notices on contact forms. Email signup confirmations. "Coupon applied" notifications at checkout. Login error messages that appear without a page reload. Almost every interactive surface on the modern web uses some version of a toast notification or snackbar to confirm that an action happened.

And almost every implementation of this pattern silently excludes screen reader users from confirmation.

This is the kind of accessibility failure that does not show up in a Lighthouse audit. It does not show up in axe DevTools. It does not show up when your developer manually reviews the page in Chrome. It only shows up when someone who actually uses a screen reader tries to use your site, gives up because nothing seems to be happening, and goes somewhere else. By that point you have already lost the sale and the customer has already added you to their internal "sites that do not work" list.

The good news is that fixing this is one of the smallest, cheapest, highest-impact accessibility improvements you can make. It is often two attributes on one HTML element. If you understand the pattern, you can usually fix it without rewriting anything.

What a toast notification actually is

A toast notification (named after toast popping out of a toaster) is a small message that appears temporarily, then disappears. Snackbar is the same concept from Google's Material Design. Both are used for transient confirmations.

The visual pattern is consistent: a small box appears at the top, bottom, or corner of the screen, contains a short message, optionally has an icon, optionally has a dismiss button, and disappears on its own after a few seconds. The user does not have to click anything for the confirmation to go away.

The reason developers love this pattern is that it is non-blocking. Modal dialogs interrupt the user and require a click to dismiss. Inline error messages require the user to scroll to find them. Toast notifications appear, communicate, and leave without demanding anything. They feel polite.

But "non-blocking" is the same as "easy to miss." For a sighted user who happened to glance at the corner of the screen, the toast registers. For a sighted user who was looking at the cart icon when the toast appeared in the corner, the toast does not register. For a screen reader user, the toast might as well not exist at all unless it has been built to announce itself.

The accessibility failure is not that the toast is temporary. It is that screen readers do not, by default, announce content that appears in the DOM after the page loads. The screen reader is busy reading whatever the user is currently focused on. Content that quietly appears off in the corner of the page does not interrupt the reading flow unless you specifically tell the screen reader that this new content is important enough to announce.

The two-line fix: aria-live

The W3C built an ARIA attribute specifically for this. It is called aria-live, and it tells assistive technology "when content changes inside this region, announce the new content to the user."

There are two values that matter:

aria-live="polite" — wait until the user is between sentences or has paused, then announce the new content.
aria-live="assertive" — announce the new content immediately, interrupting whatever the user is currently hearing.

For most toast notifications, polite is the right choice. The user does not need to be interrupted mid-sentence to hear that their cart was updated. They will hear the announcement at the next natural pause. assertive is appropriate for genuine errors that the user needs to know about before they continue — for example, "Your session has expired and your changes were not saved."

The fix looks like this:

<div aria-live="polite" id="toast-region">
  <!-- toast messages get inserted here -->
</div>

When your JavaScript updates the inner HTML of that div with the toast message, the screen reader will announce it.

That is the fix. Two attributes. One element. The visual styling of the toast does not change. The behavior for sighted users does not change. The only thing that changes is that screen reader users now hear what just happened.

The subtle part: where the region lives matters

The reason this trips people up is that aria-live regions are picky about timing. If you create the region and add content to it in the same JavaScript tick, screen readers sometimes miss the announcement. The region needs to already exist on the page when the new content is inserted.

The correct pattern is:

On page load, create an empty live region in the DOM, typically at the bottom of the body or in a wrapper near the top.
Style it however your toast notifications look — corner placement, drop shadow, fade animation, whatever.
When you need to announce something, insert the message text into the existing region.
After the toast disappears visually, remove the text from the region.

Here is a working HTML and JavaScript example:

<div aria-live="polite" id="toast-region" class="toast-region"></div>

<script>
  function showToast(message) {
    const region = document.getElementById('toast-region');
    region.textContent = message;
    setTimeout(() => {
      region.textContent = '';
    }, 4000);
  }

  // Example usage when the "Add to cart" button is clicked:
  document.querySelector('#add-to-cart').addEventListener('click', () => {
    // ...add the item to cart via your existing logic...
    showToast('Black wool scarf added to cart. Cart total: 3 items.');
  });
</script>

A few details that matter:

Use textContent, not innerHTML. Setting textContent triggers the live region announcement more reliably across screen readers.
Include enough context in the message that it makes sense out of context. "Item added to cart" is less useful to a blind user than "Black wool scarf added to cart. Cart total: 3 items." The sighted user can see what they just clicked. The blind user is relying entirely on the message.
Do not put more than one live region with the same priority on a page. Multiple polite regions can cause announcements to step on each other. One region per page, multiple messages over time, is the cleanest pattern.

What about Shopify, WooCommerce, Squarespace, and Wix?

If you are not the developer of your own site, you may not be able to edit the HTML directly. Here is what works on each major platform.

Shopify. Most Shopify themes use the AJAX cart pattern and most of them ship without accessible toast notifications. The fix is in theme.liquid (or whatever your toast partial is called) — add an aria-live="polite" wrapper around the existing toast container. Shopify's Dawn theme (the default since 2021) ships with this set correctly in newer versions, but custom and older themes frequently do not. If you cannot edit the theme files directly, this is a 15-minute job for a freelance Shopify developer. Worth doing before any audit.

WooCommerce. The default WooCommerce "Added to cart" message is a noticeable accessibility gap that has been an open issue on the project's GitHub since 2019. Some themes patch it. Some do not. The fix lives in the theme's single-product.php or loop/add-to-cart.php template, depending on which override is in place. For a non-developer, the most practical option is to install an accessibility-focused plugin that wraps the WooCommerce notice in an aria-live region.

Squarespace. Squarespace ecommerce uses a confirmation modal rather than a toast in most templates, which is a different accessibility pattern. The modal needs to manage focus correctly (moved into the modal on open, returned to the trigger on close). Squarespace's default modal handles this reasonably well in newer templates, but custom code injection can break it. Test with VoiceOver before assuming it works.

Wix. Wix's ecommerce confirmation is similar to Squarespace's — a modal rather than a toast. Wix has improved accessibility on its Stores app in 2024–2026, but custom HTML embed widgets that you may have added do not get this treatment automatically. If you have a custom newsletter signup or contact form using Velo code, that is the place to check.

How to test in five minutes without coding

You do not need to know what aria-live is to test whether your toast notifications are accessible. Here is the five-minute test.

On a Mac, open System Settings, then Accessibility, then VoiceOver. Turn it on. (Cmd-F5 also toggles it.) Open your website. Add a product to cart, sign up for the newsletter, send a contact form message, or do whatever action your site uses toast notifications for. Listen.

If VoiceOver reads the toast message out loud, you are fine. If it stays silent, you have the failure described in this article and a 15-minute fix to schedule.

On Windows, the equivalent is NVDA, which is free. Same test: trigger the action, listen for the confirmation.

You do not need to be fluent with the screen reader to do this test. You are not navigating; you are just listening for whether the confirmation gets announced. If you can hear silence, you can run this test.

Why this matters more than it looks like it matters

It is tempting to dismiss this as a minor edge case. The toast appears, sighted users see it, blind users do not, but everything else on the site works, so what is the actual harm?

The actual harm is that the screen reader user does not know whether their action succeeded. They click Add to Cart. They do not hear anything. They cannot tell if the click registered. So they click again. Now they have two items in their cart, or three, or four, with no way to verify because the cart contents are also often delivered visually. They eventually navigate to the cart page to see what is there, discover the duplicates, and have to fix it manually.

Multiply that across every interaction on your site — every form submission, every save, every coupon application, every cart change — and you have a site that punishes screen reader users with constant uncertainty. They learn to mistrust the site. They go elsewhere. Their friends and family hear about the experience.

This is also the kind of failure that turns into ADA Title III demand letters. A plaintiff's firm runs an automated scan, finds an "add to cart" flow with no accessible confirmation, sends a demand letter, and you are in settlement negotiations over what was a two-attribute fix. The cost of the demand letter and the legal response will exceed the cost of fixing the entire site, including the toast notifications, by an order of magnitude.

And finally: this is the most fixable kind of accessibility failure that exists. There is no design tradeoff. There is no performance cost. There is no need to involve UX research. You add an attribute. The site continues to look and behave exactly as before. The screen reader user gets the confirmation. Everyone wins.

A quick mental model for the next time you ship a notification

The next time your team is shipping any feature that quietly confirms something to the user — a save, an upload, a payment, a status change — ask one question: "If the user could not see the screen, how would they know this happened?"

If the answer is "they would hear the announcement from the live region," you are doing it right. If the answer is "they would not," you have an accessibility gap.

This question scales. It applies to "saved" banners, password-strength meters, character-count indicators, loading spinners that should announce when content is ready, validation errors that appear inline, search-result-count updates that change as filters are applied, and dozens of other patterns. Every one of them is a case where sighted users get visual feedback and screen reader users get silence — unless someone built the live region.

If you take one thing from this article, take this: silence is a bug. Every confirmation that exists for sighted users should exist for screen reader users too. Live regions are how you ship that.