Every Shopify merchant has heard some version of "you could get sued over your website" and reasonably wondered whether that's a genuine risk or an agency trying to sell an audit. The honest answer is that it's a genuine and measurably growing risk, concentrated disproportionately on ecommerce, and it has been for years — but the lawsuit exposure is really a symptom of a more basic problem: a meaningful share of disabled shoppers, screen reader users, keyboard-only users, and people with low vision or motor impairments simply cannot buy from stores that weren't built to let them. That's a real, addressable engineering problem with a well-documented standard (WCAG) behind it, not a vague compliance checkbox. This post covers what the legal landscape actually looks like right now, what WCAG 2.1/2.2 AA requires in practice on a Shopify storefront, why checkout is the highest-risk surface, where Shopify's own themes fall short, why the "install a widget" shortcut has become a liability of its own, and what a real remediation process looks like.
The lawsuit numbers are real, and ecommerce is the target
Digital accessibility litigation tracking isn't perfectly standardized — different firms count federal-only filings versus federal-plus-state, and totals vary by source as a result — but every major tracker points the same direction. UsableNet's annual lawsuit report and comparable trackers put 2025 federal website accessibility filings meaningfully above 2024, with year-over-year increases commonly reported in the 20-30% range depending on methodology, and mid-2026 filing pace projected toward a new annual record. The consistent, cross-source figure that matters most for a Shopify merchant specifically: ecommerce and retail sites account for somewhere between two-thirds and roughly four-fifths of all digital accessibility lawsuits, by a wide margin the single most targeted category of business online. This isn't spread evenly across every industry — it's concentrated on stores that sell things.
None of this is speculative or a niche legal curiosity. It's a well-established plaintiff's bar practice: a small number of law firms and serial plaintiffs file large volumes of nearly identical complaints against ecommerce sites, typically alleging that a screen reader user or keyboard-only user couldn't complete a purchase due to missing alt text, unlabeled form fields, or keyboard traps. Filings have historically clustered in a handful of plaintiff-friendly federal jurisdictions, with New York and California consistently cited as the heaviest volume states. If you sell in the US and your store has meaningful traffic, you are statistically inside the pool these suits get filed against — not because you did something unusually bad, but because inaccessible ecommerce sites are extremely common and the legal mechanism to sue over it is well worn at this point.
How we got here — and why there's still no formal regulation
A detail that surprises a lot of merchants: there is no federal regulation that explicitly spells out what an ADA-compliant private business website looks like. Title III of the ADA, passed in 1990, covers "places of public accommodation" and never mentions websites, because websites weren't a consumer commerce channel yet. Courts have spent the following three decades arguing about whether Title III applies to websites at all, and the case that effectively settled it for ecommerce was Robles v. Domino's Pizza — a blind plaintiff who couldn't order through Domino's website or app sued under Title III, the Ninth Circuit ruled in 2019 that the ADA applies to a business's website and app when there's a real connection to a physical place of business, and the Supreme Court declined to hear Domino's appeal that October, letting the ruling stand. That non-decision is functionally the reason ADA website litigation exists at the scale it does today.
Because Congress and the Department of Justice have still not issued a formal Title III website accessibility rule for private businesses, there's no single legal bar to clear — WCAG 2.1 or 2.2 Level AA has instead become the de facto standard cited in settlement agreements, consent decrees, and DOJ guidance letters, without ever being codified into binding regulation for private commerce. That's a meaningfully different situation from Title II, where the DOJ did issue a formal rule in 2024 requiring state and local government websites to meet WCAG 2.1 AA on a fixed timeline — private ecommerce operates in the gap where WCAG is the de facto industry standard everyone references, but not a law with a specific compliance deadline. If a meaningful share of your customers are in the EU, note that the European Accessibility Act, which took effect June 28, 2025, is a genuine hard legal requirement for ecommerce services sold to EU consumers (built on WCAG 2.1 AA via the EN 301 549 standard), with the first EAA-based lawsuits already filed in France in late 2025 — this is worth taking seriously separately from the US picture if you ship internationally. None of this is legal advice; if you've received a demand letter or are assessing specific exposure, that's a conversation for an attorney who handles ADA Title III or EAA matters, not a blog post.
What WCAG 2.1/2.2 AA actually requires on a storefront
WCAG (Web Content Accessibility Guidelines) is a W3C standard organized around four principles — content must be perceivable, operable, understandable, and robust — broken into specific, testable success criteria. At Level AA, the tier virtually every legal and industry reference point uses, the practical requirements on an ecommerce storefront break down into a handful of things that show up constantly in real audits. Color contrast needs a 4.5:1 ratio for normal body text against its background, 3:1 for large text (roughly 18pt or 14pt bold and up), and 3:1 for non-text UI elements like button borders, form field outlines, and focus rings — a huge share of Shopify theme customizations fail this the moment a merchant picks a pale brand color for body copy or button text because it "looks clean." Every meaningful image needs alt text that describes its actual content or function, not filler like "image1.jpg" or the product title stuffed in verbatim on every thumbnail — and decorative images (spacers, background flourishes) should carry empty alt attributes so screen readers skip them instead of reading noise.
Keyboard operability is non-negotiable and frequently ignored: every interactive element — nav menus, filters, quantity steppers, size selectors, modal popups, cart drawers — has to be reachable and operable using Tab, Shift+Tab, Enter, and Space alone, in a logical order, with no keyboard traps where focus gets stuck inside a component and can't escape. Every focused element needs a visible focus indicator, and under WCAG 2.2's newer criteria, that indicator can't be fully hidden behind a sticky header or cookie banner, and it needs at least a 2-pixel-thick outline with 3:1 contrast against its surroundings. ARIA labels matter, but the common failure runs the opposite direction from what people expect — merchants and app developers sprinkle ARIA attributes onto elements that already have correct native semantics, and misapplied ARIA (a wrong role, a redundant label, an aria-hidden attribute left on visible content) frequently makes a page less accessible than using plain, correct HTML would have. The first rule most accessibility engineers follow is: don't reach for ARIA if a native HTML element already does the job.
Checkout is where accessibility risk actually concentrates
If you can only prioritize one part of the store, prioritize checkout, and there's a specific legal logic behind why. Robles turned on the idea that an inaccessible ordering flow denies someone access to the actual goods and services of the business — not the marketing copy, the goods and services. A blog post with bad alt text is a real WCAG violation and a real usability problem, but a checkout flow a screen reader user can't complete is the exact fact pattern that generates a lawsuit, because it's the point where accessibility failure and commercial harm are the same event.
The specific things that go wrong in checkout, repeatedly, across real audits: form fields without properly associated labels, so a screen reader announces "edit text" with no indication of what the field is for; error messages communicated by color alone (a red border with no text, or a toast that appears and disappears before a screen reader user can navigate to it) rather than being programmatically associated with the field and announced; visual CAPTCHAs with no accessible audio or logic-based alternative, which can block a blind customer from completing a purchase entirely; session or cart timeouts that don't give people who need more time — including many screen reader and switch-device users, who navigate more slowly by necessity — a way to extend the session before it expires; and address or payment forms that force a customer to manually retype information (shipping address into billing, for instance) that WCAG 2.2's newer redundant-entry criterion says should auto-populate or be selectable instead. None of these are exotic edge cases — they're common patterns in default checkout customizations, particularly on stores that added custom fields or third-party payment widgets without testing the result with a keyboard alone or an actual screen reader.
Shopify's native theme baseline — real, but not sufficient
Shopify does hold its theme store to actual accessibility requirements, and this is worth crediting honestly rather than dismissing — themes submitted to the Shopify Theme Store have to meet baseline criteria covering things like ARIA labeling on interactive elements, basic keyboard navigation support, visible focus states, and minimum touch target sizing around 44x44 pixels for mobile tap targets. Dawn, Shopify's own free reference theme built on the Online Store 2.0 architecture, is generally regarded as the most accessible theme Shopify ships — it has clean semantic HTML, a real heading hierarchy, working skip-navigation links, and reasonably solid out-of-the-box keyboard support compared to older or heavily animated third-party themes.
The honest limit is that Shopify's theme store baseline covers a fraction of what full WCAG 2.2 AA actually requires — industry estimates put the theme store's mandatory accessibility checks at somewhere around 16-22% of the 86 total WCAG 2.2 Level AA success criteria, which means the other four-fifths of the standard simply isn't something Shopify's submission process tests for. Even Dawn, un-customized, out of the box, has been independently audited with somewhere in the range of 30 to 100 individual WCAG violations depending on which pages and components are evaluated — no Shopify theme, free or paid, is fully WCAG 2.2 compliant as shipped, and Shopify itself doesn't claim otherwise; there's no "WCAG-certified" badge in the theme store. Every layer a merchant adds on top — a review app, an upsell popup, a custom section built by a freelancer, a size-chart modal, a currency switcher — is a fresh opportunity to break whatever accessibility the base theme had, because none of those third-party additions go through Shopify's theme-store review at all. A theme choice is a reasonable starting point. It is not a compliance strategy on its own.
The overlay widget problem
The fastest-growing category of "accessibility fix" pitched to Shopify merchants is the AI-powered overlay widget — a single line of JavaScript that promises to scan your site and automatically remediate accessibility issues, often with marketing language like full WCAG 2.1 AA compliance in 24 to 48 hours. It's an appealing pitch because it's cheap and requires no development work, and it's worth being direct about why it doesn't hold up: an overlay sits on top of your existing DOM and tries to patch problems at runtime with automated scripts, which cannot reliably fix structural issues like a checkout form with no real label association, a broken tab order baked into your theme's markup, or a keyboard trap inside a third-party app's modal. It can add some superficial affordances — a floating accessibility menu, font-size controls, a contrast toggle — without touching the underlying code at all.
The regulatory and legal record on this specific approach is no longer theoretical. In 2024, the FTC fined accessiBe, one of the largest overlay vendors, one million dollars and issued a consent order specifically over deceptive claims that its AI overlay could make any website WCAG 2.1 AA compliant. UserWay, another major overlay vendor, was hit with a class-action lawsuit in Delaware alleging its marketing promised foolproof ADA compliance and failed to deliver, after a customer using the widget was sued over their site anyway. UsableNet's tracking found roughly a quarter of digital accessibility lawsuits filed in a recent year specifically targeted sites that already had an overlay installed — meaning plaintiffs' attorneys now treat the presence of an overlay as a signal that a site's owner knew accessibility was a live issue and chose a cosmetic fix over real remediation, and courts have consistently declined to treat an overlay as evidence of a good-faith compliance effort. More than 800 accessibility practitioners, standards editors, and disability advocates — including accessibility staff at Shopify itself, alongside Google, Microsoft, Apple, and Squarespace — have publicly signed onto the Overlay Fact Sheet, a joint statement arguing overlays don't repair underlying code-level barriers and can actively interfere with the assistive technology they claim to support. That's about as close to industry consensus as this space gets, and it's a real reason to be skeptical of any pitch that promises instant, code-free compliance.
What a real remediation process actually looks like
Genuine accessibility work starts with an audit that combines automated scanning with actual manual testing, because the two catch different things and neither is sufficient alone. Automated tools (axe, WAVE, Lighthouse's accessibility pass) reliably catch maybe a third to half of WCAG violations — missing alt attributes, insufficient contrast ratios, missing form labels — because those are pattern-detectable in code. They cannot tell you whether your tab order actually makes logical sense to a real keyboard user, whether your custom size-selector component is genuinely operable with a screen reader, or whether an error message actually gets announced when it appears. That part requires a human tester who navigates the site using only a keyboard, and ideally a second pass using an actual screen reader (VoiceOver, NVDA, or JAWS) through the core user journeys — browse a collection, view a product, add to cart, and complete checkout end to end, not just spot-check individual pages in isolation.
From there, a real remediation process prioritizes fixes by actual user impact and legal exposure rather than by whichever violations are easiest to knock out first — checkout and account-creation flows first, core navigation and product discovery second, and lower-traffic content pages last. Fixes happen in the theme code and app configuration itself: correcting markup, adding real label associations, fixing focus management in custom components, adjusting color tokens to meet contrast ratios, and — critically — testing each fix with the same manual keyboard-and-screen-reader pass used in the audit, not just re-running the automated scanner and calling it done. A serious engagement also produces a written accessibility statement and a maintenance plan, because a store that passes an audit in January and then ships an inaccessible new app or theme section in June hasn't actually solved the underlying problem — it's addressed a snapshot in time, not gotten in front of an ongoing state.
A starter checklist most merchants can act on this month
You don't need a full audit to start closing the highest-impact gaps. Run your site's core pages through an automated scanner like axe or WAVE and fix the flagged contrast and missing-alt-text issues, since those are usually quick wins that also happen to be the most common violations cited in actual lawsuits. Unplug your mouse for twenty minutes and try to browse a collection, open a product, add it to cart, and check out using only Tab, Shift+Tab, and Enter — if you get stuck anywhere, a real customer using a keyboard or switch device gets stuck in the exact same place. Turn on VoiceOver (built into every Mac and iPhone, free, no setup) and listen to your homepage and one product page read aloud — you will hear immediately if your images have no meaningful alt text or your buttons announce as unlabeled.
Check your color contrast on body text, button labels, and form field text against your actual brand palette using a free contrast checker rather than eyeballing it, since low-contrast brand colors are one of the single most common violations on design-forward D2C stores. Confirm every form field, especially in checkout, has a visible label that's properly associated in code — not just placeholder text, which disappears the moment someone starts typing and isn't reliably read by all screen readers. And if you've already installed an overlay widget expecting it to cover you, treat that as a starting point for a real conversation, not a finished project — read what it actually does versus what its marketing claims, and budget for genuine remediation work rather than assuming the line of JavaScript is doing the job its sales page describes.
The business case beyond the lawsuit
It's worth separating the legal-risk conversation from the actual commercial one, because they point the same direction but for different reasons. The population of people with disabilities who shop online is large and consistently underserved by ecommerce specifically — a site that a screen reader user can't navigate, or a keyboard-only user can't complete checkout on, isn't losing that customer to a competitor, it's losing them entirely, permanently, without ever generating a support ticket or a piece of feedback telling you why. Most of that revenue loss is invisible in analytics, because someone who can't complete checkout usually just leaves rather than reporting the problem.
There's also a real, well-documented overlap between accessibility fixes and general usability and conversion work that has nothing to do with disability specifically. Clear focus states help everyone navigating quickly with a keyboard, not just screen reader users. Properly labeled forms reduce checkout errors and abandonment across the board. Sufficient contrast helps anyone on a low-quality phone screen in bright sunlight, which is a meaningfully large share of real mobile ecommerce traffic. Clean semantic heading structure that helps screen readers is the same structure that helps search engines parse and rank your pages. None of this means accessibility work should be sold purely as a conversion play — the legal exposure and the basic fact that disabled customers deserve to be able to shop are real reasons on their own — but it does mean the investment isn't purely defensive spending with zero measurable upside elsewhere in the business.
Where to start if you're taking this seriously
The honest version of this whole topic is that there's no shortcut that substitutes for real engineering work — not a theme choice, not an overlay widget, not a one-time scan you fix and forget. What actually moves a Shopify store toward genuine WCAG 2.1/2.2 AA compliance is a real audit combining automated and manual testing, prioritized remediation starting with checkout and core purchase flows, code-level fixes rather than runtime patches, and an ongoing process that catches new accessibility debt as themes, apps, and sections change over time — because a store is never actually "done," it's maintained or it's slowly regressing.
That's the kind of engagement Carryup's Shopify Design & Development work is built to handle when accessibility is the driver — auditing theme and checkout code against real WCAG success criteria, fixing the structural issues an overlay can't touch, and building new sections and components accessibly from the start rather than retrofitting them later. And because accessibility isn't a one-time project any more than performance or security is, our Care & Support engagements keep it maintained as the store evolves — new app installs, new theme sections, and seasonal campaign pages checked against the same standard rather than left to quietly drift out of compliance until the next demand letter arrives. If you've gotten a demand letter, are worried about exposure, or just want an honest read on where your store actually stands against WCAG 2.1/2.2 AA before you spend money on either a widget or a full rebuild, that's a conversation worth having with an engineering team — alongside, not instead of, your own legal counsel if you're already facing a specific claim.
If any of this sounds like your situation, talk to us. We'll tell you exactly where your revenue is leaking and what it would take to fix it. Explore Strategy & Consulting →