Scandiary's answer

Memory, not detection. We use axe-core, the same open-source engine most accessibility tools are built on, so a browser extension will show you the same issues on a page you are looking at right now. The difference is that we scan the same pages every Monday, keep the history, and tell you what is new, what increased, what decreased and what is no longer detected since last week. Nobody runs an extension on their own site every week for a year, which is the only reason this exists.

Two things we will not do. We do not issue a verdict: automated checks find roughly a third of accessibility problems, and the rest needs a person. And we never say a problem was repaired, only that it is no longer detected, because a problem can disappear when a page is deleted. If nothing changed, we send nothing.

Scandiary's answer

Online shops and the people who look after their websites — often a Shopify, WooCommerce or Wix store. The scan is against WCAG 2.1 AA, which is the same standard EN 301 549 points to, so it is not tied to one country. Whether any particular law applies to a given shop depends on its size and where it sells, and that is a question for the shop, not for us.

One thing we learned scanning real shops: most of what we find comes from the theme rather than from anything the owner wrote. That is worth knowing before you pay us, because it changes who has to do the work.

Scandiary's answer

It started as a scan of ten real EU shops, five pages each, to find out whether the problem was real. Nine of the ten had violations. One was genuinely clean, and that mattered more than the nine: a tool that finds something everywhere is not sensitive, it is useless.

The scanner was wrong at first. A redirect made it treat a site's own links as external, so it scanned a single page and reported nothing. That defect was found by pointing it at real websites, not by the test suite, and it is written up on our research page instead of being quietly removed.

Running a scan once tells you almost nothing. Running the same scan every week and keeping the dates is what turns it into evidence.

Scandiary's answer

Node.js, Puppeteer and axe-core for the scanner. The visitor-facing site is plain HTML and CSS with no JavaScript at all — our own Content-Security-Policy is script-src 'none'. Reports are generated as static HTML and delivered by email through Resend. Hosting is Vercel, and the scan history is stored in a private Git repository rather than a database.

Scandiary's answer

If you already have a developer and a test suite, tools like axe DevTools or BrowserStack will serve you better. They are built for that workflow, and we use the same engine underneath anyway.

Scandiary is for the shop owner who has neither. Five pages are free every Monday and the free plan is not a trial. $12 a month adds where every problem sits — each affected element with its CSS selector and the page it is on, up to 25 per issue — and twenty pages instead of five. There is nothing to install, no account, and no script added to your site.

The other difference is what we do not sell. There is no widget added to your pages, and no report we send will tell you that you passed. A scan is evidence of what a machine could see on one date. We write that inside the report itself, not in the small print.