Skip to main content
digital accessibility compliance for state and local government
Scan a site

How it works

Eight stages. The first three are automated, the middle three are your team’s, and the last two are what a lawyer asks for.

Automate what can be automated. Manage what requires humans. Prove what was fixed.

The eight stages

  1. Discover

    automated

    What happens
    A crawl of your registrable domain, obeying robots.txt and its crawl delay. Canonical URLs are normalised so one page is one page.
    You see
    4,182 pages · 1,180 documents, plus what was skipped and why
    It produces
    The page inventory and the document inventory
    It cannot
    Reach anything behind a login. Public pages only, by design — storing your credentials would move your data into a more expensive band of every state security framework.
  2. Scan

    automated

    What happens
    The engines named in the footer attribution run on each sampled page at Desktop (1280 × 800) and Mobile (390 × 844), tagged wcag2a, wcag2aa, wcag21a, wcag21aa. The primary engine is version 4.13.0, and every finding records which engine and which version produced it.
    You see
    Violations and results needing review, with the rule id, the WCAG criterion and the failing element. There is no count of checks that succeeded, because the finding model holds no such value.
    It produces
    Raw findings — one engine result, on one page
    It cannot
    Detect most of what matters. Automated testing detects roughly 30–40% of real barriers. Manual testing covers the rest. 16 of the 50 WCAG 2.1 AA success criteria have any automated coverage — 32%.
  3. Deduplicate

    automated

    What happens
    Pages are clustered into templates by structural similarity, and findings are collapsed onto a fingerprint of engine, rule, template, DOM shape, viewport and platform.
    You see
    4,000 URLs are 12 templates; we scanned 8 pages of each. 27 issues across 4,182 pages.
    It produces
    Issues — the unit you act on — and occurrences, one per affected page
    It cannot
    Merge a desktop and a mobile defect. Viewport is part of the identity, so the same defect at two viewports is two issues, and the same defect on iOS and Android is two more.
  4. Assign

    your team

    What happens
    An issue is given an owner and a status, or it is deferred — with a written reason, a named owner and a review date.
    You see
    Assigned with the person's name, or Deferred with its owner, reason and review date, always shown together
    It produces
    An ownership record, and an event in the ledger
    It cannot
    Assign itself. Nobody is auto-assigned, and no issue is closed by the system.
  5. Remediate

    your team

    What happens
    Written guidance per issue, split by audience — content editor, developer, designer — and by effort: trivial, small, medium, large.
    You see
    The failing element, its DOM path and a fix description you can paste into a ticket unchanged
    It produces
    Nothing in your site. We never touch your site.
    It cannot
    Fix anything. No overlay, no injected script, no automatic remediation, and no generated alternative text — no code path in the product writes alt text, and a test greps for its absence on every build. The product makes no AI suggestions. If it ever does, they will be off by default, never applied on their own, never counted as verification, and labelled “AI suggestion — not verified. Review before applying.”
  6. Retest

    your team

    What happens
    The next scan re-checks every occurrence, and a person can verify by hand with a named method and a named assistive technology.
    You see
    Ready to verify means claimed. Verified means checked. They are two different states and they never look the same.
    It produces
    A verification event naming the actor, the method and the tool: Verified by Maria Sandu on 2 October 2026, manual method, NVDA 2026.1 with Firefox
    It cannot
    Confirm a criterion automation cannot test. A criterion checked only by an engine is never published as a conformance claim.
  7. Prove

    the record

    What happens
    Every change is appended to a hash-chained ledger, and the ledger is exported as an evidence packet.
    You see
    Chain intact — 2,341 events verified, 12 March 2026 to 8 September 2026; or Chain broken at event 1,987 — 8 September 2026; or Cannot verify, which is never silently reported as intact
    It produces
    An export a third party can verify without trusting us or running our code
    It cannot
    Assert conformance. The product never issues a verdict on a website's legal compliance — not in a report, not in a badge, not in an export.
  8. Monitor

    the record

    What happens
    Each asset is scanned on a schedule — weekly by default, or daily or monthly — and a scan can be compared with an earlier scan of the same asset, with each change between them classified.
    You see
    New, Regressed, Spread to more pages, Template broke — the last is the most severe
    It produces
    A comparison on screen, and email: a weekly digest of what changed, and an alert when a critical issue comes back, a template breaks, a scan fails three times running or a deadline is 90 days away. Nothing is sent when nothing changed.
    It cannot
    Watch your mobile apps. Mobile auditing is not built yet.

What automated testing can and cannot check

