Coffee Shop Ordering Apps and ADA Risk: What Owners Should Check

Your café’s mobile-ordering app is covered by the Americans with Disabilities Act — not as a “place” in its own right, but as a channel through which your shop, which is a place of public accommodation, serves its customers. That is the holding a federal appeals court reached in Robles v. Domino’s, and the Supreme Court declined to revisit it. The practical result: your app is a front door, it is open 24 hours a day, and it almost certainly has problems nobody on your team has noticed.

This article covers why that liability exists, what the public record does and does not tell us about enforcement, and seven specific failures you can check yourself in ten minutes with the phone in your pocket. No developer, no budget, no jargon. If you would rather start with the desktop site, the restaurant website accessibility guide covers menus, ordering pages, and reservation widgets.

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. We should be clear about our own vantage point here: we do not have access to a demand-letter corpus, and we are not going to characterize how many cafés are receiving letters or in which states. The public record is enough on its own — Robles is binding law in the Ninth Circuit and persuasive elsewhere, and the theory it endorses is that an ordering app is a channel of a physical place of public accommodation. If your app is that channel and a blind customer cannot complete an order in it, the legal theory that reached the Ninth Circuit applies to you on its face.

We are also not going to quote you a settlement range. Figures circulate widely in accessibility marketing and we have not been able to trace them to a published dataset, so any number we printed would be someone else’s guess with our name on it. For the filing statistics that are published and sourced, see what an ADA lawsuit actually costs. (Nothing here is legal advice.)

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. US Census American Community Survey data puts the number of Americans with a visual disability in the millions, and a much larger group has enough age-related vision loss to rely on the magnification and screen-reader settings already built into 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 that recur on café apps

These are the specific defects that recur in 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. That is the same “channel to the physical place” logic the Ninth Circuit accepted in Robles, applied to your location page rather than your ordering flow.

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.

Want to know what is actually broken on your site? Get an accessibility report.