Your Coffee Shop Mobile Ordering App Is the Next ADA Lawsuit Target — Here's Why

If you run a coffee shop, a café, or a third-wave specialty roaster, your mobile-ordering app is now your highest-revenue customer interaction. It is also, according to a federal appeals court that the Supreme Court declined to revisit, a place of public accommodation under the Americans with Disabilities Act. That makes it a legal liability the same way an inaccessible front door is — except your app is open 24 hours a day, used by hundreds of customers a week, and almost certainly has problems nobody on your team has noticed.

This article walks through, in plain English, why that liability exists, what plaintiffs’ attorneys are actually filing against cafés right now, and the seven specific failures you can check yourself in an hour with nothing but the phone in your pocket.

The Robles v. Domino’s decision is about your café, not just pizza

In 2019 a blind plaintiff named Guillermo Robles sued Domino’s Pizza because he could not order a pizza through the Domino’s website or mobile app using a screen reader. Domino’s argued that the ADA applies only to physical buildings, not to apps. The Ninth Circuit Court of Appeals disagreed. They held that the ADA applies to the mobile app and the website because both are channels through which the Domino’s stores — which are concededly places of public accommodation — connect with their customers. The Supreme Court declined to hear the appeal in October 2019, leaving the Ninth Circuit decision in place.

Robles is not a pizza decision. It is a quick-service-food decision. Every coffee shop with a mobile-ordering app is in the same legal posture as Domino’s was in 2019, and the plaintiffs’ bar knows it. Since 2024 we have seen a steady stream of demand letters against independent cafés and small chains in California, New York, Florida, and Pennsylvania, with the underlying complaint almost always the same: the blind plaintiff downloaded the app, tried to order, and could not complete a transaction independently.

Settlements typically run between $5,000 and $25,000 for an independent café, plus remediation costs, plus attorneys’ fees, plus a multi-year monitoring obligation. For a chain of three or four locations, the range is $25,000 to $100,000. The defense costs alone — even on a case that ultimately settles — usually exceed $15,000.

The frustrating part for café owners is that almost none of these defects come from the café itself. They come from the off-the-shelf mobile-ordering platform — Toast, Square, Clover, Olo, Bbot, Square for Restaurants, Heartland Restaurant, or one of the dozen-odd specialty café-platform vendors. The café signed the platform contract, configured the menu, and turned it on. The platform vendor wrote the code that fails screen-reader testing. But the café, not the vendor, is the named defendant on the demand letter.

Test your own app in ten minutes — no developer required

You do not need any technical training to do a basic accessibility check on your café’s mobile app. The phone in your pocket already has the tools built in. Here is the procedure.

If you have an iPhone: Open the Settings app, go to Accessibility, then VoiceOver. Turn VoiceOver on. Your screen now reads everything aloud as you touch it. Open your café’s app and try to place an order using only spoken feedback — do not look at the screen. To turn VoiceOver off, press the side button three times (or whatever shortcut you set).

If you have an Android phone: Open Settings, go to Accessibility, then TalkBack. Turn TalkBack on. Open your café’s app and try to place an order with TalkBack reading the screen aloud. The gesture pattern is different from iPhone — swipe right to advance, double-tap to activate — but the test is the same.

If you cannot complete the order — if buttons read out as “button” with no description, if size selections do not announce, if your loyalty balance is silent, if checkout traps you on a screen with no clear way forward — your customers with vision loss cannot complete the order either. They are not edge cases. The CDC estimates 7 million U.S. adults are blind or have serious vision impairment, and a much larger group has enough vision loss to rely on screen-reader settings on their phone.

Run through your most common order: large oat-milk latte, blueberry muffin, pickup in ten minutes. If you cannot do it with the screen reader on, neither can a real customer.

The seven failures we see on almost every café app

These are the specific defects that come up in nearly every audit we do of café and roaster mobile apps. Pull yours up while you read.

1. Menu-item buttons that read as “button” with no description

Tap a menu item with VoiceOver running. You should hear the item name, the price, and ideally the size or default customization. (“Oat milk vanilla latte, twelve ounces, five dollars seventy-five.”) If you hear “button” or silence, the developer never attached an accessibility label to the menu-item card. Every customer with vision loss is now ordering by trial and error.

This is one of the easier defects to fix on the developer side, but only the developer can fix it. Take screenshots, file a support ticket with your platform vendor, and ask specifically for “menu-item accessibility labels conforming to WCAG 2.1 AA.” Save the support-ticket reply — that documentation is the single best evidence you have in a demand-letter response if the vendor refuses or delays.

2. Size, milk, and syrup customization that uses horizontal-scroll carousels

The customization screen is the second-highest-failure surface. The standard pattern is a horizontal-scroll row of pills — “Small / Medium / Large” or “Whole / Oat / Almond / Soy / Coconut” — that screen readers either skip entirely or read in the wrong order. A blind customer can tap an option but cannot tell which one is selected, cannot tell what the price difference is, and cannot reliably proceed.

The fix is to replace carousels with native radio-button controls or a properly-labeled picker. Again, this is a platform-vendor change, not a café change. But you can document the problem and demand a fix.

