The accessibility watch: the law changed in 2025, your website did not
A weekly scan of your own site against the EU accessibility rules, on a box you already own, for EUR 0
Setup: An afternoon (~2-4 h)
Running cost: $0-6/mo (software included)
Time saved: none directly — it buys evidence, not hours: the European Accessibility Act (Directive (EU) 2019/882) has been applicable since 28/06/2025 with EN 301 549 / WCAG 2.1 AA as the reference standard, and the vendors selling the same automated monitoring publish USD 990-10,990/year (UserWay) while Siteimprove quotes privately from around USD 10,000/year on buyer-reported figures; the automated layer itself covers about 57% of WCAG issues on Deque's own measurement and 30-40% on more conservative independent guidance, so the remaining half stays a human job either way
After setup: Runs unattended — scans weekly on its own; you only read the diff, and only when something changed
Data lives: Your server — The scan runs against your public pages from your own box, and every report stays in a local folder. The optional plain-language step uses a model on the same machine, so no page markup leaves the building.
Built for small businesses in general — not a sector list.
Before you start
- A sitemap.xml that actually lists the pages customers use, otherwise the scan covers whatever someone remembered to type in a list
- Any always-on machine with Node and the system libraries headless Chrome needs; a mini-VPS at EUR 4-6/month if you have none
- Someone who can change the site once findings arrive, whether that is you, an agency or a web person on retainer
- A decision, written down and dated, on whether the microenterprise exemption applies to your business
What breaks first FAILS SILENTLY
the consent banner: it covers the page, the scanner tests the banner instead of the site, and the violation count drops. A falling number reads as progress, which is exactly why this one is dangerous. Assert on every run that the number of pages scanned matches the number of URLs in the sitemap, and fail loudly when it does not.
Version history
v1.0 · 2026-09-03 — First release. Built on pa11y-ci with the axe-core runner, sitemap mode, a baseline-then-ratchet threshold, and a dated reports folder as the evidence trail.
Since 28 June 2025 an accessible website is a legal requirement for a lot of European businesses, not a nice-to-have. This is the weekly check that tells you where you stand, runs on a box you already own, and costs EUR 0.
The architecture
the same flow as text
[ yoursite.example/sitemap.xml ] the pages you already publish
│ once a week, overnight, one cron line
▼
[ pa11y-ci — headless Chrome + the axe-core rule engine ]
├─ standard: WCAG2AA · runner: axe
├─ per-page threshold = last week's count (the ratchet)
└─ output: --json → reports/2026-09-03.json
▼
[ 30-line diff script ] this week vs last week, per page
▼
[ local model (Ollama) ] one plain sentence per violation: what, where, why it matters
▼
[ Telegram or email ] + [ reports/ folder = your dated evidence trail ]
│ once a week, overnight, one cron line
▼
[ pa11y-ci — headless Chrome + the axe-core rule engine ]
├─ standard: WCAG2AA · runner: axe
├─ per-page threshold = last week's count (the ratchet)
└─ output: --json → reports/2026-09-03.json
▼
[ 30-line diff script ] this week vs last week, per page
▼
[ local model (Ollama) ] one plain sentence per violation: what, where, why it matters
▼
[ Telegram or email ] + [ reports/ folder = your dated evidence trail ]
The whole thing is one scheduled command and one small script. There is no server to expose, no login page, nothing on the public internet. The reports folder is the part that matters most and gets the least attention: a dated JSON file per week is the difference between "we take accessibility seriously" and a record that survives being asked to prove it.
The problem
The European Accessibility Act (Directive (EU) 2019/882) became applicable on 28 June 2025. It puts accessibility obligations on private companies for the first time, and e-commerce is explicitly one of the covered services. The reference standard is EN 301 549, which points at WCAG 2.1 level AA. Two things follow from that, and most owners know neither. First: if you employ fewer than 10 people and your turnover or balance sheet total stays under EUR 2 million, the service exemption applies to you — but it is not a grace period. Cross either threshold and the exemption is gone the same day. Second: nobody sends you a warning letter that says "your menu cannot be reached with a keyboard". You find out from a market-surveillance authority, a complaint, or a customer who cannot check out. And the moment you do get asked, the question is not "is your site perfect" — it is "show me what you checked, and when". Most small businesses have nothing to show. That is the gap this blueprint closes: a dated, repeatable record of what your own site does and does not pass, produced automatically, every week, without a subscription.
Tool choices — and why
pa11y-ci
(LGPL-3.0, 629 stars, last commit 29/08/2026) is the runner. Point it at your
sitemap.xml with pa11y-ci --sitemap https://yoursite.example/sitemap.xml and it loads every page in a headless Chrome, tests it, and exits non-zero when any page is over its allowance. Sitemap mode is the low-maintenance choice: a page you publish tomorrow is scanned next week without anybody editing a list. Its sibling pa11y (LGPL-3.0, 4,500 stars, last commit 28/08/2026) is the single-page version — useful while you are actually fixing something.axe-core
(MPL-2.0, 7,468 stars, last commit 01/09/2026) is the rule engine, maintained by Deque, an accessibility vendor. Set
"runners": ["axe"] in your config and use it instead of pa11y's default engine. Two reasons: the findings are conservative, so what it reports is almost always real and fixable, and it is the same engine as the free axe DevTools browser extension — so anything the weekly scan flags, you or your web person can reproduce in a browser with one click. Deque's own measurement puts automated coverage at about 57% of WCAG issues; independent guidance is more conservative and usually says 30-40%. Take the low number as your planning assumption. Either way, half the work is not automatable, and any tool that tells you otherwise is selling something.Ollama
(MIT, 180k stars, active) runs a small model on your own machine to turn each raw violation into one sentence a non-developer can act on. "Serious violation: colour-contrast — the grey price text on your product pages is too light against white, WCAG 1.4.3" beats a CSS selector and a rule ID. This step is optional and it is the only part with a model in it. Keep it local: the input is your own page markup, and there is no reason to ship that to anyone.
pa11y-dashboard
(GPL-3.0, 1,089 stars, last commit 25/03/2026) is the optional trend view — charts of violations per URL over time. Honest caveat: it needs MongoDB and is less actively developed than the CLI tools. Skip it on day one. A folder of dated JSON files and a diff already answers "are we getting better or worse", which is the only question the chart was going to answer.
Monthly cost
Software: EUR 0, all of it. Hardware: EUR 0 if you have any always-on machine — the scan runs for a few minutes a week. A mini-VPS is EUR 4-6/month if you do not. For comparison, the published prices on the other side: UserWay's widget starts at USD 49/month and its scanning and monitoring service runs USD 990-10,990/year; Siteimprove does not publish pricing at all and buyer-reported figures for the accessibility module start around USD 10,000/year. Those are the vendors' own numbers, not my estimates.
Setup outline
- Check whether the exemption applies to you: fewer than 10 people and turnover or balance sheet total not above EUR 2 million, for services. Write the answer down with today's date. If you are close to either line, build this anyway — the exemption ends the day you cross it, with no transition.
- On any always-on box, install Node and
pa11y-ciglobally. On a Linux box you also need the system libraries headless Chrome wants; the project README lists them, and thebuildkite/puppeteerDocker image has them pre-installed if you would rather not. - Write a
.pa11yciconfig:"standard": "WCAG2AA","runners": ["axe"],"timeout": 30000,"concurrency": 1(one page at a time — see the pitfalls), andhideElementsfor third-party widgets you genuinely cannot fix. - Run it once by hand against your sitemap and write the JSON to a file. That first run is your baseline, not a failure. Expect a lot of findings and do not panic at the number — most sites produce the same handful of rules repeated across every page from one template.
- Set each page's threshold to its current count, so tomorrow's run passes. From then on the rule is simple: the number may go down, never up. That is the ratchet, and it is what stops a redesign quietly undoing six months of work.
- Add the cron line — weekly, overnight. Keep every JSON in a
reports/folder, named by date. Never delete them. - Add the diff script: compare this week's per-page counts to last week's and send the difference to Telegram or email. Silence when nothing changed is the point.
- Optional: pipe each new violation through a local model for the plain-language line, and fix the top three items each month rather than trying to clear the list.
- Publish an accessibility statement on your site: what standard you aim at, what you know is not yet compliant, and how someone can reach you about it. It costs an hour and it is the single most visible thing you can do.
Pitfalls — what goes wrong when you build this
Never buy an overlay
This is the expensive mistake in this field. On 3 January 2025 the US Federal Trade Commission charged accessiBe over claims that its one-line widget made websites WCAG-compliant; the final order landed on 21 April 2025, USD 1,000,000, and it runs for twenty years. Courts have not accepted an installed overlay as proof of compliance. A scanner that shows you what is broken and a widget that paints over it are not the same product, and only one of them survives a challenge.
The cookie banner eats your score
The most dangerous failure here is silent. If a consent wall covers the page, the scanner tests the wall and reports a clean site — the violation count drops and it looks like progress. Handle the banner (dismiss it in the scan, or exclude it explicitly) and sanity-check that the number of pages scanned matches your sitemap on every run.
A green scan is not a compliant site
On the tool's own numbers you are covering somewhere between a third and a half of WCAG. Whether alt text is meaningful rather than merely present, whether the tab order makes sense, whether someone can actually complete a checkout with a keyboard — none of that is machine-checkable. Once a year, unplug the mouse and try to buy something on your own site. It takes twenty minutes and it will teach you more than the scanner.
Concurrency looks like failures
Each parallel page is a whole Chrome process. Push past one per CPU core on a small box and you get timeouts, which appear in the report as errors that read exactly like accessibility problems. Keep concurrency at 1 or 2 and let the scan take longer.
A zero threshold on day one kills the habit
Turn on a strict gate against an existing site and the first run is a wall of red; the normal human response is to switch the whole thing off. Baseline first, then ratchet down.
Watch what you install
While researching this I found a self-hosted accessibility dashboard that does exactly what this blueprint describes, with a nicer interface. One author, one star, first commit weeks ago. It may well become good. It does not yet clear the bar for something you put in front of a legal obligation, so it is not recommended here — the boring 4,500-star tool with eleven years of commits is.
Verified repos
pa11y-ci — LGPL-3.0, 629 stars, last commit 29/08/2026
pa11y — LGPL-3.0, 4,500 stars, last commit 28/08/2026
axe-core — MPL-2.0, 7,468 stars, last commit 01/09/2026
pa11y-dashboard — GPL-3.0, 1,089 stars, last commit 25/03/2026 (optional, needs MongoDB)
Ollama — MIT, 180k stars, active (optional, for the plain-language step)