Real barriers detected by the best automated tool
30–40%
WCAG 2.1 AA criteria with any automated coverage
32%, 16 of 50
WCAG 2.2 AA criteria reliably flagged automatically
13%, 7 of 55
Individual errors detectable automatically, by volume
about 57%
12 WCAG success criteria, how much of each an automated engine can check, and what a person still has to do. Ordered by automated coverage, from most to least.
Success criterionAutomatedWhat a person still has to do
1.4.3 Contrast (Minimum)Level AAYesCheck text over images and gradients, which the engine skips
1.4.11 Non-text ContrastLevel AAPartlyJudge which graphics are meaningful
1.1.1 Non-text ContentLevel APartlyDecide whether the alternative text is correct, not merely present
1.3.1 Info and RelationshipsLevel APartlyConfirm the visual structure matches the markup
4.1.2 Name, Role, ValueLevel APartlyOperate custom controls and listen to what is announced
3.3.1 Error IdentificationLevel APartlySubmit the form wrongly and check what is said
2.4.7 Focus VisibleLevel AAPartlyLook at every focusable element in every state
2.1.1 KeyboardLevel ANoOperate every control from the keyboard alone
1.4.10 ReflowLevel AANoZoom to 400% in a 320 px viewport and read the page
2.5.8 Target Size (Minimum)Level AA (2.2)NoMeasure the controls people actually miss
1.2.2 Captions (Prerecorded)Level ANoWatch the video and read the captions
1.2.4 Captions (Live)Level AANoAttend the meeting stream

Roughly two out of three real barriers require a human. That is why guided manual testing is in the product and in the same tables as the automated results — not sold separately, and not left to you.

What you get at the end

An evidence packetPDF, tagged, with a JSON sidecar
Every event with its actor, its timestamp and its hash; the scope statement naming what was and was not tested, including vendor systems; the methodology statement naming every engine and version; and the chain verification result.
A conformance reportVoluntary Product Accessibility Template (VPAT) 2.5Rev, as HTML and .docx
One row per success criterion, marked Supports, Partially Supports, Does Not Support or Not Applicable, with remarks on every row that is not Supports.
A remediation planHTML and CSV
Criterion, what fails, owner, effort and target date — one line per open item, in the five project phases: quick wins, template fixes, content remediation, documents, structural.
An accessibility statementHTML, published on your own site
What conforms, what does not, the date it was assessed, and a feedback channel that reaches a real person with a stated response time.

Every one of these is generated from the same ledger. None is written by hand, and none can say something the record does not support.

Where the numbers on this page come from

The 30–40% figure, the 32% coverage figure and the 57% by-volume figure are drawn from published research on automated accessibility testing, not from our own product. We do not publish a benchmark of our own engine against a commercial one — the licence terms of the tools involved forbid it, and a vendor’s self-run benchmark is not evidence anyway. Where a figure on this site cannot be sourced, it is not stated. If you think one of these numbers is wrong, write to us and we will correct the page or cite the source.

What we will not do

  • No injected script. We make no request to your site outside a scan you started, and we serve nothing from your domain. There is no snippet to install.

  • No score. There is no column in the schema that holds one, no percentage of the standard, no grade, and no ranking of one entity against another. A number that averages 1.4.3 with 2.1.1 means nothing.

  • No generated alternative text. No code path generates, suggests or applies it, and a test greps the codebase for its absence on every build.

  • No verdict on legal compliance. The product cannot emit one. No template, no export and no string table in it contains such a sentence.

Questions engineers ask

Which engines do you run?

The attribution in the footer of this page names all 3 of them. The primary one is version 4.13.0 and the second is IBM Equal Access 4.0.33/13July2026. Every finding records which engine and which version produced it, because violation counts move between engine versions without the site changing.

Why do you not run best-practice rules?

They are not WCAG requirements, and reporting them as issues inflates the count with things nobody is obliged to fix. We run wcag2a, wcag2aa, wcag21a and wcag21aa.

What happens when the engine version changes?

Any comparison across a version change carries a visible caveat, in these words: “Engine versions changed between these scans. Some differences may reflect the engine, not the site.” It is not dismissible, because a difference that moved with the engine is not a difference about your site.

How many pages per template do you scan?

A structured sample — one page per template, every page in a complete process, the home page and unique-functionality pages — plus a random sample. The sample and the reason each page was included are stored with the scan.

Will scanning slow our site down?

2 concurrent requests per host by default, rising to 8 only if you raise it yourself, with a minimum of 250 ms between requests. robots.txt is obeyed, including its crawl delay. Scans run on the asset’s schedule, at a time assigned to your organisation so customers’ scans are spread across the day, or when you start one. The full politeness table is on the crawler page. If your host still sees load, tell us and we will slow it further.

Is there an API and a CI check?

A versioned public API, at /api/v1, with API keys, signed webhooks and an OpenAPI 3.1 document; the API documentation prints its examples with the responses they get from the sandbox. The GitHub App is built and registered with GitHub; the settings screen that installs it is not built yet, so we send the installation link on request. The command-line tool is built and not yet published: it scans the pages you name with the same engines and configuration as the platform, compares them with the asset’s baseline, and exits 0, 1 or 2 — when the tool itself fails it exits 2, never 0. The GitHub App’s permission list is on the security page, so you can read what it asks for before anyone installs it.

Scan 5 pages, freeOpen the demo (opens demo.barrierops.com)See pricing

The demo uses sample data from a fictional city and needs no account.

https://barrierops.com/how-it-works