Which rules apply to your website, and what an automated scan can actually check

Two questions come up before anyone reads a compliance report: which rules actually apply to me, and how much of this can a scanner really tell me?

This page answers both, honestly, including the parts where the answer is that we cannot help. Pick a market below.

Scope follows your visitors, not your address

The common assumption is that a company is bound by the law of the country it is registered in. For website compliance that is usually the wrong test. The European Accessibility Act reaches services offered to consumers in the EU; the GDPR reaches the monitoring of people in the EU. A business registered in Sydney with German customers is in scope for both, and a business registered in Berlin selling only to Australia answers to the Disability Discrimination Act rather than the EAA.

So Veracly scopes a scan by the countries your visitors come from, plus the primary market you configure. Jurisdictions with no qualifying traffic are shown on the report as not evaluated rather than silently omitted, so you can see what was and was not assessed.

What “automated” honestly means

Automated accessibility testing has a hard ceiling, and it is worth being precise about where it sits. Of the 50 WCAG 2.1 A and AA success criteria, 29 cannot be reliably verified by any automated tool. No scanner can tell whether alt text isaccurate, whether a reading order matches the intended meaning, or whether an error message is actually helpful — those need a person.

The other 21 have at least one automated check, and that distinction matters too. A passing check means one specific failure mode is absent. It does not mean the criterion is met. An image with alt text passes the automated check whether the text describes the image or reads image1.png.

This is why every Veracly report prints all 29 manual criteria, and why they do not affect your score: scoring criteria we did not test would be inventing a number.

On the privacy side, the limit is structural

Tracker and cookie detection is not a sampling problem — it is an observability one. We drive a real browser to a public page and record what it does. That makes what we find highly reliable: if we say a request fired before consent, you can open DevTools and watch it fire.

It also means an entire category is invisible. Server-side tracking — Conversions API, server-side tag managers, hashed-email backend sends — leaves no trace in the browser. Neither does anything that only fires inside a logged-in area. If those matter to you, a scan is not the tool; a server-log audit is.

Where we say “we are not sure”

Not every finding is equally solid, and reports that pretend otherwise are less useful, not more. Veracly separates three kinds:

• Observed — we watched it happen and can point at the element or the request. You can reproduce it yourself.
• Inferred — established by absence, or by a heuristic. We probed for a privacy policy across a fixed set of locations and did not find one; a site that publishes it somewhere we did not look looks identical to a site with none.
• Contextual — the technical observation is right, but the conclusion depends on facts a scan cannot reach, such as what your privacy policy actually says or whether a tag is consent-gated at runtime.

A finding in the second or third group is a prompt to look, not a verdict. We would rather tell you that than hand you a confident number built on an inference.

What this page is not

It is a description of what our software checks. It is not legal advice, and the list of regulations we monitor is not a list of the regulations that bind you — those are different questions, and only the second one matters to a regulator. If a finding has consequences, take it to a qualified lawyer in the relevant jurisdiction.

If you think a finding is wrong, we would like to know: corrections@veracly.app. We re-scan and reissue or retract within five business days.