Artificial Intelligence (AI) can build a retail storefront in an afternoon. It can generate product pages, create a checkout flow, and connect it to your backend processors. It can write the code behind all of it faster than any team could have a few years ago. What it can't do is tell you whether a shopper who relies on a screen reader can choose a size, add an item to the cart, or confirm the order actually went through.
That gap between what AI can produce and how accessible that output is for humans is something I've discussed more and more over the past year. And I want to be clear up front: this isn't an argument against using AI in development or content creation. The question was never whether AI belongs in accessibility work. It's whether the people and the knowledge around the AI are strong enough to keep it honest.
A storefront can pass an automated accessibility scan, earn a 100% score, and get sign-off from an agency and its stakeholders. But a shopper with a disability may still hit a wall that costs you the sale. That gap is also what invites a demand letter or lawsuit.
Retail sites are never finished. Promotions launch, catalogs grow, sites get redesigned, and more and more of that code and content is now generated with AI. That speed is real, and it cuts both ways. The same tools that let you ship faster can repeat one inaccessible pattern across hundreds or thousands of product pages before anyone notices there's a problem.
The 2026 WebAIM Million study offers a warning. For the first time in six years, detectable accessibility errors went up. In 2026, 95.9% of the one million home pages tested had detectable Web Content Accessibility Guidelines (WCAG) failures, up from 94.8% the year before. The average number of errors per page was 56.1.
WebAIM's analysis of the underlying code points to AI-assisted coding as part of the story, along with a wave of sites now generated almost entirely by AI. In other words, the web isn't improving at the pace many teams assume, and the tools meant to help may be quietly scaling the problem.
For retailers, this lands on top of an already serious litigation environment. In UsableNet's 2026 midyear research, 79% of digital accessibility lawsuits targeted eCommerce companies. When an inaccessible component sits in a shared template, it doesn't stay in one place. It's part of every page that reuses it, and AI can make that replication faster than ever.
Most of the trouble I see doesn't come from AI being useless. It comes from a handful of comfortable assumptions about what AI is doing when it writes or reviews code. Here are the four the UsableNet team encounters the most.
AI models have read the Web Content Accessibility Guidelines. The problem is what else they learned from. They were trained on a web that is overwhelmingly inaccessible, so while a model can recite the rules, it has seen very few strong examples of what correct, accessible implementation actually looks like. Given room to improvise, it tends to drift toward "best practices" that have little to do with WCAG. Knowing the rulebook and knowing how to build to it are not the same thing.
In practice, it's often the reverse. Give a model all the requirements at once and the first result can be reasonably solid. Start refining it one change at a time, and accessibility can slip without you knowing it. The model loses track of the original instruction to keep the site WCAG-conformant. Plus, the more complex and customized a website is, the more difficulty AI may have in working with the code.
Context matters too: a component that's correct on the home page can end up wrong when it's reused elsewhere, because the model doesn't know the new context the component sits in unless you tell it. And the same prompt that works beautifully in one session can fail in the next. That unpredictability is easy to miss until the code is live and you get complaints.
This myth actually has nothing to do with AI, and it's something I wish retail teams would let go of. Automated testing is genuinely useful, but it only covers a portion of the WCAG, roughly 25 to 30 percent. A clean automated report tells you that you passed the checks a machine can run, not that a customer can complete a purchase.
UsableNet has seen a team clear every automated issue in a couple of days by adding aria-hidden="true" to the page body, which technically removed the "errors" by hiding all the content from assistive technology. Zero detected issues, zero usable page. Poor prompting produces the same trap: ask an AI to "fix the errors," and it may not do it in a truly accessible way.
AI amplifies the competence that's already inside the team. It doesn't create it. In skilled hands, AI is a real accelerator. In hands that can't judge the accessibility of the output, it's a fast way to ship the wrong thing with more confidence. The danger isn't that AI is occasionally wrong. It's that someone without accessibility expertise often can't tell when it's wrong. Unfortunately, this is the case for many development teams. And accessibility was never a developer-only job to begin with. When we break down the WCAG success criteria, responsibility splits fairly evenly across development, design, and content and the knowledge gap tends to persist across each team.
None of this makes automated testing the enemy. It's the right tool for many jobs because it runs across a huge catalog quickly, flags recurring patterns, and gives you a repeatable benchmark release over release. That's real value, and I'd never tell a retail team to stop scanning.
The trouble starts when the scan becomes all that's used. Most WCAG success criteria depend on context: an element's role and its relationship to everything else on the page. That's exactly the kind of judgment automation can't make. The issues automation misses tend to be the ones that hurt customers most: broken interactions, confusing screen reader experiences, and barriers that only show up for a real user rather than a machine.
These manual checks are what reveal if someone can shop with you. Can a screen reader user select a size, add it to the cart, and hear that the cart updated? Can a keyboard user open and operate the product filters? When checkout rejects an entry, is the error perceivable so the shopper can fix it? A scan can't answer any of those. A person can. Testing with people who actually use assistive technology is still the only way to know the full journey works. AI can support that work. It can't replace it.
Used with care, AI earns its place as a tool that already-skilled teams use. It can excel with a narrow task, a precise instruction, and with someone who has accessibility expertise doing the prompting and reviewing the result. For retail teams, this can include (but is not limited to):
The common thread is specificity. "Make this checkout accessible" gives a model nothing to work with. "The checkout error message isn't programmatically associated with the email field, so a screen reader doesn't announce which field needs attention" gives it a bounded, solvable problem. The first invites a guess. The second invites a fix.
The quality of the instruction. A vague prompt forces the model to guess, while a precise one gives it a real problem, along with the information it needs to find and fix it.
The knowledge base behind the output. AI needs more than "follow WCAG." It needs the component, the specific criteria in play, the reason the element fails, and the role it plays in the customer's journey. Without those guardrails, a model can produce an answer that sounds right but doesn't actually make a fix.
This is the part we're actively working on at UsableNet. With AQA, our developer-led, AI-assisted platform, the aim is to give the AI two things: a precise identification of each issue, and a vetted body of accessibility knowledge to draw on. When a team's own developers act on that code-level guidance, it's grounded in something reliable, not the model's best guess.
As my colleague Michele Lucchini, UsableNet's Vice President of Product, likes to put it, the goal is artificial efficiency, not artificial intelligence. Put another way, the goal is to have AI make skilled people faster and help teams scale, not to hand over accessibility to the AI.
The approach I've watched succeed isn't complicated.
The retailers who get the most out of AI are the ones who already know what good accessibility looks like. They use AI to scale that knowledge, not to substitute for it.
Meanwhile, agentic AI is starting to add a new wrinkle that retailers should be ready for. Shopping agents that browse, recommend, and even buy on a customer's behalf are increasingly an option available to consumers. It's early days, but the same accessible foundations (clean semantics, meaningful labels, sensible structure) are what let those agents operate a site reliably. Accessibility work is increasingly the work that makes your storefront ready for whatever comes next.
If your storefront relies on automated tools or AI-generated code and you're assuming accessibility is handled, that's the assumption worth testing across product pages, cart, and checkout, where a barrier costs you both a customer and a sale. If you'd like a clear picture of where yours actually stands, request a consultation with UsableNet.