What is the single most important requirement to put in an accessibility RFP?

How the sample is defined. Almost every disappointing accessibility engagement traces back to a scope line that says 'the website' and a proposal that quietly reads it as fifteen representative pages. Fifteen pages is a legitimate methodology — it is what a manual audit can do properly — but it is a different purchase from coverage of every template, every authenticated flow and every PDF you distribute. Write the sample yourself: name the templates, name the transactional journeys end to end including checkout and account creation, state whether logged-in areas are in scope, and state how many documents. A bidder who then prices it higher has not overcharged you; they have quoted the job you actually described.

Should the RFP require WCAG 2.1 AA or WCAG 2.2 AA?

Require the version your obligations actually reference, then ask for the newer one as a separately-priced addendum. US public entities under the Department of Justice's Title II web rule are pointed at WCAG 2.1 Level AA, and private-sector settlements have overwhelmingly used the same yardstick, so 2.1 AA is what most organisations are measured against today. WCAG 2.2 AA adds criteria on top rather than replacing them, so a 2.2 audit is a superset — useful to have, but do not let it become a reason for a bidder to price a bigger job than your obligation requires. The failure mode to avoid is the opposite one: an RFP that says 'accessible' or 'ADA compliant' with no standard named at all, which lets each bidder pick their own bar and makes the proposals incomparable.

Do we need to ask for a VPAT or an ACR?

If you sell to government, to universities, or to any enterprise with a procurement checklist, yes — and ask for it in the current version of the template with a real evaluation behind it. A VPAT is the blank form; an Accessibility Conformance Report is the completed one. The distinction matters in an RFP because 'we will provide a VPAT' is a promise to fill in a document, not a promise about its contents, and a report full of 'Supports' with no explanatory remarks is the usual result. Require remarks for every criterion, require the evaluation methods and the tested product version to be stated, and require that criteria be marked 'Partially Supports' or 'Does Not Support' where they are — an honest ACR with known gaps survives a procurement review that a uniformly green one does not.

How do we compare bids that vary five-fold in price?

Normalise on the unit of work before you look at the totals. Ask every bidder for the same three numbers: how many unique pages or screens will be manually tested, how many hours of assistive-technology testing that includes and with which combinations, and how many retests are in the base price. A wide price range almost always resolves into an automated scan plus a summary at one end and manual testing with screen readers at the other, and those are different products that happen to share a name. The second normaliser is the deliverable format — a spreadsheet of findings keyed to a URL, an element selector and a success criterion is worth several times a narrative PDF, because only one of them can be pasted into a ticket queue.

Should retests be part of the same contract?

Yes, and the number should be in the base price rather than in a change order. An audit without a retest measures the problem and stops, which leaves your team guessing whether a fix satisfied the criterion or merely changed the symptom. Specify at least one full retest of all reported findings within a stated window after delivery, plus a mechanism for spot-checking individual fixes as they ship rather than in a single batch at the end. The commercial reason is simple: a vendor who has priced the retest has an incentive to write findings clearly enough that your developers can act on them the first time.

Accessibility Vendor RFP 2026: The Requirements That Decide What You Get

"The Website" Is Not a Scope

A scope line that says "audit our website against WCAG" is read by every competent bidder as a sample. That is not evasion — a manual audit is human work and cannot cover a hundred thousand URLs — but it means the most consequential decision in the engagement is being made inside a proposal you have not written, and each bidder will make it differently. The result is a set of quotes that cannot be compared, followed by a report that covers less than the person who signed it assumed.

Write the sample into the RFP yourself and the problem disappears in both directions. Enumerate the templates rather than the pages: home, category listing, detail, search results, article, form, dashboard, error states. Enumerate the journeys end to end, because the failures that generate complaints live in multi-step flows rather than on landing pages — registration, login and password reset, checkout or application submission, and anything involving a date picker, a file upload or a timed session. State explicitly whether authenticated areas are in scope, because a vendor who has not been given credentials cannot test them and will quietly exclude them.

Named templates, not a page count — and say how many instances of each.
Transactional journeys listed step by step, including failure and error states.
Authenticated areas: in or out, with credentials provided if in.
Native mobile apps and any embedded third-party widget, named individually.
Documents: how many PDFs, which ones, and whether remediation is included.
Breakpoints and assistive-technology combinations to be tested.

Specify the Evidence, Not Just the Standard

The difference between a useful audit and an expensive one is almost entirely the shape of each finding. A narrative paragraph explaining that colour contrast is insufficient across the site is true and unusable. A row that names the URL, the element selector, the specific success criterion, the assistive technology and browser it was reproduced in, the observed behaviour, the expected behaviour and a suggested remediation is a ticket. Ask for the second thing, in a machine-readable format, and say so in the requirements rather than hoping.

Severity is worth specifying too, and worth defining rather than delegating. Vendors use their own scales, and a report where a third of the items are "critical" ranks nothing. A workable request is a two-axis rating — user impact and frequency across the sample — plus a stated rule for what counts as a blocker. Then ask for the findings to arrive as a spreadsheet or an export your issue tracker can ingest, with a stable identifier per finding so the retest can reference it.

