Independent accessibility research
Which sites fail accessibility — and the exact code that fails.
I scan business websites with axe-core — the same engine inside Chrome’s developer tools — and document every violation it reports, with the element that causes it. Two cities studied so far. Every figure is published, and so is what the method cannot see.
Read the studyHow the results were verified
Measuring 1,554 sites is the easy half. The hard half is knowing which of the resulting numbers are real. Five independent checks were written for that, and none of them reuse the scanner’s own code — checking your own work with the same logic repeats the bug instead of catching it.
| Check | What it found |
|---|---|
| Cross-check against axe-core | On 1,554 sites measured by both engines, the verdicts agreed 80.8% of the time: 109 sites were caught only by axe-core, 23 only by my own checker. Where they disagreed, axe’s number was published. |
| Reliability test | Written from scratch without the scanner’s code, testing for false negatives as well as false positives — an understated figure is no more honest than an inflated one. |
| Source identity | 6 domains out of 1,133 had lapsed and been re-registered by third parties. Each would have been reported as a failing restaurant while actually serving something else entirely. |
| Extreme values | The highest-scoring pages re-counted by separate code, because one category dominating the extremes usually means a detector fault rather than a real finding. |
| Injected content | Sites carrying hidden spam were excluded rather than counted as accessibility failures. Two independent signals required before flagging, so that no owner is told they were breached when they were not. |
Three classes of false result were found and corrected this way. The worst: 12 sites that returned a block page instead of a website — title “Access Denied”, 52 to 265 characters of text — recorded as the restaurant’s content and reported as successful measurements. Eleven of the twelve returned HTTP 200. Checking the status code alone would have caught none of them. Nothing now enters the statistics without an HTTP status, a final URL and an explicit verdict.
| Redirected to another domain | 132 · 37.6% | |
|---|---|---|
| Effectively empty page | 99 · 28.2% | |
| Navigation failure | 94 · 26.8% | |
| Browser error page | 12 · 3.4% | |
| Parked domain | 9 · 2.6% | |
| HTTP 403 / 500 | 5 · 1.4% |
What this is not
This is not an audit. Automated testing reaches perhaps a third of WCAG 2.1 AA. Keyboard traps, focus order, whether alternative text actually says anything useful, whether an error message makes sense — none of it can be judged by a machine, and axe cannot judge it either.
Every figure I publish is therefore a lower bound. axe itself flags cases it cannot resolve rather than guessing; on 92.9% of the sites I measured there was at least one. If you need a full audit, hire someone who does full audits. I will tell you honestly when that is what you need.
Who runs this
My name is Arkadiusz Sorelli and I work from Poland. I collected the site lists, built the pipeline that renders each page and decides whether it is a working website at all, and ran axe across it.
The measurements are not mine to be trusted on. The rules engine is axe-core by Deque, not something I wrote — so anyone can check my figures with the tool they already use. Where my own checker disagreed with axe, I published axe’s number, not mine.
That is deliberate, and running axe is not the hard part. On one page it takes ten seconds, and you should do it yourself. The work is everything around it, and it only shows up at scale: deciding which of 1,950 domains is a working business website at all — 351 were not, and 132 of those now point somewhere else entirely. Rendering pages that hand a plain request an empty document. Clearing the cookie banner that hides the page from the tool on a quarter of sites. Knowing which businesses to check in the first place.
axe is the last step and the easiest one. If you need it done across three hundred sites instead of one, and the answer to be worth something when it comes back, that is the part I do.
I also publish what went wrong. The current study excludes 351 domains that no longer serve a working restaurant website, each with a recorded reason, and a further 45 where my own pipeline failed. An earlier version of the study reported figures that were too low; the correction is on the report page, with the previous numbers left visible.
What I do
I measure accessibility across large numbers of websites at once — a franchise network, a hotel group, a university’s department sites, a public body’s separate domains, an agency’s client portfolio. You get one list: every site you own, ordered worst to best, with the specific failures on each and the element that causes them.
Running axe on one site is not the work. It takes ten seconds and you should do it yourself. The work only appears at scale, and it is the difference between a number and a number worth having: 351 of 1,950 domains in the last study were not a working website at all, a quarter of sites hid their content behind a cookie banner, and twelve returned a block page while reporting HTTP 200. Point a free tool at three hundred addresses and you get a report that looks complete and is not.
| Scope | Price | Delivery |
|---|---|---|
| Up to 25 sites | $900 | 5 working days |
| 26 to 150 sites | $2,400 | 10 working days |
| 151 to 500 sites | $4,800 | 15 working days |
| Over 500 sites | quoted | agreed in advance |
Every run carries the verification layer described above: excluded addresses keep a recorded reason, block pages are caught rather than counted as content, and domains that have lapsed and been re-registered are removed before they are reported as yours. You receive the raw data as well as the report, so any figure can be checked against the record.
What this is not. This is measurement, not a conformance audit, and no result here is a compliance certificate. Automated testing reaches perhaps a third of WCAG 2.1 AA, so every figure is a lower bound. Where a single site needs a full manual audit, that is different work and I will say so.
The method is open — three repositories:
- skaner-dostepnosci — the scanner itself and the five independent verification tests.
- skaner-playwright — the same measurement reimplemented in Python and Playwright, with both results compared. Verdict agreement: 100%.
- analiza-dostepnosci-sql — SQL analysis reconciling the published figures to the record.
The rules engine is axe-core by Deque, not something I wrote, so you can repeat any figure with the tool you already use.
Ta strona po polsku — informacje dla polskich firm
Get in touch
Email is the fastest way to reach me and the way I prefer. If you want to talk about the method, the code, or a role, write and I will reply.
Or write directly: contact@provenaccess.com