Skip to content
wcagc
Create account
←Back to blog
honestyvendorsprocurementVPAToverlays

How to vet an accessibility vendor's compliance claims

How to check accessibility vendor claims: what WCAG compliant should mean, how to read a VPAT, and what the FTC accessiBe order says about proof.

P

Pavel Charkasau

To vet accessibility vendor claims, ask for the evidence behind each one and check that it matches the words. A claim like "makes your site WCAG compliant" needs proof that the product actually does that, on sites like yours, and keeps doing it. The US Federal Trade Commission made that point in January 2025 when it settled with accessiBe, whose accessWidget was marketed as able to "make any website compliant with WCAG". The FTC said those claims were "false, misleading, or unsubstantiated" (FTC, January 2025). The W3C, which writes WCAG, says no tool can settle the question on its own: "Web accessibility evaluation tools can not determine accessibility, they can only assist in doing so" (W3C WAI). So the practical test is simple. For every promise on a vendor's site or in their proposal, ask: what exactly is claimed, about which pages, tested how, and where is the report? Below are the questions I would ask, the documents to request, and the phrases that should make you slow down.

Why do accessibility vendor claims need checking at all?

Because the person publishing the claim is usually the person selling the product, and the buyer carries the consequences. Your site is what people with disabilities have to use. Your organisation is the one named in a complaint or a regulator's letter, whatever the vendor's homepage said.

The accessiBe case shows the pattern in public records. Per the FTC's complaint, the company claimed its AI-powered plug-in could make any website WCAG compliant, and it also promoted the product through articles and reviews "formatted to appear as if they were independent opinions by impartial authors." The FTC said the company "failed to disclose the company's material connections to the supposedly objective reviewers" (FTC, January 2025). The final order, approved in April 2025, required a $1 million payment. It bars accessiBe from claiming its automated products can make any website WCAG compliant, or keep it compliant over time, "unless it has the evidence to support such claims" (FTC, April 2025).

That last phrase is the whole method. You are not trying to catch anyone out. You are asking for the evidence the FTC says a claim like that needs. Our longer write-up of the case is the accessiBe FTC settlement, explained.

What should an accessibility vendor be able to prove?

It depends on what they sell. A scanner, an audit firm, a remediation agency and an overlay script make very different promises, so match the evidence to the product.

Vendor typeTypical claimWhat to ask for
Automated scanner"Finds WCAG issues across your site"Which rules it runs, which WCAG success criteria they map to, and what it says it can't check
Audit firm"Full WCAG 2.2 AA audit"Methodology (for example WCAG-EM), page sample, assistive technologies used, a redacted sample report
Remediation agency"We fix your code"Before and after test results on the same pages, and who retests
Overlay / widget"Instant compliance"Independent test results on real customer sites, with dates and scope

A scanner vendor that is honest about its coverage is easier to trust than one that isn't. Automated testing finds a real share of issues, but not most of them in every count. Deque's study of more than 2,000 audits found automated tests caught about 57% of issues by volume (Deque). Counted by success criteria instead of issue volume, the share is lower, which is why you'll see a range of roughly 30 to 57% quoted. If a vendor's numbers sit well above that range, ask how they counted. I wrote more about this in how much automated tools actually catch.

Which phrases should make you slow down?

Some words are a signal to ask a follow-up question, not proof of bad faith. These are the ones I'd flag in a proposal:

  • "Compliant" with no scope. Compliant with which standard, which version, which level, on which pages, as of what date? WCAG 2.2 says a conformance claim has to state the date, the version, the level, the pages covered and the technologies relied on (W3C, WCAG 2.2).
  • "Instant" or "one line of code." Fixing a missing form label means changing the form. A script can try to patch the rendered page, but the W3C is clear that tools can only assist in determining accessibility.
  • "Certified." There is no official WCAG certification for websites. The W3C's own logo page says its logos "do not represent review or validation of conformance by W3C and/or WAI" (W3C WAI). More on that in is there such a thing as WCAG certification?.
  • Reviews you can't trace. If the only praise comes from comparison sites and "best of" lists, check who runs them and whether the vendor pays them. That was a core part of the FTC's case.
  • A legal promise. Any vendor that says their product will protect you from complaints or regulators is promising something no software can deliver. The legal standard under the ADA or the European Accessibility Act is about whether people can use the service, not about which tool you bought.

How do you read a vendor's VPAT or ACR?

