Independent study · revised 9 August 2026
Four in five restaurant websites fail an accessibility check anyone can repeat
1,554 restaurant and cafe home pages in Chicago and Toronto, measured with axe-core — the same engine built into Chrome’s developer tools. 79.7% had at least one WCAG 2.1 AA violation.
The point of this report is not the number. It is that you can reproduce it. Every figure below comes from axe-core 4.10.2, an open-source engine published by Deque Systems and used inside Chrome DevTools, Lighthouse and most professional accessibility tooling. Open any of these sites, run axe, and you should see what I saw.
This page previously reported 69.5% and 66.3%. Those figures were produced by my own scanner reading raw HTML, and they were wrong in three specific ways: it could not see pages built with JavaScript, it counted browser certificate-error pages as site content, and it measured cookie banners instead of the pages underneath them.
The method was rebuilt on 8–9 August and the study re-run from scratch. What changed, and by how much, is set out under What changed at the foot of this page.
Headline figures
| Chicago | Toronto | Both | |
|---|---|---|---|
| Websites measured | 819 | 735 | 1,554 |
| At least one violation | 624 (76.2%) | 615 (83.7%) | 1,239 (79.7%) |
| Median rules broken | 2 | 2 | 2 |
| Median failing elements | — | — | 4 |
Toronto scored worse than Chicago, by 7.5 points. I have no explanation for that and will not invent one. In the earlier, weaker version of this study the order was reversed — which is itself a reason to treat any city-to-city comparison here with caution. The finding I would stand behind is the one that held under both methods: the large majority of these sites fail, in both countries.
How bad, per site
| Rules broken | Websites | Share |
|---|---|---|
| None | 315 | 20.3% |
| 1 | 373 | 24.0% |
| 2–3 | 622 | 40.0% |
| 4–6 | 225 | 14.5% |
| 7 or more | 19 | 1.2% |
One site in five is clean by this measure. That is worth saying plainly, because a report claiming everything is broken deserves suspicion.
Which barriers occur most often
| Rule | What it means | Sites |
|---|---|---|
link-name | A link with no text a screen reader can announce — usually an icon or an image with no alternative text | 47.2% |
color-contrast | Text too close in brightness to its background to be read reliably | 46.4% |
image-alt | An image with no alternative text | 16.5% |
meta-viewport | Zoom disabled on phones | 14.6% |
frame-title | An embedded frame — a map, a menu, an ordering widget — with no title | 10.8% |
button-name | A button with no accessible name | 6.0% |
html-has-lang | The page does not declare its language | 5.2% |
role-img-alt | An element marked as an image with no alternative text | 5.0% |
nested-interactive | A control inside another control, which traps keyboard users | 5.0% |
label | A form field with no label | 4.1% |
The most common barrier is not the one the industry talks about. Missing image descriptions get the attention; empty links are three times as common. An empty link is typically a social-media icon, a phone-number icon, or a logo linking home — and to a screen reader it announces as nothing at all, or as the raw URL.
By platform
| Platform | Sites | With violations | Median rules |
|---|---|---|---|
| Weebly | 47 | 100% | 3 |
| GoDaddy | 53 | 98.1% | 4 |
| Webflow | 21 | 90.5% | 2 |
| WordPress | 527 | 88.6% | 2 |
| Custom or other | 361 | 82.0% | 2 |
| Shopify | 23 | 78.3% | 2 |
| Squarespace | 280 | 74.3% | 1 |
| Wix | 116 | 57.8% | 1 |
| Restaurant-specific platforms | 121 | 51.2% | 1 |
Read this table carefully, and do not read it as a ranking of vendors. Most of what axe finds comes from the theme and the content a business or its agency added — images uploaded without descriptions, icon links left unlabelled, colours chosen for looks. A platform can make good defaults easy or hard, but almost none of these failures are the platform emitting broken code on its own.
The small samples deserve particular caution: 21 Webflow sites and 23 Shopify sites cannot support a claim about either product.
How this compares to the WebAIM Million
The reference study in this field is the WebAIM Million, which examines the home pages of the top one million websites each year. It uses WebAIM’s own engine, not axe, so the two are not measuring identically — but the largest overlapping rule is a useful sanity check.
| Barrier | WebAIM Million | This study |
|---|---|---|
| Empty links | 46.3% | 47.2% |
| Low contrast | 83.9% | 46.4% |
| Missing alternative text | 53.1% | 16.5% |
| Missing document language | 13.5% | 5.2% |
| Missing form labels | 48.2% | 4.1% |
Empty links land within one point of each other — 46.3% against 47.2%, on a completely different sample, with different software, measured independently. That is the strongest evidence here that the method is sound.
The other four diverge sharply. I sent these figures to WebAIM and Jared Smith, Associate Director of WebAIM, replied with four explanations that are better than the guess I had written here:
- Pages in Chicago and Toronto are likely more accessible than the average of the million-page sample — .ca pages are among the best in it.
- Restaurant pages being simpler than pages in general may contribute — though in the WebAIM sample, Food & Drink sites fared slightly worse than average.
- US restaurant websites are often targeted by serial litigants over inaccessibility, so they may be better prepared than comparable sites elsewhere.
- WAVE tests hidden content; axe-core generally ignores it. Restaurant pages often put contact or order forms inside user-triggered dialogs, and problems inside those may not be detected by axe.
The fourth point applies directly to my method, so I tested it: see the overlay trade-off below. He is right that removal hides some forms, but the effect is small and runs against a much larger one in the opposite direction.
One thing I can add from my own data: 70.7% of these restaurant home pages have no form fields at all. That is the main driver of the 4.1% figure — it is largely a denominator effect, not a detection gap. Whether it explains the whole difference I cannot say, because I do not know what share of the WebAIM sample has forms.
Treat those four rows as a caution about comparing studies, not as a finding.
Method
Engine. axe-core 4.10.2 by Deque Systems, restricted to rules tagged wcag2a, wcag2aa, wcag21a and wcag21aa. Nothing here is my own rule set. Anyone can install axe and check any of it.
Rendering. Each page was opened in a real browser and given time to run its JavaScript before being measured. This matters more than it sounds: sites built with React, Vue or Angular return an almost empty document to a plain HTTP request. An earlier version of this study read raw HTML and consequently recorded 202 working restaurant websites as blank pages.
Overlays. On 24.8% of sites a cookie banner or modal dialog was covering the page. While such a dialog is open the browser correctly marks everything behind it as unavailable to a screen reader, so measuring without dismissing it would measure the banner. Overlays were therefore removed locally, inside my own browser. No consent was given, no button was clicked, and nothing was sent to any site.
What that removal costs, measured. Jared Smith of WebAIM pointed out that restaurant sites often put forms inside user-triggered dialogs, so removing the dialog might hide them. I tested it: 34 sites that definitely had a modal, measured twice, same day, with removal and without.
| Overlays removed | Overlays left in place | |
|---|---|---|
| Sites with any form field | 10 | 12 |
| Form fields with no accessible name | 11 | 11 |
| Images with no alternative text | 301 | 162 |
| Links with no accessible name | 133 | 85 |
| Total violations found | 460 | 275 |
He is right that removal hides forms: on 2 of the 34 sites (6%) form fields appear only when the overlay is left in place. But the count of unlabelled fields was identical either way, and leaving overlays in place loses 185 violations, about 40% of everything found. Removal costs roughly 6% of forms and recovers roughly 40% of violations. That is the trade-off, stated rather than hidden.
What was counted. Only violations axe reports with certainty. axe places cases it cannot resolve in a separate category, which is not counted here — 92.9% of sites had at least one such case, 1.3 on average. The 79.7% figure is therefore a floor, not a ceiling.
Access. Only the publicly served home page of each site, the same document any visitor receives. No login, no bypassing of any protection. Each domain’s robots.txt was respected and 24 sites were skipped because it forbade access.
Source of the site list. OpenStreetMap, under the ODbL licence.
Exclusions
Of 1,950 domains that returned something, 351 were excluded because what they returned was not a working restaurant website. Every exclusion has a recorded reason:
| Reason | Domains |
|---|---|
| Redirects to an unrelated domain — the address no longer belongs to the business | 132 |
| Practically empty after rendering | 99 |
| Navigation failure, mostly invalid TLS certificates | 94 |
| The browser’s own error page, not site content | 12 |
| Registrar parking page | 9 |
| HTTP 403 or 500 | 5 |
Several of those domains now serve gambling or adult content in languages unrelated to either city. Leaving them in would have reported a closed restaurant as a restaurant with a hundred accessibility failures.
That leaves 1,599 working websites. On a further 45 of them axe could not complete — a technical failure of my pipeline, not a property of those sites. They are excluded from the figures and counted here so the arithmetic closes: 1,950 − 351 − 45 = 1,554.
Known limits
Home pages only. Menus, booking flows and ordering pages were not examined. That is where the barriers that cost a business money usually are.
Desktop viewport only. Measured at 1280×900. Mobile layouts can differ.
One moment in time. Measured on 9 August 2026. One domain in this study served an online casino on 7 August and a restaurant menu on 8 August. These findings expire in days.
Automated testing reaches perhaps a third of WCAG. Keyboard traps, focus order, whether alternative text is actually meaningful, whether an error message makes sense — none of it can be judged by a machine. This is a scan, not an audit, and no scan can tell you a site is accessible.
Two engines, side by side
Before switching to axe I measured every site with my own checker, built on the browser’s accessibility tree. Both sets of numbers were kept:
| Engine | Sites with violations |
|---|---|
| My own checker | 85.4% |
| axe-core (Deque) | 79.7% |
The two agree on whether a site has any violation for 80.8% of sites. Where they disagree, mine is usually the stricter of the two. I publish the axe figure, because it is the one you can check, and because a number you cannot verify is worth nothing.
What changed on 9 August
| Previous version | This version | |
|---|---|---|
| Headline | 69.5% / 66.3% | 79.7% |
| Engine | my own, reading raw HTML | axe-core 4.10.2 |
| JavaScript | not executed | rendered in a browser |
| Cookie banners | measured as page content | removed before measuring |
| Excluded as not a working site | 78 | 351 |
| Lost to my own tooling failing | not recorded | 45 |
The earlier figures were not fabricated — they were what that method produced. They were also too low, because the method was blind to a substantial part of what it was looking at. Corrections to this page are published here with the date, and the previous numbers are left visible rather than quietly replaced.
Important note
A violation detected by a tool is a technical finding, not a legal one. This study does not assert that any site violates any law, and no business is named anywhere in it.
Who did this
My name is Arkadiusz Sorelli and I work from Poland. I collected the site list, built the pipeline that renders each page and decides whether it is a working website at all, and ran axe across it. There is no company behind this and no client paid for it.
I am not an accessibility consultant and I do not sell remediation.
Want to see the data before you ask me anything?
Name a segment or an area — “cafes in Scarborough”, “restaurants in the Loop” — and I will send you the 25 worst-scoring sites in it: the address, which axe rules each one breaks, and how many elements are affected. Free, no conditions, no sales call. Two sentences in an email is enough.
The list is derived from OpenStreetMap and is passed on under the same ODbL licence it came with. It is not sold to firms that bring accessibility claims against businesses — that rule is not negotiable and predates this report.
If you find an error in these figures, I want to hear about it: contact@provenaccess.com. Corrections will be published on this page with the date.