Accessibility Requirements in RFPs: A Vendor's Guide to Answering Them Well

Accessibility requirements in RFPs have become standard for software sold to the public sector and to large organizations. If you sell a SaaS product or other software to governments, universities, colleges, hospitals or enterprises, expect the solicitation to ask for four things: conformance with a named standard (usually WCAG 2.1 or 2.2 Level AA, or EN 301 549 in Canadian federal and European bids), an Accessibility Conformance Report (ACR) written on the ITI VPAT template, a roadmap for anything that doesn't yet conform, and a contractual commitment to fix issues and keep the report current.

The best answers are specific and honest. Buyers expect most products to have gaps. "Partially Supports" with a clear remark and a fix date is a normal, credible answer. "Fully compliant" with no evidence is the answer that worries an evaluator.

This guide covers why buyers ask, what the clauses usually look like, which report edition they want, how Canadian public procurement uses EN 301 549, and a checklist you can work through before the submission deadline.

Why accessibility shows up in procurement requirements

Buyers aren't adding these clauses on a whim. In many cases, their own legal or policy obligations require it.

Ontario's public sector

Under section 5 of the AODA's Integrated Accessibility Standards Regulation, the Government of Ontario, the Legislative Assembly and designated public sector organizations must incorporate accessibility design, criteria and features when procuring or acquiring goods, services or facilities, except where it isn't practicable. If they decide it isn't practicable, they must explain why on request. Designated public sector organizations include municipalities, school boards, hospitals, colleges, and universities that receive provincial operating grants. That is why a hospital or university RFP for even a modest software tool will usually ask about accessibility.

Ontario buyers also have to meet the AODA's website rule for their own sites, which covers web content "including web-based applications" that they control directly or through a contract that allows the product to be modified. A vendor's portal can become part of the buyer's compliance picture.

Federal and federally regulated buyers

The Accessible Canada Act requires federally regulated entities to identify, remove and prevent barriers in priority areas that include information and communication technology and procurement. The Government of Canada's guide for including accessibility in ICT-related procurement tells business owners to require suppliers to submit an ACR, preferably on the VPAT template, and prefers that it be prepared by a third party with professional testing expertise or by experienced in-house specialists. The same guide notes that under the Directive on the Management of Procurement, the business owner must provide a written justification when they don't include accessibility requirements.

Enterprises and buyers outside Canada

US federal agencies buy against the Revised Section 508 Standards, and buyers in the EU work with EN 301 549. Large private companies increasingly set their own accessibility policies for the tools their employees and customers use. If you sell across borders, you may get three different versions of the same question in one quarter.

What accessibility clauses in RFPs typically ask for

The wording varies, but most accessibility procurement requirements are built from the same parts.

Conformance with a named standard

Typically "WCAG 2.1 Level AA" or "WCAG 2.2 Level AA", or "EN 301 549" for Canadian federal and European buyers. Read the version number carefully: if the RFP names WCAG 2.2, the six Level A and AA success criteria added in 2.2 are in scope, and an ACR that stops at 2.1 doesn't answer the question.

An ACR, usually on the latest VPAT

Most buyers ask for a completed Voluntary Product Accessibility Template, often specifying "the latest version". Some ask for it with the bid, others at contract award. If the terminology is new to you, our ACR and VPAT reports page explains the difference between a VPAT, an ACR and a certification.

Evidence of who tested it

Evaluators increasingly ask how the report was produced: who did the testing, with which tools and assistive technologies, and when. A report with a methodology section and a recent date carries more weight than one with no testing described.

A remediation roadmap

Where your product doesn't fully conform, expect to be asked for a roadmap: which criteria fail, what you'll change, and by when. Some buyers make an award conditional on it and check progress at renewal.

Contract commitments

Clauses often require the vendor to fix accessibility defects within an agreed period, to provide an updated ACR after significant releases (or at least annually), and to keep documentation, training material and support channels accessible too.

Hands-on testing during evaluation

Some buyers test a demo or trial account themselves, with a keyboard and a screen reader, and compare what they find with your ACR. Assume your answers will be checked.

Which VPAT edition the RFP is asking for

