Accessibility Requirements to Write Into Your Website RFP

Most website RFPs say something about accessibility. Very few say anything a vendor can be held to.

"The site must be ADA compliant" is the usual formulation, and it is close to meaningless as a contract term. There is no federal regulation defining what an accessible private-sector website is, so the phrase names no standard, no version, no scope and no test. Every bidder can agree to it honestly while planning to deliver something different, and you will not discover the gap until after launch, when fixing it is your problem rather than theirs.

This is a solvable drafting problem. Below is what to put in the document instead, and how to read what comes back.

Name the standard, the version and the level

Write the requirement as a specific conformance target: Web Content Accessibility Guidelines 2.2, Level AA. Three parts, all of them load-bearing.

The standard matters because "accessible" is not a specification and "ADA compliant" is not a standard. The version matters because these are revised periodically and the differences are real. The level matters because AA is the operative tier in essentially every regulation and contract; AAA is not intended to be achievable site-wide and asking for it signals you have copied the phrase from somewhere.

On version, there is a wrinkle worth knowing. The rules that do exist mostly cite older versions than the current one. The Department of Justice rule for state and local government cites WCAG 2.1 AA. The Department of Health and Human Services rule for recipients of its funding also cites 2.1 AA. Section 508, which governs federal agencies and the vendors selling to them, still incorporates WCAG 2.0 AA. The current published recommendation, meanwhile, is 2.2.

The resolution is simpler than it sounds. If a regulation applies to you, name the version that regulation names, because that is the number you will be measured against. Then specify 2.2 AA as the build target anyway. WCAG 2.2 is backward compatible with 2.1, so a site that meets 2.2 meets 2.1 by construction, and you get the newer criteria — target size, focus visibility, accessible authentication, alternatives to dragging — which are the ones that matter most on mobile and for users with motor and cognitive disabilities.

Say what the standard applies to

A conformance target with no defined scope is the second most common drafting failure. Bidders will price the templates. Your risk lives everywhere else.

Spell out that the requirement covers page templates and components, the content management system's authoring interface, PDFs and other documents you publish, forms and their error handling, video and audio content including captions and transcripts, email templates if they are in scope, and any third-party embeds, widgets or integrations.

That last category is where projects come apart. Scheduling widgets, payment flows, chat, maps, review carousels and portal logins are routinely the least accessible things on a finished site, and they are precisely the parts the agency did not build. Decide in the document who is responsible for them, and be realistic: a vendor cannot rewrite somebody else's SaaS product. What they can do is test the integrations, tell you which ones fail, and either configure an accessible alternative or document the gap so you can take it up with that supplier. Ask for that, not for a promise nobody can keep.

Ask for a VPAT, and know what you are reading

A Voluntary Product Accessibility Template is the industry-standard document a supplier uses to report how a product measures against an accessibility standard. The completed document is properly called an Accessibility Conformance Report. In practice people say VPAT for both.

Two distinct asks belong in your RFP, and confusing them is common.

First, ask bidders for conformance reports on work they have already delivered — a site they built for another client, not a marketing claim. This is evidence about the vendor. Second, require a conformance report as a deliverable of your project, produced against the finished site before final payment. This is evidence about your site.

When reports come back, read them properly. Each criterion is marked Supports, Partially Supports, Does Not Support, or Not Applicable, with explanatory remarks. A report that says Supports for every single criterion with no remarks is not a good sign; it is a sign nobody tested. Real reports have partials, and the remarks column is where the honesty lives. Check who produced it and when: a self-assessment from the vendor is worth less than an independent audit, and a report against WCAG 2.0 tells you little about a 2.2 requirement. Note also that a VPAT is a point-in-time statement about a specific version of a product, so one attached to a platform from three years ago describes software that no longer exists.

Require a test method, not just a target

State how conformance will be demonstrated, because otherwise it will be demonstrated with an automated scanner, and automated tools catch only a minority of real barriers. They are good at contrast ratios and missing alt attributes. They cannot tell you whether alt text is accurate, whether a custom component announces its state correctly, whether the focus order makes sense, or whether a task can actually be completed without a mouse.

Ask for automated testing across all templates, manual keyboard-only testing of every key user journey, screen reader testing on a named combination or two, and testing at 200 percent zoom and 320 pixel width. Name the journeys you care about: find a service, complete the main form, make a payment, search, log in. Those are the paths where a failure costs you something.

The four clauses that decide who pays

Everything above describes the work. These decide what happens when it turns out to be incomplete, which it sometimes will.

Acceptance. Conformance is a condition of acceptance, and acceptance is what triggers the final payment. Withhold a meaningful percentage until the conformance report is delivered and reviewed. This single clause does more than the rest of the document combined.

Remediation. Defects against the named standard found within a defined window after launch — twelve months is a reasonable ask — are fixed at the vendor's cost. Define what counts as a defect: a failure against a criterion the contract named, on content the vendor delivered. Not content your team published afterwards, which is your responsibility and should be said out loud.

Authoring. The CMS must make it hard for your editors to break accessibility: enforced heading structure, required alternative text, no colour-only status indicators, an editor interface that is itself usable with a keyboard. A site can be delivered conformant and fail within a month of ordinary publishing. Ask for editor training and a documented content standard as deliverables.

Third parties. Say who tests integrations, what happens when one fails, and who talks to that supplier. Silence here means it becomes your job by default.

How to score the answers

Give accessibility its own weighted line in the evaluation rubric rather than folding it into a general "technical approach" score, where it disappears.

The answers separate quickly. Weak responses restate your requirement back to you, promise full compliance without describing a method, or name an overlay or accessibility widget as the solution. A vendor proposing a toolbar bolted onto an inaccessible site is telling you they do not do this work; overlays do not deliver equivalent access, and a growing body of litigation involves sites that had one installed.

Strong responses name their testing tools and their manual process, tell you which staff do the testing and what their training is, show a conformance report from real delivered work, and — the best signal of all — raise something in your own requirements that will be difficult, expensive or impossible as written. A bidder who tells you at proposal stage that your legacy document library is a bigger problem than your website is a bidder who has actually looked.

A short version you can paste

If you take nothing else from this, four sentences in your requirements section will do most of the work. The supplier shall deliver conformance with WCAG 2.2 Level AA across templates, components, documents, forms, media and the authoring interface. Conformance shall be demonstrated by automated testing plus manual keyboard and screen reader testing of the user journeys listed in this document, and reported in an Accessibility Conformance Report delivered before final acceptance. Defects against this standard in delivered work shall be remediated at the supplier's cost for twelve months after launch. Bidders shall submit an Accessibility Conformance Report for a comparable site they have delivered.

Adapt the wording to your procurement rules, and have counsel review it if the contract is significant. But the shape is right, and it is enormously better than a sentence asking for an ADA compliant website.

Related reading

If you are still drafting the wider document, our website RFP template covers the sections around this one, and the red flags to watch for in the proposals that come back includes several that are specific to accessibility claims. Public bodies should also read our guide to the ADA Title II rule, and healthcare organizations the HHS web accessibility rule, since both name a standard and a date that your RFP should simply inherit.

When your document is ready, you can send it to us, and our RFP submission process sets out what happens next.