Shopify ADA compliance after a demand letter: what to do first

What an ADA demand letter about a Shopify store usually is

Most letters about online stores follow a pattern. A law firm, often on behalf of a tester who uses a screen reader, states that its client tried to use your store and could not, lists accessibility failures under the Americans with Disabilities Act, cites WCAG success criteria as the measure, and asks for two things: remediation of the store within a defined period and a payment to settle the claim. The failures listed are almost always the ones an automated scanner reports, because that is how the store was found: missing alt text on product images, low contrast, unlabelled form fields, controls that cannot be reached by keyboard, links with no meaningful text.

Two things follow from that. First, the letter is rarely unique to you. The same template goes to many stores that failed the same scan, which is why the failure list can feel generic. Second, the technical claims in it are checkable. You can run the same class of scan yourself, see whether the failures are real, fix the ones that are, and produce dated evidence of the before and after state. That evidence is what a defence lawyer asks for, and it is also what the remediation clause of most settlements requires you to show.

Vendor compilations of 2025 settlements put the typical range in the mid four to low five figures, with remediation to WCAG 2.1 AA within a set window. That is not a prediction about your letter. It is the reason the technical work is worth doing this week rather than after the response goes out.

The first week, in order

1. Talk to a lawyer before you reply, pay or ignore it. Letters carry a response window. Whether to respond, what to say and whether the claim has merit are legal decisions. Do not email the firm yourself and do not post the letter publicly.
2. Scan the page types the letter names. Most stores have four templates: home, a collection, a product and the cart. A scan of each covers the catalogue. Use the free scan below for any page, or the landing page scan, and save the dated result.
3. Fix the critical and serious items first, in the theme. Alt text, contrast, labels and accessible names are theme and product data changes, not a project. The alt text checker and the contrast checker handle the two biggest categories on their own.
4. Keep dated evidence of before and after. A dated scan report from before the fixes, the fix log, and a dated scan after. Keep them with the letter, so whoever handles it can see what was found, what was fixed and when.
5. Do not install an overlay app as the fix. Complaints cite the widgets themselves, roughly a quarter of stores sued in 2025 already had one, and in January 2025 the FTC ordered the largest overlay vendor to pay $1 million over its compliance claims. Fixing the theme is cheaper and it is what the letter actually asks for.

Scan one storefront page free

Enter the page the letter names, or your home page. We load it in a real browser, run the same class of automated WCAG 2.2 checks a plaintiff's tester starts with, and show you the summary here on screen. Nothing is installed in your store, and a queued result is deleted as soon as it is shown to you. A big storefront can take a minute.

Storefront page address Scan this page free

Free, here on screen: the score, issue counts by severity, and the top 3 issues with a fix hint. In a plan: every issue with fix steps, a dated PDF report of each scan, and weekly re-scans, from $19 a month.

What Shopify gives you, and where your part starts

Shopify publishes accessibility guidance for theme developers and ships reference themes that follow it. The checkout is hosted and maintained by Shopify, which removes the riskiest single flow from your plate. That is a real head start, and it is also where the platform's responsibility stops.

Your storefront is a theme you customised, a product catalogue you imported, a set of apps that inject their own markup, and content that other people on your team edit. Shopify's sections architecture is built so merchants can rearrange and duplicate blocks without touching code, which is exactly why a store's accessibility drifts: every section a merchant adds is new markup that nobody tested. The platform cannot check whether the alt text you typed describes the photo, whether your brand's sale badge clears 4.5 to 1 against its background, or whether the app you installed yesterday traps keyboard focus.

So the honest framing of Shopify ADA compliance is this. Shopify removes one large class of risk and hands you the rest. The rest is the part that shows up in letters.

The six failures that make up most of what a scanner finds

The WebAIM Million has measured the same pattern every year: a small number of failure types account for the overwhelming majority of automatically detectable errors. On a store they take these shapes, and they are almost certainly what your letter lists.

1. Product images with no alt text

Bulk imports, supplier feeds and CSV uploads rarely carry alt text, so a catalogue of two thousand products can arrive with two thousand unlabelled images. A screen reader then announces the file name, or nothing at all. WCAG 1.1.1 asks for a text alternative that serves the equivalent purpose, which for a product photo means the product, the variant and anything the photo shows that the copy does not. Decorative images, the lifestyle banner behind a heading, should carry an empty alt attribute so they are skipped rather than narrated. Our alt text checker reads a page and sorts every image into missing, empty, file name, too long and looks fine.

2. Low contrast on badges, prices and buttons

Contrast is the single most common failure on the web and stores are unusually good at producing it. Sale badges in brand colours on brand backgrounds, grey struck through compare at prices, white text on a pale hero image, disabled looking Add to cart states. WCAG 1.4.3 wants 4.5 to 1 for normal text and 3 to 1 for large text, and 1.4.11 wants 3 to 1 for the parts of a control that tell you it is a control. You can check any pair in our contrast checker before it ships, and a palette matrix will tell you which of your brand colours can sit on which.

