Rendered website scanning
Crawl modern JavaScript experiences with Playwright and run axe-core against the interface people actually receive.
- Same-origin safe crawling
- WCAG-mapped evidence
- Human-review states
Proof, not promises
We tested Webscan on our own website.
Before we asked anyone else to trust it, we ran Webscan against Inclusive App Craft's own site—a modern React application. Here is the honest account of what it caught, how it helped us fix the issues, where it fell short, and how it improved.
What it caught
First of all, Webscan scanned our live site the way a real browser does and surfaced eleven findings. Also — because it renders each page after JavaScript runs, not just the raw HTML — it caught a subtle defect a naïve checker misses entirely: a page title that was present in the server response but silently stripped once the app hydrated in the browser. Moreover, it turned the most serious findings into tracked issues: duplicate element IDs on our contact form, a missing title on a service page, and a field tied to more than one label.
How it helped us fix it
Then came remediation. Webscan imported the exact source file from GitHub, drafted a real code change, and — only after a person approved it — opened a focused draft pull request. For the duplicate-ID issue its proposal was spot-on, introducing React's useId() so every field became unique. Furthermore, that single fix resolved the multiple-label issue too, because both shared one root cause. After we merged and the site redeployed, Webscan re-scanned the live page and confirmed the violations were gone.
Where it fell short
However, we will not overstate it. On the missing-title bug, Webscan's automatic fix was plausible but wrong — from the source file alone it could not see that the real cause was a hydration failure deeper in the framework. In other words, a human still had to diagnose and correct that one. This is precisely why Webscan never writes to your main branch on its own, and why every fix waits for human approval: automation assists, and people decide.
The bugs we found in Webscan itself
Along the way, testing on a real, modern site exposed bugs in Webscan too — and we fixed them. First, the scanner's browser refused to launch inside our container until we hardened its sandbox settings. Also, a strict content-security policy initially blocked Webscan from injecting its own analysis script, so we taught it to instrument protected pages safely. In short, using our own product in earnest made it tougher.
How far it has come
As a result of everything we learned, Webscan is markedly stronger today. First of all, it now feeds real browser evidence — including the console errors a page throws — into its fix suggestions, so it can tell a source-code defect apart from a runtime one. Moreover, it reads the neighbouring files a component imports, and it carries a growing library of known framework pitfalls. In addition, it can render a proposed fix and re-check it in a safe sandbox before a pull request is ever opened. Finally, it only calls a fix verified once its own scanner has re-confirmed the issue is gone — never on a guess.
Live proof · verified in a real build
One fix, three connected files, checked in a real build before anyone saw a pull request
To show the sandbox working, we planted a deliberate barrier in a small React app — an icon button with no accessible name — where the correct fix could only be written by reading three files that depend on one another. Here is exactly what Webscan did, end to end.
-
Found
A critical, unnamed button
Rendering the live page the way a browser does, the scanner flagged a Critical
button-nameviolation: toolbar icon buttons with no accessible name — effectively invisible to a screen reader. -
Understood
Across three files that depend on each other
The button lives in
IconButton.tsx, but its correct label comes from a helper inlabels.ts, which derives the text from a field inactions.ts. Webscan read the neighbouring files the component imports and used all three — while treatingactions.tsandlabels.tsas read-only context it must never change. -
Fixed
A minimal, correct change
The change Webscan proposed to IconButton.tsx<button type="button" className="icon-btn" + aria-label={actionLabel(action)} > <Icon size={18} aria-hidden /> </button> -
Verified
In a real, isolated build
Before proposing anything, an isolated sandbox installed the project, built it with Vite, rendered the result, and re-ran the accessibility scan. The violation was gone — on the first attempt. Only then did Webscan mark the draft Sandbox-Verified, still waiting for a person to approve it.
✓ Sandbox-Verified The build ran with none of Webscan's own credentials, and nothing was ever pushed to a branch automatically — automation assists, people decide.
Accessibility is a practice, not a score — and honest tooling should show its work, including its limits.