Automated Coverage Is a Baseline, Not a Bid

Automated testing reliably catches a minority of WCAG success criteria — missing alternative text, unlabelled form controls, contrast ratios, heading order, language attributes, obvious ARIA misuse. That minority is genuinely worth having and it costs almost nothing, which is precisely why it should not be what you are paying a consultancy for. Run a scan before the RFP goes out so you know roughly what the automatable layer looks like, and require bidders to state what proportion of their proposed findings will come from tooling versus from a person.

What only a person can tell you: whether the focus order makes sense, whether an error message is announced, whether a custom component behaves like the control it imitates, whether alternative text is accurate rather than merely present, and whether a flow can be completed with a screen reader at all. Price those hours explicitly. An RFP that asks for "a WCAG audit" without separating these layers invites a bid that is a scan with a cover page, and that bid will win on price.

The Retest Is Where the Money Is Made or Lost

An audit without a retest is a measurement with no closing loop. Your team ships fixes, and nobody with the original methodology confirms whether the criterion is now met — so the next audit, a year later, rediscovers half of them. Put a defined number of retests in the base price, against the original finding identifiers, within a stated window. Ask for incremental verification as fixes ship rather than one batch at the end, since a developer who learns on Tuesday that Monday's approach was wrong does not repeat it across forty components.

Two adjacent clauses are worth the same attention. First, developer access: a stated number of hours where your engineers can ask the auditor questions directly, which converts a report into knowledge transfer. Second, a re-audit trigger for material redesigns, so a template rebuild six months in does not silently invalidate the conformance position you are relying on.

Ownership, Confidentiality and What Happens If You Leave

Accessibility findings are a documented list of the ways your product currently fails people with disabilities. That is exactly what you need internally and exactly what you do not want distributed, so say who owns the report, what the vendor may retain, and whether your organisation can be named as a client or in a case study. Where counsel is involved, decide early whether the engagement is being run under privilege, because that is a structural decision about who signs the contract rather than a label applied afterwards.

Then ask the exit question for any tooling bundled into the deal. Monitoring platforms accumulate a history of scans, issue states and dismissals, and that history is the part you cannot rebuild. Require an export in an open format, on demand and at termination, and confirm what happens to the data afterwards. A vendor whose answer is a screenshot-only dashboard has told you what switching costs will look like in year three.

Questions Procurement Teams Are Asking

How many pages should we ask to have manually tested?

Work from templates rather than from a target number. Count the distinct page templates in your system, add each step of every transactional journey as its own screen, add the error and empty states, and that list is your floor. For most mid-sized sites it lands somewhere between twenty and sixty screens, which is a very different brief from 'ten representative pages' and a much cheaper one than 'the whole site'. If budget forces a cut, cut breadth of templates rather than depth of journeys — a half-tested checkout is worth less than an untested marketing page is risky.

Is it a conflict of interest if the auditor also does the remediation?

Not inherently, and for many teams the combined engagement is the practical choice, but structure it so the marking is not done by the person being marked. The usual arrangement is one contract with separated deliverables and an independent retest — either a different team inside the vendor or a second firm for the final verification. What you should avoid is the pattern where remediation is sold as a subscription and the same subscription produces the conformance claim, because then the number that says you are improving is generated by the party being paid to improve it.

The bidder says they cannot guarantee compliance. Is that a red flag?

No — it is the honest answer, and a bidder promising guaranteed compliance or immunity from complaints is the one to worry about. Conformance is a statement about a tested scope at a tested moment, and your site changes weekly. What a vendor can commit to is methodology, sample coverage, the standard applied, the testing combinations used and the retest. Put those in the contract as obligations and treat any 'guarantee' language as marketing, particularly where it appears alongside an overlay product.

Should we require experience in our specific industry?

Require relevant technology experience; treat industry experience as a tiebreak. What actually changes the quality of an audit is whether the auditor has tested your kind of interface before — a single-page application with a custom component library, a data-heavy dashboard, a native mobile app, a PDF-heavy document estate. An auditor fluent in your framework's accessibility failure modes will find things a generalist misses. Sector familiarity matters mainly where the journeys are regulated or unusual, such as patient portals, benefits applications and student information systems.

What should we do before the RFP goes out at all?

Run an automated scan over the templates you intend to put in scope and read the output. It costs nothing, and it changes the conversation twice: you arrive knowing which of your problems are the cheap machine-detectable kind, and you can tell instantly whether a bid is quoting you for work a free tool already did. It also gives you a dated baseline, which is the thing that makes the post-engagement retest readable as progress rather than as a new opinion.

Know the Automatable Layer Before You Pay for It

The cheapest way to make an accessibility RFP comparable is to arrive with your own baseline. Scan the templates you plan to put in scope, read what the machine layer finds, and write the sample and the evidence format around what is left — the part that needs a person.

Then judge every bid on four lines: the sample it names, the shape of one example finding, the number of retests in the base price, and who owns the report afterwards.