The a11ycheck bot

a11ycheck is an automated web accessibility scanner. It checks pages against WCAG 2.2, the Web Content Accessibility Guidelines, and reports the issues it finds.

If you have seen a11ycheck in your server logs, this page explains what it was doing, what it does and does not touch, and how to stop it.

Identifying the bot

Our crawler sends this User-Agent:

a11ycheck/0.1 (+https://bot.a11ycheck.dev; accessibility scanner; respects robots.txt)

The version number changes over time, so match on the prefix a11ycheck/ rather than the exact string. We use bot.a11ycheck.dev as the reverse-DNS name for the addresses we crawl from, so you can verify us rather than trusting a self-declared header.

Requests originate from a single, stable IPv4 address:

40.160.237.133

Our scanning infrastructure has no IPv6 route, so this is the only address your logs will ever show for us.

Publishing that address means you can allow-list us if you filter by IP, and know exactly what to block if you would rather we stayed away.

Why it is on your site

Scans are always initiated by a person. Someone submitted your domain through our API — usually the site's owner, an agency working on it, a developer before a release, or an accessibility consultant doing an audit.

We do not crawl the web indiscriminately and we do not discover sites by following links from other sites. If we are on your site, a specific scan of your domain was requested.

What it requests

For a given scan, the bot makes only GET requests, and only to pages on your own domain:

Because link discovery and analysis are separate stages, a page may be requested more than once within a single scan. We do not fetch off-site resources beyond what a normal page load requires to render.

What it never does

• It never submits a form, clicks a button, or types into a field.
• It never logs in. We hold no credentials for your site and do not attempt authentication.
• It never sends anything other than GET. No POST, PUT, PATCH or DELETE.
• It never modifies your content or configuration.
• It never leaves your domain. Discovery is same-origin by default.

One thing worth being precise about: pages are loaded in a real Chromium browser, so your JavaScript does execute — as it would for any visitor. What the bot does not do is interact with the result.

How it limits itself

We take care to be a well-behaved guest:

• robots.txt is respected — disallowed paths are skipped, and a sitemap does not override your rules.
• Same-origin only — we do not follow links to other domains.
• Page cap — a scan analyses a bounded number of pages (50 by default).
• Depth cap — link following is limited by depth (2 by default).
• Time caps — any single page is abandoned after 30 seconds, and a whole scan runs to a deadline of two minutes plus ten seconds per page. A full 50-page scan therefore has about ten minutes, rather than a fixed cap that would cut off large sites part-way.
• Concurrency ceiling — pages are scanned one at a time, so we do not burst.
• Per-customer limits — each API key has its own rate limit and a cap on how many scans it may run at once, so no single customer can generate sustained heavy traffic.
• SSRF protection — we refuse to fetch private, loopback, link-local or cloud-metadata addresses, so the scanner cannot be used to probe internal networks.

How to block the bot

Any one of these is enough, and we will not work around it.

1. robots.txt (simplest)

User-agent: a11ycheck
Disallow: /

To block the bot while leaving the rest of your rules intact, add this group alongside your existing ones.

2. Block by User-Agent

Match on the prefix a11ycheck/ in your CDN, WAF or server configuration.

3. Block by IP

We publish our egress address above. Blocking it is effective and permanent until we tell you otherwise, and we will tell you before changing it.

What happens when you block us

The scan will fail with a discovery or fetch error, and the customer who requested it sees that failure. Nothing bad happens to your site, and a block never counts against you. If a customer believes a scan should be permitted, the conversation is between them and us.

What we store

A scan records:

• Findings — the rule triggered, the WCAG 2.2 success criterion, the affected element's CSS selector, and a snippet of the surrounding HTML.
• Metadata — the page URLs, HTTP status codes, timings, and the fact that a scan occurred.

We do not store screenshots, page images, or copies of your pages.

Be aware that HTML snippets can capture page content, which may include personal data if your pages display it. We delete this material 90 days after the scan that recorded it.

Deletion from the live database is immediate and cascades to everything recorded about that scan — the pages, their URLs, status codes, timings and snippets go together. Our backups retain a copy for a further 7 days, so a scan's data is fully gone within 97 days of the scan. Aggregate counts with no page content (how many scans and pages a customer used, for billing) are kept for longer; they contain no URLs and no snippets.

If you are a data subject or a site owner and want material relating to your site deleted earlier, or you need our data-handling details for a DPIA or your records of processing, contact us at the address in the Contact section below.

A word on accuracy

This matters more than anything else on this page, so we will be blunt about it.

Automated testing covers only part of WCAG 2.2. Roughly a third of success criteria — including several added in 2.2, such as Focus Appearance, Dragging Movements and Accessible Authentication — cannot be reliably judged by a machine, because they depend on how an interface behaves under keyboard navigation and assistive technology.

Our engine names those criteria explicitly in every report rather than quietly passing them. It does not invent findings for them: a finding has to describe something we observed on your page, and "this criterion is not machine-testable" is a limit of the tool rather than a problem with your site. A report tells you a page has no machine-detectable issues; it does not tell you the page conforms to WCAG 2.2.

A scan result is not a certification, conformance statement, or legal opinion, and should not be presented as evidence of compliance — a point we make to our own customers as well.

Contact

We aim to respond to crawl-related enquiries within two business days. If you would like us to stop scanning your site permanently, say so and we will add a standing exclusion — you do not need to justify the request.