Procurement & RFP Pathway

What it means in practice

Put accessibility in the mandatory technical requirements section of the RFP. Not the desirable section. Vendors who can't meet the bar get filtered out at the first technical evaluation, long before contract signing. The minimum bar should reference EN 301 549 (specify the version — v3.2.1 at the time of writing) and require WCAG 2.1 Level AA conformance with an upgrade path to WCAG 2.2 within 12 months. Require the vendor to provide a current VPAT or ACR as part of the bid response. Make them describe their accessibility testing process: who tests, how often, with what tools. The RFP Generator on this site produces a 12-point requirement set you can drop straight into any tender. It covers the standard clauses, the documentation requirements, and the ongoing obligations. Treat it as a baseline and add product-specific requirements as needed. For scoring, give accessibility real weight in the technical evaluation. At least 10% of the technical score, more if the product is consumer-facing. Make it worth 2% and vendors will treat it as a checkbox. Make it worth 15% and they'll resource it properly. Don't accept 'we're WCAG compliant' as an answer. WCAG has multiple versions, three conformance levels, and conformance is per-criterion, not per-product. Demand specifics. Which version. Which level. What exceptions exist. What got tested. By whom. When.

Common pitfalls

• ×Listing accessibility as 'desirable' rather than 'mandatory'. Vendors respond to the criteria you set.
• ×Accepting 'WCAG compliant' as a finished answer. There's no such thing as generic WCAG compliance — version, level, and exceptions all matter.
• ×Skipping the documentation requirement entirely. A vendor with no VPAT can't be evaluated, and shouldn't be shortlisted.

How to verify it

Look at your last three RFPs. For each one: was accessibility in the mandatory section? Did it reference EN 301 549 and a specific WCAG version? Was a VPAT required? Did the scoring give accessibility meaningful weight? Any 'no' is something the next RFP fixes. For existing contracts, the realistic move is to introduce an accessibility addendum at renewal. Most vendors will accept it. The ones who push back are the ones whose products you'd want to replace anyway.

What it means in practice

Read the whole VPAT, not just the summary. The summary will say 'WCAG 2.1 AA compliant'. The body tells you which criteria are 'Supports', 'Partially Supports', 'Does Not Support', or 'Not Applicable', with remarks for each. The actual truth is in the remarks column. Red flags to watch for: a VPAT older than 12 months (the product has moved on, the document is stale), 'Not Applicable' on criteria that obviously do apply (the vendor is hiding gaps), 'Supports' with no remarks at all (no evidence of testing), 'Partially Supports' with vague remarks like 'in progress' (the gap exists and there's no commitment behind fixing it). Cross-check the VPAT against the actual product. Ask for a demo account. Run automated tests against representative pages. Do the keyboard test on the core flows. If the VPAT says 'Supports' for keyboard access and the demo product has a keyboard trap, the VPAT is wrong and you've got grounds to escalate. For critical systems, ask for the vendor's underlying test evidence — the Annex C test plan and the results, not just the summary. A vendor who can't produce them hasn't done the testing they claim. Walk away. If you're a vendor preparing your own VPAT or ACR, the VPAT/ACR Editor on this site walks through the structure. Be honest about gaps. An accurate VPAT with documented limitations is worth more than an inflated one that gets challenged.

Common pitfalls

• ×Taking the VPAT summary at face value. The summary is sales material. The body is the actual document.
• ×Not checking the VPAT's date. A two-year-old VPAT against a product that has shipped four major releases tells you nothing about the current state.
• ×Treating 'Partially Supports' as 'good enough'. Partial support is a known gap that ships straight to your users.

How to verify it

For each shortlisted vendor, score the VPAT on four things: recency (within 12 months), completeness (all relevant criteria addressed), specificity (real detail in the remarks, not boilerplate), and honesty (gaps documented, not hidden). A vendor that scores poorly on any of those is a procurement risk regardless of the headline 'compliant' claim. Wherever you can, validate one or two claims independently. Ask for a demo account, pick a criterion the VPAT says 'Supports', and test it yourself. If the test passes, your trust in the rest of the document goes up. If it fails, your trust evaporates and you have a documented basis to push back.

What it means in practice

Keep a vendor risk register that tracks accessibility status alongside the usual security and finance risks. For each active vendor: their operator role, their conformance evidence (VPAT date and version), their last review date, and a RAG status. Vendors with stale or missing evidence go on the remediation list. For critical vendors — the ones whose product is embedded in your customer-facing service — book in annual review meetings. Ask them to show progress against the gaps in their last VPAT. Ask about their test process. Ask whether WCAG 2.2 conformance is on their roadmap. If they can't answer those questions, escalate. For commodity vendors, where you have hundreds of them and can't review every one individually, pick a sampling regime. Five vendors per quarter, prioritised by risk (consumer-facing, customer data, payment flows). Five per quarter is 20 per year, which is enough to catch systematic issues across a portfolio of 100+. When a vendor turns out to be non-conformant, you've got three options: get them to fix it (preferred), build a workaround (interim), or replace them (last resort). Each one has cost and time implications. Document the choice and the reasoning — that's part of your conformity assessment too. The Supply Chain Compliance Checklist and Compliance Programme Template on this site give you structured approaches for all of this. Use them to formalise what's currently informal, and to give the conversation a shape when you bring it to leadership.

Common pitfalls

• ×Treating accessibility risk as separate from security and finance risk in the vendor register. They get reviewed differently and accessibility quietly falls behind.
• ×Reviewing vendor accessibility once at onboarding and never again. Vendors regress, VPATs go stale, products change.
• ×Replacing a non-conformant vendor without verifying the replacement is any better. You've inherited a different non-conformance instead of fixing the problem.

How to verify it

Pull 10 vendors from the register at random. For each one: do they have a current VPAT (within 12 months), has anyone reviewed it, is the review documented, is there a follow-up action? If most answers are no, the register is decoration and you need to either resource the reviews properly or shrink the scope to something you can actually maintain.