Most café owners meet web accessibility the same way: a vaguely threatening email arrives claiming your site is out of compliance and offering to fix it for a monthly fee. The email is usually spam. The underlying issue is usually real.
This guide separates the two. It covers which rules actually bind an independent café in Canada and the US, which ones don’t despite what you may have read, and the short list of fixes that account for most real-world failures. It is written for an owner, not a developer — but it will tell you exactly what to hand your developer.
One caveat up front: this is general information, not legal advice. The US position in particular is judge-made and varies by circuit. If you have received a demand letter, talk to a lawyer rather than to a blog.
Why this matters beyond the legal question
Start with the part that isn’t about liability.
Roughly one in five people has a disability. Some of them are your regulars. The person who can’t read your grey-on-white menu prices at 6am, the person who navigates by keyboard because a tremor makes a trackpad unusable, the person whose screen reader hits your checkout and announces “button, button, button” — none of them are edge cases. They are customers who wanted to give you money and couldn’t.
The scale of the problem is not subtle. The WebAIM Million, an annual automated analysis of a million home pages, found in its February 2026 study that 95.9% of home pages had detected WCAG 2 failures, averaging 56.1 errors per page — up 10.1% year over year, reversing what had been a slow improvement. And because those are automatically detectable failures only, 95.9% is a floor, not a ceiling.
The failure types are remarkably consistent, and they’re the same ones on café sites:
| Failure | % of home pages (WebAIM Million 2026) | What it breaks on a café site |
|---|---|---|
| Low contrast text | 83.9% | Menu prices, item descriptions, fine print |
| Missing image alt text | 53.1% | Every photo of the food |
| Missing form input labels | 51% | Checkout, pickup time, special instructions |
| Empty links | 46.3% | Icon-only “cart” and “menu” links |
| Empty buttons | 30.6% | “Add to cart” rendered as a bare icon |
| Missing document language | 13.5% | Screen reader pronounces everything wrong |
That table is basically your to-do list, ranked by how likely you are to have the problem.
What does the law actually require?
Here is where precision matters, because this topic attracts more confident wrongness than almost any other.
The ADA (United States)
The Department of Justice’s position is clear on the whether: “The ADA’s requirements apply to all the goods, services, privileges, or activities offered by public accommodations, including those offered on the web.” And the DOJ’s own examples of Title III public accommodations explicitly include food and drink establishments. So your café is covered, and there is no employee-count exemption from the ADA’s general nondiscrimination duty.
But on the how, the DOJ is equally clear that no technical standard is set by regulation. It “does not have a regulation setting out detailed standards,” and businesses “can currently choose how they will ensure that the programs, services, and goods they provide online are accessible.” It points to WCAG as a helpful reference. Then it closes the loophole people try to drive through: “But they must comply with the ADA’s requirements.”
The canonical case for our industry is Robles v. Domino’s Pizza, decided by the Ninth Circuit in January 2019. A blind customer sued over a website and app he couldn’t use with a screen reader. The court held that Title III covered them because of a nexus to a physical place of public accommodation — the inaccessible site impeded access to the goods and services of Domino’s physical stores. The Supreme Court denied certiorari in October 2019, leaving it standing.
The nexus test is circuit-specific, and courts split on whether a web-only business counts. But note what that means for you specifically: a café with a storefront is the strongest possible case for the nexus theory. The physical shop is right there. Domino’s is the relevant precedent precisely because it looks like you.
One thing to ignore: the DOJ’s 2024 web rule adopting WCAG 2.1 Level AA, with compliance dates in 2027 and 2028. It is the most misreported item in this space. It is a Title II rule — it covers state and local governments, special purpose districts, Amtrak and commuter authorities. It does not apply to a private restaurant. Its only relevance to you is as a signal of where the DOJ thinks the bar sits.
How much litigation is there, really?
Honest answer: nobody knows exactly, because there is no government registry of these filings. Every number you have seen comes from a private tracker.
The most-cited tracker, UsableNet, reports more than 5,000 digital accessibility lawsuits filed in 2025, with food and service businesses making up roughly 21%. Treat those as one vendor’s tracked estimate rather than an official count — figures across UsableNet’s own tracker, midyear report and year-end summary don’t fully reconcile, and the vendor sells accessibility services.
The argument doesn’t need the numbers anyway. The relevant fact is simpler: these suits happen, restaurants are a meaningful share of them, and the fixes below are cheap compared to the correspondence.
Ontario’s AODA
This one has a bright line, and it probably cuts in your favour.
Ontario’s Integrated Accessibility Standards Regulation requires WCAG 2.0 Level AA for websites and web content published after January 1, 2012, with a compliance deadline of January 1, 2021. Live captions and pre-recorded audio descriptions are carved out.
The threshold: it applies to designated public sector organizations and to any business or non-profit with 50 or more employees. If you have fewer than 50, you are exempt from the web standard. Be careful with the word “exempt,” though — it’s scoped to the web requirement. Other AODA duties, like accessible customer service and providing accessible formats on request, still apply to you.
The Accessible Canada Act
Not yours. The ACA applies to federally regulated entities: federal departments and agencies, Crown corporations, the RCMP, the Armed Forces, Parliament, First Nations band councils, and federally regulated private businesses — banks, interprovincial and international transportation, broadcasting and telecom. An independent café is provincially regulated. The jurisdictional test excludes you before headcount ever comes up.
Putting it together
For a small independent café, the accurate composite is this: Ontario’s web standard probably doesn’t bind you. The ADA has no small-business exemption but names no standard. WCAG Level AA is what the DOJ and courts point to in practice. And a customer who can’t order doesn’t check your headcount first.
What is WCAG, in one minute?
WCAG — the Web Content Accessibility Guidelines — is the W3C standard everyone references. WCAG 2.2 is the current Recommendation (published October 2023, updated December 2024) and is also ISO/IEC 40500:2025. It’s a superset: content conforming to 2.2 also conforms to 2.1 and 2.0, so building to 2.2 satisfies AODA’s 2.0 AA requirement automatically. WCAG 3 is an early draft — ignore it for now.
There are three conformance levels — A, AA, AAA. AA is the level every regulator references, and the one to aim at.
The organizing principles are POUR:
- Perceivable — text alternatives for images, content presentable in different ways.
- Operable — all functionality available from a keyboard, enough time, navigable.
- Understandable — readable, predictable, helps users avoid and correct mistakes.
- Robust — works with current and future assistive tools.
That’s the whole conceptual framework. The rest is specifics.
The five fixes that cover most failures
Ranked by return on effort for a café ordering page.
1. Colour contrast. The most common failure on the web by a wide margin. Level AA requires 4.5:1 for normal text and 3:1 for large text, where large means at least 18 point or 14 point bold (roughly 24px and 18.5px). The 4.5:1 figure exists because it accounts for the contrast sensitivity loss of roughly 20/40 vision. In practice: your light-grey secondary text fails, and your white text over a latte photo definitely fails. This is a CSS change, not a rebuild.
2. Alt text on menu photos. Over half of home pages get this wrong. Every meaningful image needs a text alternative that describes it usefully — the same discipline that makes menu photos and descriptions sell more orders applies here, and it is the same sentence doing double duty. Bonus: alt text is read by search crawlers too, so this overlaps directly with getting your ordering page to rank.
3. Form labels in checkout. Half of pages fail this. Placeholder text is not a label — it disappears the moment someone types, and screen readers may not announce it. Every field in the order flow needs a real, programmatically associated label. This is where an accessibility failure costs you money directly: a broken checkout is an abandoned order.
4. Keyboard navigation and visible focus. Unplug your mouse and place a real order. You should reach every control with Tab, always see where you are, and never get stuck. WCAG 2.2 added Focus Not Obscured (2.4.11, Level AA), which is worth knowing because it targets a pattern cafés use constantly: a sticky header or floating cart bar covering the element you just tabbed to.
5. Touch targets. WCAG 2.2’s Target Size (2.5.8, Level AA) sets a minimum of 24 × 24 CSS pixels. But the platform vendors ask for more: Apple’s guidance is a 44 × 44 pt hit region, Android’s is 48 × 48 dp. Use the platform numbers. Hitting 24px is technically conformant and still miserable for someone tapping one-handed while holding a coffee. If you use QR code ordering, this one matters double — everyone is standing up, one-handed, in a hurry.
How to test it yourself, free
You do not need a consultant to find your first twenty problems.
- WAVE — WebAIM’s evaluation tool; online plus browser extensions. The most owner-friendly of the bunch.
- axe DevTools — free browser extension, industry-standard engine.
- Lighthouse — already in Chrome DevTools; runs axe-core under the hood.
- VoiceOver (iOS) / TalkBack (Android) — the real test for your app.
- Xcode Accessibility Inspector — if you have a developer, they should be running this.
The caveat that matters: automated tools catch a subset. Lighthouse’s own documentation is explicit that its score is a weighted average of pass/fail audits, and WebAIM’s 95.9% counts detectable errors only. A perfect Lighthouse score is not compliance and it is not a legal defence.
The test that actually tells you something takes twenty minutes: turn on VoiceOver and order a drink from your own shop with your eyes closed. Every owner who does this finds something. Most find something embarrassing.
What about your app?
If you have a branded ordering app, the same principles apply through platform APIs instead of HTML — labels on controls, sufficient contrast, respecting the user’s Dynamic Type and text-size settings, and hit regions at 44pt on iOS or 48dp on Android.
The practical advice for a café owner is to make it a procurement question rather than a maintenance one. If a vendor is building your app, ask what they test with and whether they run a VoiceOver and TalkBack pass before submission. This sits alongside the other launch questions worth asking early, like who owns the developer accounts and what the privacy disclosures declare. A vendor who has an immediate, specific answer has done this before. A vendor who looks surprised has not.
This is one of the underrated arguments for a properly built platform over a DIY approach: accessibility is not a feature you bolt on at the end, and a good white-label app should ship with it handled — the same way it ships with tokenized payments and store listings handled, at $99 CAD/month per location. But the fixes in this post are yours to verify regardless of who built the thing.
Wrap up
Strip away the legal fog and the picture is simple. Ontario’s web standard likely doesn’t apply to you. The DOJ’s 2024 rule definitely doesn’t. The ADA does, without a technical standard, and WCAG Level AA is what everyone points at in practice.
Meanwhile, the actual failures are boring and fixable: your text is too light, your photos have no alt text, your checkout fields have no labels, and your cart bar covers the focused element. Contrast is a CSS change. Alt text is an afternoon. Labels are a developer ticket.
Do those four, then go order a coffee from your own site with VoiceOver on. That’s the whole audit — and it will do more for the customers you’re currently turning away than any compliance badge ever will.
Sources
- DOJ — Guidance on Web Accessibility and the ADA
- DOJ — Fact Sheet: Title II Web and Mobile App Accessibility Rule (2024)
- Robles v. Domino’s Pizza, LLC, No. 17-55504 (9th Cir. 2019)
- Ontario — How to make websites accessible (AODA / IASR)
- Accessible Canada Act — Summary of the Act
- W3C — WCAG 2 Overview (versions and conformance levels)
- W3C — WCAG 2 at a Glance (POUR)
- W3C — Understanding SC 1.4.3: Contrast (Minimum)
- W3C — Understanding SC 2.5.8: Target Size (Minimum)
- WebAIM Million — 2026 accessibility analysis of one million home pages
- Android — Make apps more accessible (touch target size)
- Apple — Accessibility (Human Interface Guidelines)
- Chrome — Lighthouse accessibility scoring
- UsableNet — 2026 digital accessibility lawsuit trends (vendor-tracked estimates)