How to Buy a Website That Is Actually Accessible

Accessibility gets retrofitted for one of two reasons. Nobody asked for it, or somebody asked in words too vague to hold anybody to. The second is the more expensive, because everyone believed the requirement was covered right up until acceptance.

So this page is about the wording. It applies whether you are commissioning a site, hiring an agency, or buying software you will make your staff use. None of it is legal advice, and you should have a lawyer read anything you sign.

The Wording That Does Not Work

• "The site must be accessible." Accessible to whom, measured how? Unenforceable, and everybody signing it knows that.
• "The site must be WCAG compliant." No version, no level. WCAG 2.0 Level A is compliance, it is satisfiable, and it is a long way below what your law probably requires.
• "The site must be ADA compliant." Careful with this one, because the answer changed in 2024 and depends on who you are. The ADA statute contains no technical standard, and for a business under Title III there still is not one, so the phrase names nothing testable. For a state or local government body under Title II, the DOJ's rule now sets WCAG 2.1 Level AA with dates attached, so the phrase does name something. Our WCAG versus the ADA page has the detail.
• "Best practice accessibility." Best practice according to whom, and verified by whom?

The Wording That Does

Four elements make a requirement enforceable. A standard with a version and a level, a scope, a verification method, and a consequence.

Every part of that is doing work, and two of the parts exist because the standard makes them necessary rather than because they read well.

Processes are named separately from pages because conformance for a process runs across every page in it. A checkout assembled from four perfectly conforming templates still fails as a process if step three does, and a clause scoped to templates leaves exactly the part that takes your money unprotected.

The claim has to be dated because the standard says a conformance claim must carry a date, the level satisfied, a description of the pages covered and the technologies relied upon. An undated verification is not a weaker claim. It is not a claim, in the standard's own terms, and you can say so.

Naming manual testing is what stops a clean automated scan being offered as proof, and that requirement is enforceable rather than merely sensible. Of the 55 criteria at Level A and AA, 24 have no automated rule written against them at all. On 59 of the 87 live rules that do exist, W3C records a pass as meaning the criterion needs further testing. And W3C's own guidance on evaluation tools says in as many words that human judgement is required. A supplier arguing that a scan discharges a WCAG clause is arguing against the body whose standard the clause names.

Tying it to acceptance is what gives the whole thing force, because a requirement with no consequence is a preference.

Which Standard to Name, and Where

WCAG 2.2 Level AA is the right default, and there are two situations where naming it alone leaves a gap.

If you are buying in Europe or the UK, the standard your regime actually routes through is EN 301 549, not WCAG. It carries WCAG for web content and adds requirements WCAG has nothing to say about, covering hardware, two-way communication and documentation. A contract naming only WCAG has under-specified, and the fix is to name both.

If you are a US federal buyer, your binding standard is WCAG 2.0 Level AA through Section 508, and a supplier may push back that 2.2 is more than the law asks. They are right about the law and it does not help them, because the versions stack. A product conforming to 2.2 conforms to 2.0 automatically, so naming 2.2 costs the supplier nothing they would not spend anyway and saves you renegotiating when the standard moves.

Ask for Evidence, Not Assurance

Suppliers will tell you their product is accessible. Ask what the claim rests on, and know that a regulator has already drawn this line for you. In April 2025 the FTC's order against an overlay vendor barred it from representing that its automated product makes any website WCAG-compliant, or keeps it compliant over time, unless it has the evidence to back that up. Evidence is the standard a federal regulator applied to a supplier's compliance claim. It is a reasonable one for you to apply too.

1. 1Ask for a VPAT or an accessibility conformance report. What one is and how to read it is in VPAT and ACR, explained.
2. 2Read the remarks column, not the ratings. "Supports" with a paragraph of exceptions underneath is a partial answer wearing a full one.
3. 3Check the date, the edition and the WCAG version. The current template is VPAT 2.5Rev, from April 2025, and it comes in four editions covering Section 508, EN 301 549, WCAG, and an international one combining all three. Ask for the edition that matches your regime, because the wrong one answers a question you did not ask. And a 2.5 template can still be filled in against WCAG 2.0, so the template version and the standard version are two different checks.
4. 4Ask who tested it. A VPAT is designed to be self-assessed, and the body that publishes it states plainly that it neither reviews nor approves them. So a VPAT is a supplier's own account of their product, which is useful and is not third-party assurance, whatever the formality of the document suggests.
5. 5Ask whether a screen reader user was involved. The answer separates real testing from a tool run faster than any other question on this list.

For an Agency Build

Put accessibility in the acceptance criteria rather than the nice-to-haves, and give the team something concrete to build against.

• Name WCAG 2.2 Level AA explicitly, and say that the design system components are in scope as well as the pages.
• Require a keyboard pass and a screen reader pass as part of their own QA, not only yours.
• Ask for the design checklist to be applied before build, which is where it is cheapest.
• Hold back a meaningful part of the final payment until independent verification passes.

For Software You Are Buying

If your staff will have to use it, accessibility is an employment matter as much as a procurement one. A tool a disabled employee cannot use is a barrier you chose and paid for.

That duty has no size threshold in the UK, where every employer carries it regardless of headcount, and company size only affects whether a defence of disproportionate burden gets anywhere. In the US the analogous duty sits in Title I of the ADA. Either way, buying inaccessible software is a decision that lands on somebody's ability to do their job.

Ask for the conformance report before the demo rather than after. It changes the conversation, and a supplier who cannot produce one has told you something useful.

When Part of It Genuinely Is Not Theirs

Sometimes a supplier is right that a piece of the page is outside their control. An embedded payment frame, a map, a feed. The standard has a mechanism for exactly that, called a Statement of Partial Conformance for third-party content, and knowing it exists changes how that conversation goes.

It does not let anybody off. What it does is give a supplier a legitimate, named way to describe what conforms and what does not, instead of choosing between an overclaim and a vague exclusion. So the answer to "that bit is not ours" is not to accept it or reject it. It is to ask for it written up the way the standard provides for, and then to decide what you want done about it.

If You Are the Supplier

This cuts both ways, and a clause like the one above is one you may be asked to sign. Price the verification in, agree the standard before you start, and get the scope written down, processes included. Ambiguity at the brief stage becomes free remediation at the acceptance stage, and it is always your free remediation.

Our second opinion audit exists for exactly this moment, when two parties disagree about whether a build met the standard it was sold against.