A VPAT is a blank template from the Information Technology Industry Council (ITI). Filled in with test results, it becomes an Accessibility Conformance Report, or ACR (ITI). The current version is VPAT 2.5Rev, in four editions: 508, EU (for EN 301 549), WCAG and INT. It is written by the vendor, about the vendor's own product.

Section508.gov's buyer guidance is a good reading guide, and it applies outside US government too (Section508.gov):

  • "Partially Supports" means the product does not conform to that criterion. The guidance says "It is crucial for purchasers to examine the ACR in detail" to see which parts fail.
  • "Not Evaluated" gives no assurance either way. Ask the vendor when they plan to test it.
  • "Not Applicable" should come with a reason. Check that the reason holds.
  • "Whenever possible, purchasers should conduct independent conformance validation testing."

Three quick checks I do on every ACR. Is it dated, and is the date within the last year or so? Does it name the product version you are buying? Do the remarks column entries say something specific, like "the date picker in the booking flow is not keyboard operable", or do they just repeat the criterion? A report with "Supports" on every row and no remarks tells you very little. Our primer on what a VPAT is goes through the format row by row.

How can you test a vendor's claim yourself?

You don't need a full audit to spot a gap between claim and reality. Pick two or three of your real user flows (sign-up, search, checkout) and try them yourself:

  1. Run an automated scan before and after. If a vendor says their product fixes issues, the rule IDs should change. You want specifics such as label on #checkout-email or button-name on .cart-drawer > button.close, not a score.
  2. Use the keyboard only. Tab through the flow. Can you reach every control, see where focus is, and close every dialog? An automated tool can't fully judge this.
  3. Turn on a screen reader. VoiceOver on macOS or NVDA on Windows. Does the "Add to cart" button announce as a button with a name? Do error messages get read out?
  4. Read the fine print. Compare the contract's wording with the marketing page. The contract usually promises much less, and the contract is what you can hold them to.

Our WCAG checklist marks which criteria a scanner can decide and which need a person, so you can see where a tool's claim stops.

Here is my opinion, stated plainly. A vendor who tells you what their product can't do is the one I'd shortlist. Every honest scanner, ours included, misses things like whether alt text is accurate or whether focus order makes sense. If a sales deck says otherwise, the deck is the problem, not your site.

What should go into the contract?

Put the claims in writing in a form you can check later. US federal guidance is a useful model here. The FY 2025 governmentwide Section 508 assessment recommends that agencies "require all ICT contracts to include defined testing methodologies and right-to-repair provisions", so vendors "fix, replace, or correct non-conforming products at their own expense", and that agencies reject deliverables that fail Section 508 requirements (Section508.gov). Private buyers can borrow the idea:

  • name the standard and level, for example WCAG 2.2 AA or EN 301 549 v3.2.1
  • require an ACR for the version delivered, plus updates on major releases
  • keep the right to run your own testing, or have a third party do it
  • define what happens when testing finds failures: who fixes them, and by when

None of this needs legal drama. It turns a marketing sentence into a deliverable.

FAQ

How do I know if an accessibility vendor's claims are true?

Ask for the evidence behind each claim and test a few real flows yourself. A credible vendor can show dated test results, the pages covered and the method used, and will say what their product does not check.

Can any product make my website WCAG compliant automatically?

No. The W3C says evaluation tools "can not determine accessibility, they can only assist in doing so", and the FTC's 2025 order bars accessiBe from claiming its automated products can make any site WCAG compliant without evidence to support the claim.

Is a VPAT proof that a product is accessible?

No. A VPAT, once completed, is an Accessibility Conformance Report written by the vendor about its own product. Section508.gov advises buyers to read it in detail and, whenever possible, to run independent validation testing.

What does "Partially Supports" mean in an ACR?

It means the product does not fully conform to that criterion. Section508.gov treats it as non-conformance and tells buyers to check exactly which parts fail.

Should I trust accessibility vendor reviews and rankings?

Only when you can tell who wrote them and whether the vendor paid for them. The FTC alleged that accessiBe failed to disclose its material connections to supposedly objective reviewers.

Check a vendor's claim against your own pages

Run a free scan on the flows a vendor says they've fixed. You'll get each finding with its rule, WCAG success criterion and selector, plus a clear note on which checks still need a person.

Pavel Charkasau, founder, wcagc.com Last updated: 10 October 2026

Sources