Procurement and Vendor Accessibility

Procuring inaccessible software exposes your organization to legal liability and creates barriers for employees and clients with disabilities. Canadian law — the Accessible Canada Act, AODA, and provincial human rights codes — applies to technology you purchase just as it applies to technology you build. This page provides practical guidance for procurement teams, including how to write RFP requirements, evaluate vendor claims, and enforce accessibility in contracts.

Why accessibility in procurement matters

When you purchase software — an HR system, a customer portal, a content management system, a learning management system — you inherit its accessibility properties. If the vendor’s product is not accessible:

  • Employees with disabilities may be unable to use internal tools — exposing you to CHRA and provincial human rights complaints
  • Customers with disabilities may be unable to use your service — exposing you to AODA or ACA non-compliance
  • You cannot remediate what you do not control — if the vendor does not fix it, you are stuck
  • Retrofitting accessibility later, if the vendor offers customization, is expensive and time-consuming

A procurement process that evaluates accessibility properly costs a few hours of additional evaluation. Remediating an inaccessible system post-purchase can cost tens of thousands of dollars — or require replacing the system.

Accessibility in RFPs

Leadership

Minimum requirement language

Include explicit accessibility requirements in every RFP for software that will be used by employees, clients, or the public:

The vendor must demonstrate that the proposed solution meets WCAG 2.1 Level AA as the minimum standard. Supporting evidence must include a current Voluntary Product Accessibility Template (VPAT) or Accessibility Conformance Report (ACR) completed within the past 12 months, covering the specific modules included in this proposal. The organization reserves the right to conduct independent accessibility testing prior to contract award and at defined intervals during the contract term.

Minimum RFP requirements

Include these as pass/fail or rated criteria:

  1. Conformance report: Current VPAT/ACR (within 12 months) for the specific product version proposed
  2. Standard: WCAG 2.1 AA minimum; WCAG 2.1 AAA preferred for customer-facing content
  3. Testing evidence: Describe the testing methodology used to produce the VPAT (automated only, manual, user testing with disabled users)
  4. Known issues: List of documented accessibility issues and remediation roadmap with dates
  5. Remediation commitment: SLA for fixing accessibility bugs reported during the contract term
  6. Training materials: Are training materials for the system accessible?
  7. Customization: If the organization customizes the interface, does the vendor confirm that customization does not break WCAG compliance?
  8. Updates: Does the vendor commit to maintaining WCAG compliance through software updates?

Weighted evaluation criteria

For scored RFP criteria, suggested weighting for accessibility:

CriterionWeight (example)
Provides current VPAT/ACR5 points
VPAT demonstrates WCAG 2.1 AA conformance10 points
Testing methodology includes manual and user testing5 points
Documented remediation roadmap for known issues5 points
Contractual accessibility SLA offered5 points
Total accessibility30 points (adjust relative to other criteria)

Understanding VPATs and ACRs

What is a VPAT?

The Voluntary Product Accessibility Template (VPAT) is a document format created by the IT Industry Council (ITI) in which vendors self-report how their product conforms to accessibility standards. The completed VPAT is called an Accessibility Conformance Report (ACR).

VPATs exist for several standards frameworks:

  • VPAT 2.x (WCAG 2.x) — the version relevant for Canadian web and software procurement
  • VPAT 508 — US Section 508 (less relevant for Canada, though the technical standards largely overlap)
  • VPAT EU — EN 301 549 (the European standard, referenced by the ACA)
  • VPAT INT — covers all three frameworks (most comprehensive)

For Canadian procurement, request the VPAT WCAG edition or the VPAT INT edition.

How to read a VPAT

Each WCAG success criterion is listed with one of these conformance levels:

VPAT ratingMeaning
SupportsThe feature meets the criterion without exception
Partially SupportsSome functionality meets the criterion; exceptions exist
Does Not SupportThe criterion is not met
Not ApplicableThe criterion does not apply to this product/feature
Not EvaluatedThe criterion has not been tested

Red flags in VPATs:

  • “Not Evaluated” for many criteria — the vendor has not tested their product
  • “Partially Supports” with no explanation of what the exceptions are
  • VPAT dated more than 12–18 months ago — may not reflect the current product version
  • VPAT covers only part of the product (e.g., only the main interface, not the admin module)
  • No description of the testing methodology used to produce the report
  • “Supports” for criteria that are commonly failed and technically complex — without evidence, this claim is unverifiable

What a credible VPAT looks like

