The pattern that pushed me to build this: I'd fix an accessibility issue, ship, and a
few deploys later it would quietly come back. A contrast tweak undone here, a label
dropped there. I never found out until someone told me, and by then it was in production.
So I built AxeGuard. Paste any public URL, it loads the page in a real headless browser
(Playwright), runs axe-core against it, and gives you the violations grouped by rule with
the WCAG success criterion, the affected elements, and fix guidance for each. Free, no
signup, results in about 30 seconds.
What it does and doesn't do
I want to be straight about this, because the accessibility-tool space is full of
overpromising. Automated checks catch a subset of WCAG issues. The figure people usually
cite is somewhere between a third and a half. A scanner can tell you an image has no alt
attribute. It cannot tell you whether "IMG_1234.jpg" is meaningful alt text, or whether
your focus order makes sense, or whether your captions match the audio.
So AxeGuard never uses the word "compliant." It is not a compliance certificate and it
will not make a demand letter go away. What it does is find the machine-checkable issues
fast, so the human review you still have to do starts from a cleaner baseline.
How it's built
Nothing exotic. Next.js, axe-core running inside Playwright Chromium, one small Fly.io
machine, SQLite for storage. The part that took the most care was SSRF protection, since
the entire app is "type a URL and we will fetch it." It resolves DNS and rejects private,
loopback, and link-local ranges, strips credentials out of URLs, blocks cloud metadata
endpoints, and re-checks every redirect and subresource the page tries to load. You cannot
point it at internal infrastructure.
The result page groups findings by rule, sorts critical down to minor, and links each rule
to the Deque docs so you can read the full explanation and the suggested fix.
Where it's going
The scanner is the free part. What I am actually testing is whether people want
monitoring: weekly re-scans, an alert when a deploy introduces a new issue, and a CI check
that fails the build on a regression. That is the thing that would have saved me from the
bug-comes-back loop in the first place.
If that sounds useful, there is an email field on the results page. And if you work in
accessibility and the output gets something wrong, I want to hear it. Tear it apart.