Open a banking site and click "Pay Bill." For a second or two, the screen freezes, a small circular icon spins in the middle, and then the page jumps to a confirmation. A sighted user sees the spinner, sees it disappear, sees the new screen — and moves on without thinking. A screen reader user clicks the same button, hears nothing, then hears the confirmation screen begin reading from the top. The two-second gap between click and confirmation is a blank silence that costs trust and, increasingly, costs lawsuit money.
Loading states are everywhere on the modern web. They appear when forms submit, when search results load, when a cart updates, when a checkout finalises, when a chatbot is "thinking," when an AI search assistant is "writing." Designers spend hours making them feel snappy and on-brand — animated gradients, branded skeleton screens, witty progress messages. Almost none of those visual flourishes reach a screen reader. The user hears silence, and silence in software has a specific meaning: nothing is happening. So they click again. Or they hit Back. Or they assume the site is broken and call support.
This article is for non-developers — founders, content owners, marketing managers, designers — who need to understand why a spinner is an accessibility issue and how to make sure the fix actually lands on the engineering backlog. We will cover what the legal exposure looks like in 2026, what screen readers actually need to hear during a load, and exactly what to ask your team to change.
Why the silence is a real accessibility failure
The Web Content Accessibility Guidelines (WCAG) handle dynamic page changes through a specific success criterion called 4.1.3 Status Messages. The wording is dry, but the rule is simple: when the page changes state without moving keyboard focus — a loading state, a success message, a cart update, an inline error — that change must be announced to assistive technology programmatically. A visible spinner satisfies the visual side of the design. It does not satisfy 4.1.3 unless the spinner is accompanied by a live region that a screen reader picks up and reads aloud.
The 4.1.3 criterion is Level AA. That matters because every major accessibility law in 2026 — the European Accessibility Act, the US Department of Justice Title II rule that became enforceable in April 2026, the UK Public Sector Bodies Accessibility Regulations, the Section 508 update for US federal contractors, and the procurement standards in Canada, Australia, and Japan — references WCAG 2.1 AA as the compliance baseline. Failing 4.1.3 fails the law.
It is also one of the failures most likely to surface in a real user complaint rather than an automated scan. Spinners often pass an axe-core scan because there is nothing visibly wrong with the HTML — the failure is the absence of an aria-live announcement, not the presence of a bad element. The bug only shows up when a real screen reader user tries to use the site and hits a wall of silence.
What the silence sounds like in real life
Consider a small wedding-florist site that takes orders for arrangements. The order form has six fields. A customer using a screen reader fills them out, presses Place Order, and the site sends the request to the payment processor. While the processor verifies the card, the page shows a "Processing your order, please wait" spinner overlay for about four seconds.
A sighted customer sees the overlay, waits, and is rewarded with a confirmation screen. The screen reader customer presses Place Order, hears nothing for four seconds, assumes the click did not register, and presses Place Order again. The site double-charges the card. The customer calls customer service. The owner of the florist has a thirty-minute support call to refund the duplicate charge, and the customer never orders flowers from that site again.
Multiply that by every loading state on every site. A user who calls support to ask "did my order go through?" is the lucky outcome. The unlucky one is the user who silently goes to your competitor's site instead, and the worst outcome is the user who contacts a plaintiff's law firm because the silence cost them money or a missed appointment.
What an ADA demand letter looks like for a loading state failure
We have reviewed dozens of accessibility demand letters sent to small US businesses since the start of 2025. The letters are usually templated, run three to six pages, and cite specific WCAG criteria the demanding party claims to have tested. WCAG 4.1.3 Status Messages appears in roughly one in four letters now, up from almost zero in 2022. The specific complaint reads something like this:
"Your checkout page presents a loading indicator after the customer submits payment information. The indicator is visually presented but is not announced to assistive technology. JAWS, NVDA, and VoiceOver users receive no audio feedback during the loading period and cannot determine whether their submission has been accepted. This violates WCAG 2.1 Success Criterion 4.1.3 Status Messages."
The letter then typically demands either a settlement payment (commonly five to twenty thousand US dollars for small businesses, more for larger ones), a written commitment to remediate within a set timeline (usually 60 to 120 days), or both. The cost of fixing the underlying loading-state announcement is usually under an hour of developer time. The cost of not fixing it is far higher than that. Read our analysis of how much an ADA lawsuit actually costs for a sense of the range.
In the EU, the European Accessibility Act exposure is different in character but similar in size. A market-surveillance authority can issue a non-compliance order with a 30 to 90 day correction window, and continued failure can lead to fines that scale with company turnover. We have not yet seen a public EAA enforcement action specifically about a loading spinner, but the criterion is in scope and the act has been in force since June 2025. The first wave of enforcement is now landing in 2026.
What screen readers actually need to hear
A loading state needs to announce three things, in order:
First, that the load has started. When the user presses the button, the screen reader should hear something like "Submitting order, please wait." This confirms the click was received. The phrase should be brief — two to six words is plenty.
Second, optionally, that the load is still happening if it runs longer than expected. If the load takes more than ten seconds, an interim message like "Still processing, this can take up to thirty seconds" prevents the user from assuming the site has hung. Most loads finish in under three seconds and do not need an interim message.
Third, that the load has completed, with the outcome. "Order submitted successfully" or "There was a problem with your payment, please review the highlighted fields." The completion message is the most important of the three because it is what lets the user know they can act again.
The technical mechanism that delivers those announcements is an HTML attribute called aria-live. A region of the page marked with aria-live="polite" tells the screen reader to announce any text that appears inside it without interrupting the user. A region marked with aria-live="assertive" interrupts whatever the screen reader is currently saying to deliver the message immediately. For loading states, polite is usually the right choice; assertive is reserved for genuine emergencies like a session timeout warning.
The five places your site most likely has the bug
Based on the small-business sites we have audited in 2026, the loading-state announcement is missing most often in these places:
The checkout submit. The Place Order, Pay Now, or Submit Payment button on every e-commerce site. WooCommerce, Shopify, Wix Stores, Squarespace Commerce — all of them ship default loading spinners with no live region. We covered the WooCommerce-specific patterns in our WooCommerce accessibility checklist.
The contact-form submit. Contact Form 7, Gravity Forms, WPForms, Typeform, Tally — the form submission spinner is universally silent by default. The success message ("Thanks, we will be in touch") usually does appear in a live region in newer plugin versions, but the in-flight spinner does not.
The site-search results. As-you-type search results that update below the search bar are a classic 4.1.3 failure. Sighted users see the result count change ("12 results"); screen reader users hear nothing as they type and have no idea whether results exist.
The "Add to Cart" confirmation. AJAX add-to-cart buttons add the product to the cart and update the cart-icon counter without a page reload. The cart counter changes visually but the screen reader hears nothing, so users have no idea whether their click worked. Many users then add the same product a second or third time.
The chatbot "thinking" state. Live chat widgets, AI assistants, and customer-service bots all show a "typing" indicator while the response is generated. Almost none of them announce it. The user types a question, hears nothing, and waits, with no sense of whether the bot is working or stuck. Our chatbot and live chat accessibility guide covers the full pattern.
What to ask your developer (or your plugin vendor)
You do not need to know the code to spec the fix. Here is the conversation, in plain language:
"For every loading state on the site, please add a status message that screen readers can hear. The technical pattern is an aria-live region. When a load starts, the region should announce something like 'Submitting order, please wait.' When the load finishes, it should announce the outcome — success or failure. The announcement should not steal keyboard focus from wherever the user currently is. Please test the result with VoiceOver on macOS and NVDA on Windows, not just by looking at the visual page."
If you are using a no-code site builder (Wix, Squarespace, Webflow, Framer), the conversation is with the platform's support team or in a developer forum: "Does your checkout / contact form / search component support WCAG 4.1.3 Status Messages with an aria-live region? If not, when will it?" Most of the major platforms are catching up in 2026 because the EAA enforcement is putting pressure on them, but the default behaviour still fails in many cases.
If you are using a WordPress plugin (Contact Form 7, WPForms, Gravity Forms, WooCommerce extensions), check the plugin's accessibility statement or release notes for 4.1.3 support. WPForms Pro added proper status messages in version 1.8.5 (early 2026). Gravity Forms had support since 2.7. Contact Form 7 still requires manual customisation as of May 2026.
A simple browser test you can run today
You do not need a developer or a screen reader to start finding the bug. Here is a five-minute test that catches the worst offenders.
Open Chrome. Right-click anywhere on your site and choose Inspect. Click the Console tab at the top of the panel that opens. Paste this single line into the console and press Enter:
document.querySelectorAll('[role="status"], [aria-live]').forEach(el => console.log(el));
This prints every element on the page that is set up to announce status messages to screen readers. If you press the print button after clicking Add to Cart, Place Order, Submit Search, or any other action that triggers a spinner, you should see new elements logged or existing elements update. If you press the button and nothing appears in the console, your site has no programmatic announcement for that loading state.
This is not a full audit — it misses some patterns and gives false positives for others — but it is enough to start a conversation with your team. For a more comprehensive check, run a full five-minute accessibility audit on the same pages.
Why this matters more in 2026 than it did in 2024
Loading states have become more elaborate over the past two years. Generative-AI search, AI assistants embedded in checkout flows, real-time inventory updates, fraud-detection delays during card payment, and AI image generation during product personalisation have all added new loading patterns to ordinary e-commerce flows. Each new loading pattern is another chance to fail 4.1.3.
At the same time, screen reader software has become much better at handling well-implemented aria-live regions. NVDA 2024.3, JAWS 2025, and VoiceOver in macOS 14 and 15 all handle polite live regions reliably across Safari, Firefox, and Chromium-based browsers. There is no longer a good engineering reason to skip the announcement — the cross-browser, cross-screen-reader behaviour is solid.
And legally, both the US and the EU have moved into active enforcement. The Title II rule deadline came and went in April 2026 for state and local governments and any business that contracts with them. The EAA has been live for almost a year. Plaintiff law firms have templated the loading-state complaint and are sending it at volume. The window for treating spinners as a polish-pass nice-to-have is closed.
The fix is small. The risk of not fixing is not.
Adding an aria-live announcement to a single loading state is usually a one-line code change plus a one-line content change. A site with ten loading states typically takes a developer two to three hours to fix end-to-end, including testing with a real screen reader. Compare that to the cost of an ADA demand letter, a contracted accessibility consultant, or an EAA enforcement action: the math is not close. The reason the fix has not already shipped is almost always that no one with decision-making authority knew the bug existed. Now you do.
Walk through your site this week with a stopwatch. Every time you press a button that triggers a load — a checkout, a contact form, a search, a cart update, a chat — ask yourself: would a screen reader user know what just happened? If you cannot answer yes with confidence, that loading state is on the list.
We are building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.
Top comments (0)