A credible VPAT:

  • Names the specific product version and release date
  • Names the testing methodology: automated scan tool, screen readers tested, user testing (yes/no)
  • Provides remarks explaining any “Partially Supports” claim — what works, what does not, workarounds
  • Acknowledges known issues honestly
  • Is dated within the past 12 months
  • Is produced by a named third party or internal accessibility team, not just marketing

Evaluating vendor accessibility claims

Independent testing

Never rely solely on a vendor’s VPAT. Before contract award for significant purchases, conduct or commission independent testing:

  1. Request a demo environment — most enterprise vendors provide sandbox environments for evaluation
  2. Run automated scans — axe DevTools on the key flows: login, primary task completion, settings, help
  3. Keyboard walkthrough — complete the primary user flow by keyboard only; note failures
  4. Quick screen reader check — NVDA+Chrome through the login and primary task flow

This evaluation takes 2–4 hours for a mid-sized application. It is not a full audit — it is a due diligence check that reveals whether the VPAT claims are plausible.

Questions to ask vendors

Before shortlisting:

  • What WCAG version and level does your product conform to?
  • When was your most recent third-party accessibility audit?
  • What is your process for accessibility testing new features?
  • Do you have an internal accessibility team or designated accessibility lead?
  • What is your SLA for fixing accessibility bugs reported by customers?
  • Are your release notes accessible to customers who use screen readers?

Red flags in vendor responses

  • “We are compliant with all applicable standards” with no specifics
  • VPAT for a different product version or substantially older version
  • No awareness of WCAG 2.1 (still referencing only 2.0)
  • No testing methodology described
  • No named person responsible for accessibility
  • “Accessibility is on our roadmap” — implies it is not a current reality

Contract language

Leadership

Accessibility requirements must be in the contract, not just the RFP. Verbal commitments and pre-sales representations do not survive vendor account manager turnover.

Conformance standard

The Vendor warrants that the Software meets WCAG 2.1 Level AA at the time of contract execution. The Vendor will provide an updated Accessibility Conformance Report (ACR) within 30 days of any major release or upon written request.

Defect resolution SLA

The Vendor will classify and remediate accessibility defects as follows:

  • Critical (blocks task completion for users with disabilities): acknowledged within 2 business days, remediation plan within 5 business days, fix deployed within 30 days
  • Serious (significantly impedes task completion): acknowledged within 5 business days, fix deployed within 60 days
  • Moderate (creates friction but workaround exists): included in next major release

Regression prevention

The Vendor will not introduce new WCAG 2.1 AA failures in updates to the Software. In the event that an update introduces new accessibility failures, the Vendor will revert or patch the update within the timelines specified in the defect resolution clause.

Right to audit

The Organization reserves the right to conduct accessibility audits of the Software using independent auditors at the Organization’s expense, and to share audit results with the Vendor. The Vendor will respond to audit findings within 30 days with a remediation plan.

Training and documentation

The Vendor will ensure that user documentation and training materials for the Software are available in accessible formats (WCAG 2.1 AA conformant HTML) at no additional charge.

Ongoing vendor management

Accessibility does not end at contract signing. Build it into the vendor relationship:

Annual review

  • Request an updated VPAT annually
  • Run an independent accessibility check on the current version annually
  • Review the vendor’s published release notes for accessibility improvements or regressions
  • Assess any new modules or features added since the last review

Reporting accessibility issues

  • Assign a named internal contact for reporting accessibility issues to the vendor
  • Track reported issues in your internal system — if the vendor does not fix them, you have documentation of the breach
  • Escalate unresolved critical issues to account management and legal as required

At contract renewal

If the vendor has not met accessibility commitments during the contract term:

  • Document the failures with evidence
  • Use them as leverage in renewal negotiations
  • Consider whether the vendor’s accessibility posture has improved enough to justify renewal
  • Evaluate alternative products that may be more accessible

Accessible procurement for services

Procurement of consulting and creative services (web agencies, design studios, communications firms) requires different accessibility considerations:

RFP requirements for services firms

  • Does the firm have trained accessibility practitioners on staff?
  • Does the firm conduct accessibility testing as part of standard project delivery?
  • Can the firm provide examples of accessible work with evidence of WCAG conformance?
  • Does the firm’s standard project methodology include accessibility reviews at design and development stages?
  • Will the deliverables include an accessibility conformance report?

Statement of work language

All web deliverables under this contract must meet WCAG 2.1 Level AA. Deliverables include an Accessibility Conformance Report (ACR) prepared by a trained accessibility practitioner. The contractor will remediate any WCAG 2.1 AA failures identified within 30 days of delivery at no additional cost.