The Information Technology Industry Council (ITI) publishes the VPAT. The current version is VPAT 2.5Rev, and it comes in four editions. The edition tells you which standard the report is measured against.

If the RFP doesn't say which edition it wants, ask through the clarification process. If you sell into Canada, the US and Europe, the International edition saves you maintaining three separate reports.

EN 301 549 in Canadian procurement

In May 2024, Accessibility Standards Canada published CAN/ASC-EN 301 549:2024, an identical adoption of the European standard EN 301 549 (V3.2.1, 2021). It is a voluntary national standard; Accessibility Standards Canada doesn't enforce it. The federal procurement guide describes it as "not yet mandatory" for the Government of Canada, while strongly encouraging departments to use it. So you'll see it referenced in federal solicitations, but don't assume every Canadian buyer requires it, and don't tell a buyer it's the law when their RFP says otherwise.

What matters for vendors is scope. EN 301 549 goes beyond web pages. Its web requirements (clause 9) mirror WCAG 2.1 Level A and AA, but it also has clauses for non-web documents (clause 10), software (clause 11), and documentation and support services (clause 12), plus hardware and two-way voice and video communication. A desktop app, your PDF user guide and your help desk can all be in scope. If your documentation is mostly PDFs, it's worth checking them early, or bring in document accessibility remediation before the bid.

How to answer accessibility requirements in RFPs honestly

Evaluators read a lot of accessibility answers. The ones that hold up have the same qualities.

• Use the real conformance levels. The VPAT defines four: Supports, Partially Supports, Does Not Support and Not Applicable. "Partially Supports" is common and acceptable when the remark explains exactly what fails.
• Write remarks a buyer can verify. "Placeholder text in the search field is below 4.5:1 contrast" is checkable. "Some minor issues may exist" is not.
• Don't mark criteria Not Applicable to hide failures. If your product has video, captions apply. An evaluator who spots one misused N/A will doubt the rest.
• Never rely on an overlay. A third-party widget doesn't change your product's code. Our article on accessibility overlays and compliance explains why buyers treat these with suspicion.
• Keep the RFP answer and the ACR consistent. If the questionnaire says "fully WCAG 2.2 AA conformant" and the attached ACR has twelve Partially Supports, the evaluator will notice.
• Pair every gap with a plan. A gap with a remediation date is a managed risk; a gap with no plan is an open one.

Weak answer: "Our platform is fully accessible and compliant with all applicable accessibility laws and standards."

Strong answer: "Our platform partially conforms to WCAG 2.2 Level AA, based on a manual audit completed in [month, year] by an external tester. The attached ACR (VPAT 2.5Rev, WCAG edition) lists each criterion. The main gaps are keyboard access to the drag-and-drop scheduler (2.1.1) and contrast on two status badges (1.4.3). Both are scheduled for our [quarter] release; the roadmap is attached. We will provide an updated ACR after that release and at least annually."

The strong answer admits more problems and still scores better, because it shows the vendor knows its product, has tested it and will be a reliable partner after the contract is signed. Turning audit findings into a credible timeline is its own skill; our guide to building an accessibility remediation plan walks through it.

Accessibility RFP response checklist

Work through this list as soon as the RFP lands, not the week it's due.

1. Find every accessibility requirement in the solicitation, including ones buried in technical, security or contract sections.
2. Note the exact standard and version named (WCAG 2.0, 2.1, 2.2, Section 508, EN 301 549) and whether accessibility is a mandatory pass/fail item or a rated criterion.
3. Confirm which VPAT edition is wanted, and ask a clarification question if the RFP doesn't say.
4. Check that your ACR is current: it matches the product version you're bidding, uses the current VPAT version, and has a recent date. If it doesn't, plan the testing now.
5. Make sure the ACR says how the product was tested, by whom, and with which assistive technologies.
6. Prepare a roadmap with dates for every Partially Supports and Does Not Support item.
7. Cover the whole offering: web app, mobile apps, documentation, training material and support channels, especially for EN 301 549 bids.
8. Read the contract language for remediation timelines and ACR update obligations, and confirm your team can meet them.
9. Have someone outside the sales team check that the written answers and the ACR say the same thing.
10. Prepare a demo account that works with a keyboard and screen reader, in case the buyer tests it.

Frequently asked questions