3. Add-to-cart and checkout buttons that report no role to screen readers

Tap your add-to-cart button. VoiceOver should announce “Add to cart, button” or similar. If it says nothing, or says only “Add to cart” with no indication that it is interactive, the button was implemented as a generic view rather than as an actual button. The customer cannot reliably activate it.

Same fix path: screenshot, ticket, document the response.

4. Loyalty-rewards balance shown only as a graphic

Open the loyalty or rewards screen. With VoiceOver on, does it read your current point balance and the next reward threshold aloud? On most café apps it does not — the balance is rendered as a styled image with no accessible text equivalent, and the next-reward badge is a decorative graphic. A blind regular has no way to know how close they are to a free drink, what tier they are at, or how many more visits unlock the next perk.

The remediation is to render the balance as plain text that screen readers can read, with the visual styling layered on top. This is a one-day developer change, and it dramatically improves the everyday experience for the customer most likely to be a high-LTV regular.

5. Apple Pay and Google Pay flows that lose focus after the fingerprint scan

This one is subtle. When the customer taps “Pay with Apple Pay,” the phone shows the fingerprint or Face ID screen, accepts the biometric, and then returns to the app. On a well-built app, focus moves to the order-confirmation screen and VoiceOver announces “Order confirmed.” On a poorly-built app, focus disappears entirely — the screen reader goes silent, the customer does not know whether the order went through, and they end up tapping randomly until something speaks again.

You can reproduce this in two minutes with VoiceOver on. If you can, your customers with vision loss are panicking after every order.

6. Subscription enrollment that uses swipeable card stacks

If you sell a subscription coffee plan, the enrollment flow is almost certainly the worst page in the entire app from an accessibility standpoint. The frequency picker is often a card grid with no labels. The flavor-profile quiz is often a Tinder-style swipeable card stack that screen readers cannot operate at all.

The Federal Trade Commission’s 2024 Negative Option Rule also requires that subscription-cancel be no harder than subscription-enroll. If your enrollment is inaccessible, your cancel-flow probably is too, which is a separate federal violation on top of the ADA exposure.

7. “Visit Us” page that hides hours, address, and accessibility info in images

This is not exactly a mobile-app failure — it is a website failure — but it costs cafés just as many customers. The “Visit Us” page is often the most-visited page on the entire café website, and it is also often the worst. Hours are rendered as a photograph of the printed door sign. The address is a styled card with no plain text. The wheelchair-access disclosure, the outdoor-seating availability, and the dog-friendly status are small icons with no alt text.

A wheelchair-using customer trying to confirm step-free entry before driving twenty minutes to your café has no reliable way to do so. Several recent demand letters specifically allege that an inaccessible “Visit Us” page constructively excluded the plaintiff from the physical store before they ever arrived.

This one you can fix yourself. Open your website’s “Visit Us” page in your CMS. Replace every image of text with actual typed text. Add a plain-text accessibility section: “Step-free entry from the sidewalk. One accessible restroom on the ground floor. Two outdoor tables with no step. Service dogs welcome.” Five minutes of typing, no developer required, removes one of the most common claim theories.

What to do this week if you are an independent café owner

You do not need to fix everything at once. Here is a realistic 30-day plan.

Week 1: Document. Run the VoiceOver test described above. Take screenshots of every place where the app or website fails to read aloud or fails to behave like a button. Save them in a folder. This is your evidence file.

Week 2: Vendor pressure. Open a support ticket with your mobile-ordering platform vendor — Toast, Square, Clover, Olo, whoever — and ask for their current VPAT, also known as an Accessibility Conformance Report. Every reputable vendor has one. If yours cannot produce one, that is your signal to start evaluating a switch. Document the request and the response.

Week 3: The fixes you control. Update your “Visit Us” page to plain text. Add a clearly visible phone number near the start of the page with a note: “If you have trouble ordering on the app or website, call us at [number] and we will take your order over the phone.” Make sure someone is actually answering that phone during business hours.

Week 4: Statement and policy. Publish a brief accessibility statement on your website that names your ordering platform, acknowledges the work in progress, and tells customers how to contact you about accessibility concerns. This is not a magic shield against lawsuits, but it demonstrably reduces demand-letter volume because plaintiffs’ firms screen for sites with no statement before sites with a statement.

The 30-day plan does not make your app perfect. It does dramatically reduce the size of the bullseye on your back, and it gives you a defensible position if a demand letter does arrive: documented vendor pressure, fixes within your control, and a clear customer-service path.

What this is really about

The reason every café owner should care about this is not the legal exposure. The legal exposure is real, but the reason to care is that the customer who cannot use your app is, almost by definition, the regular you most want to keep — a daily user, comfortable with your menu, brand-loyal, ordering the same drink at the same time every weekday. Mobile ordering exists to make that customer’s life easier. If your app makes it harder, you are quietly losing the customer you most need.

The same is true for every accessibility issue. The cost of a fix is small. The cost of doing nothing is a customer who quietly stops coming.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.