Can an ADA demand letter target your Shopify checkout?
Yes, and checkout claims are among the most dangerous kind. A demand letter that cites the homepage can be answered with a remediation plan. A letter that documents a keyboard or screen-reader user unable to complete a purchase strikes at the store's core function, and it is much harder to argue that the barrier was minor. Checkout is where accessibility failures convert directly into lost sales, which is exactly the framing a demand letter wants.
Why checkout gets targeted
Plaintiff firms test the full user journey, and the journey ends at checkout. A store can have a perfect homepage and still fail the test that matters: can a person using assistive technology actually buy something. Checkout involves the most complex interactions on the site, forms, payment widgets, error handling, order review, which means it has the most surface area for failure.
There is also a strategic reason. A barrier on a blog post is an inconvenience. A barrier at checkout is exclusion from the transaction itself, which reads as more serious to everyone involved: the sender, the recipient, and any court that might see it. Demand letters lead with their strongest examples, and checkout failures are usually the strongest examples available.
The checkout failures that get cited
Unlabeled form fields are the most common. Checkout forms with placeholder-only inputs, address fields with no programmatic labels, and payment fields inside iframes that expose no names to assistive technology. A screen-reader user tabs through checkout hearing "edit box, edit box, edit box" with no idea which is the card number.
Error handling is the second. Forms that show errors only in red text, without moving focus to the error or announcing it, leave keyboard users submitting repeatedly with no idea what went wrong. Error summaries need to be announced and focus needs to move to the problem field.
Payment widgets are the third. Third-party payment buttons and express checkout options are often the least accessible part of the flow: injected iframes with poor keyboard support and no announcements. The store owner did not build them and cannot easily fix them, which makes them a frustrating finding, but they are still part of your checkout.
Order review and confirmation are the fourth. If the final review step cannot be read by a screen reader, or the confirmation page gives no accessible confirmation of what was ordered, the transaction is complete but unverifiable for the user. That is a clean, documentable failure.
What to check before a letter arrives
Run the checkout with a keyboard only, end to end, including a test purchase. Every field needs a visible label and a programmatic one. Submit the form with errors and confirm the errors are announced and focus moves. Test with a screen reader if you can: the payment step especially, since that is where third-party widgets live.
Document the test. A dated record showing that checkout was tested with assistive technology and what was found is evidence of good faith. It does not make a store immune, but it changes the conversation from neglect to diligence, which is the difference that matters in early negotiations.
The response if checkout is cited
If a demand letter names specific checkout barriers, verify each one promptly and fix what you can immediately. Unlabeled fields and error handling are usually quick fixes. Payment widget issues may need escalation to the provider, and you should open that ticket the same day: "waiting on our vendor" is a better position than silence, but only if the ticket is real and documented.
Do not rebuild checkout from scratch in a panic. Targeted fixes to the cited barriers, tested and documented, resolve most checkout claims. The goal is a checkout that a keyboard or screen-reader user can complete, evidenced by a test, not a perfect checkout. Perfect is the enemy of the documented, tested, and fixed.