What a website accessibility scanner can and cannot do
Teams ask for a website accessibility scanner when they need a concrete starting point: which pages have WCAG 2.2 AA conformance issues that an automated engine can see, where those issues sit in the DOM, and what a developer should change. A11yRemedy is built for that job. You paste a URL on this page, we open the document in a headless browser in our infrastructure, and we run axe-core against the rendered HTML. Within about thirty seconds you see issue counts by impact and a preview of the first findings. Give an email address and you unlock the rest of the list, including suggested HTML snippets. Nothing is written back to the site you scanned. A person still implements every change.
Automated testing detects approximately 30–57% of WCAG issues. Manual testing by a qualified auditor is required for a complete conformance assessment. That is not a footnote we hide in the footer; it is the working model. Rules that axe-core can evaluate with high confidence — missing alternative text, unlabelled form controls, empty buttons, a document without a language attribute, colour combinations that fail the contrast algorithm — show up here with a selector and a failing snippet. Keyboard traps, focus order that is technically present but confusing, meaning that depends on sensory characteristics, and most of 2.4.4 in context still need a human. If a vendor tells you a scan replaces an audit, they are selling a different product from a remediation programme.
This is not an overlay and it does not change a live site
Accessibility overlays and widgets inject a script into a customer site to restyle the page or add a toolbar. A11yRemedy does not do that. The only JavaScript that touches a URL you submit is the headless Chromium instance that runs the scan, and that process lives on our servers. We do not drop a badge on your homepage, we do not rewrite your CSS at runtime, and we do not claim the page is accessible because a widget loaded. Overlays have a poor record with disabled people and with courts; they also train organisations to postpone real template work. This scanner exists to make that template work obvious: here is the node, here is the current markup, here is a suggested snippet for a developer to adapt.
Suggested snippets are starting points, not a one-click patch. Alternate text has to describe the actual image. A label has to match the question you ask the user. Colour adjustments have to survive your design system. A11yRemedy never opens a pull request against your repository and never patches production HTML. If you create an organisation after this scan, we can crawl the rest of the site on a schedule, watch for regressions, and produce a remediation report the same way — still for a human to implement. The public scan is the front door: one page, no signup, real findings, then a path into monitoring if you want it.
How to use these results in a remediation programme
Treat the output as a punch list, not a certificate. Share the unlocked report with whoever owns the templates. Fix critical and serious items first; they usually block screen reader users or keyboard users from completing a task. Re-scan the same URL after you deploy so you can see whether those issues resolved. Add pages that matter — checkout, search, account, the news article template — rather than assuming the homepage represents the product. When you need coverage beyond what automated testing can see, bring in a qualified auditor and a group of people who use assistive technology. A11yRemedy supports that programme; it does not replace it, and it does not sell a guarantee.