3. Inputs labelled by a placeholder

Newsletter signups, discount code fields, contact forms and product option pickers often ship with a placeholder and no label. The placeholder disappears as soon as someone types, and assistive technology treats it as a hint, not a name. Every input needs a programmatically associated label, visible if at all possible.

4. Icon only controls with no accessible name

The cart, the search toggle, the hamburger, the wishlist heart, the close button on a popup. When the only content is an SVG, WCAG 4.1.2 is not satisfied and the control is announced as button with nothing after it. Give it a name, with visually hidden text or an aria-label, and make sure the count next to the cart icon is part of that name rather than a floating number.

5. A missing or wrong page language

One attribute on the html element decides which voice a screen reader uses to read your entire store. Multi market stores get this wrong most often, serving a translated storefront that still declares English.

6. Link text that means nothing alone

Screen reader users pull up a list of links to navigate. A page of Shop now, Read more and View details is unusable that way. Name the destination in the link, or add visually hidden text that does.

The store specific traps that scanners are worse at

The six above are cheap to find. The ones that actually stop a sale usually need a keyboard and ten minutes, and a tester who uses a screen reader every day will have found them even if the letter does not name them.

• Popups and cookie bars. An email capture modal that opens on load and does not move focus into itself, or does not return focus when it closes, strands keyboard users. Worse, a bar pinned to the bottom of the viewport can cover the control a keyboard user just tabbed to, which is what WCAG 2.2 added Focus Not Obscured for.
• Carousels and sliders. Featured collection sliders are usually built for the mouse. Controls need to be real buttons, reachable in order, with a way to stop the movement. The ARIA Authoring Practices carousel pattern is the reference implementation.
• Quick view and variant pickers. A quick view modal is a dialog, and a colour swatch is a control with a state. Both are routinely built from divs, which means a keyboard cannot reach them and a screen reader cannot tell selected from unselected.
• Apps that inject markup. Reviews, upsells, loyalty widgets, chat bubbles and stock counters each add HTML you did not write, on every page, often after load. A store can pass a scan the week before an app is installed and fail on every product page after.
• Infinite scroll on collections. If new products append with no announcement and no keyboard reachable Load more, the rest of the catalogue effectively does not exist for some customers.
• Tiny targets. Quantity steppers, swatch dots and modal close buttons frequently land under the 24 by 24 CSS pixel floor that WCAG 2.2 sets in Target Size (Minimum).

Why the overlay app in the app store is not the answer

Overlay products promise compliance from one script tag, which is why they sell well to merchants, and why a merchant holding a letter reaches for one. They do not work, and the record is now long enough to say so without hedging. An overlay adjusts what the browser renders after your page loads. It does not change the HTML your theme serves, so the failures remain for any scanner, for the screen reader that the widget frequently interferes with, and for the tester writing a complaint. The Overlay Fact Sheet, signed by more than a thousand practitioners, documents the gap between the marketing and the mechanism.

In January 2025 the FTC ordered the largest overlay vendor to pay $1 million over claims that its widget made websites WCAG compliant. Lawsuit trackers have counted overlays on roughly one in four of the sites sued through 2025 and into 2026. Installing one is not neutral either: the widget itself shows up in complaints as a barrier.

The order to do the work in

You do not need a project. You need a sequence that removes the listed failures fastest for the least effort, and leaves a dated trail behind it.

1. Scan the four page types, not the home page. Home, a collection, a product and the cart. Most stores have four templates and thousands of URLs, so four scans cover the catalogue. Start with the scan above.
2. Clear the six common failures. Contrast, alt text, labels, accessible names, page language, link text. This is where the counts drop.
3. Walk the purchase path with a keyboard only. Tab from the home page to a product, pick a variant, add to cart, open the cart, reach checkout. Anything you cannot do is a barrier that no scanner reported.
4. Audit your installed apps. Disable anything you are not actually using. For what remains, re-scan a product page with the app live.
5. Publish an honest accessibility statement. Say what conforms, what does not yet, and give a contact that a real person reads. A statement that claims full compliance while the store fails is worse than none.
6. Re scan after every release. Theme edits, app installs and bulk imports all reintroduce failures. This is the step that keeps the first five from decaying, and the dated history it produces is the evidence for the next letter.

Where this leaves you legally

There is no federal regulation that names a pixel value for private ecommerce in the United States. What exists is the ADA, the Justice Department's guidance pointing at WCAG as the practical measure, and a steady volume of filings against online stores. If you sell into the EU, the European Accessibility Act has applied to ecommerce services since June 2025 and points at the same standard. Nobody can sell you a guarantee against being sued, and any vendor who does is describing a product that does not exist. What you can do is remove the failures a tester would find, keep them removed as the store changes, and keep dated evidence that you did. How that evidence is used in response to a letter is your lawyer's call, not ours.