Process

Accessibility in Procurement Requirements

By EZUD Published · Updated

Accessibility in Procurement Requirements

Every third-party tool, platform, and service your organization purchases becomes part of the user experience. If a procurement decision introduces an inaccessible tool, the organization inherits accessibility barriers that it did not create and may not be able to fix. Accessibility procurement requirements ensure that vendors meet your standards before their products are deployed.

Why Procurement Matters

Organizations increasingly depend on third-party software: CMS platforms, analytics tools, collaboration suites, learning management systems, customer support platforms, and more. If any of these tools are inaccessible, they create barriers for employees with disabilities (internal tools) or customers with disabilities (customer-facing tools).

In the United States, Section 508 of the Rehabilitation Act requires federal agencies to procure accessible information and communication technology (ICT). The European Accessibility Act (EAA) and EN 301 549 impose similar requirements in the EU. Even in the private sector, organizations with accessibility commitments must ensure their supply chain supports those commitments.

What to Include in RFPs and Contracts

Conformance Requirements

  • Specify the standard: “The product must conform to WCAG 2.2 Level AA” or “The product must meet EN 301 549 requirements.”
  • Request a current VPAT/ACR (Voluntary Product Accessibility Template / Accessibility Conformance Report) as part of the vendor’s response.
  • Require that the VPAT be specific to the product version being offered, not a generic corporate statement.

Evaluation Criteria

  • Weight accessibility alongside functionality, price, and security in the evaluation scorecard. If accessibility is not scored, it will not influence the decision.
  • Conduct your own accessibility evaluation of the product during the trial or demo phase. Do not rely solely on the vendor’s VPAT.
  • Test with screen readers (NVDA, JAWS, VoiceOver), keyboard navigation, and magnification during product demos.

Contractual Obligations

  • Include accessibility conformance as a contractual requirement, not just a preference.
  • Require the vendor to remediate accessibility defects within a defined timeline.
  • Include the right to audit the product for accessibility at any time.
  • Require the vendor to provide an updated VPAT with each major release.
  • Specify that accessibility regressions introduced in updates will be treated as defects.

Ongoing Accountability

  • Require the vendor to disclose known accessibility issues and their remediation timeline.
  • Include accessibility in service-level agreements (SLAs) where applicable.
  • Require the vendor to support your accessibility testing by providing sandbox environments or test accounts.

Evaluating a VPAT/ACR

Not all VPATs are created equal. When reviewing a vendor’s VPAT:

  • Check the date. A VPAT older than two years may not reflect the current product.
  • Check the version. The VPAT should correspond to the product version being sold.
  • Read the “Remarks and Explanations” column. Vague language like “partially supports” without explanation is a red flag.
  • Look for “Does Not Support” entries. These represent known barriers that will affect your users.
  • Cross-reference with your own testing. If the VPAT claims “Supports” for keyboard navigation but your testing finds keyboard traps, the VPAT is inaccurate.

See VPATs and ACRs explained for a complete guide.

Building Internal Procurement Processes

Create an accessibility evaluation checklist

Develop a standard checklist for evaluating vendor products. Include automated scanning results, keyboard testing results, screen reader testing results, and VPAT review findings.

Train procurement staff

Procurement professionals do not need to become accessibility experts, but they need to know:

  • Why accessibility matters in procurement
  • How to read a VPAT
  • When to engage an accessibility specialist for product evaluation
  • What accessibility language to include in contracts

Establish a review workflow

For all technology purchases above a defined threshold, require accessibility review before approval. This review can be conducted by the accessibility team, an accessibility champion, or an external evaluator.

Maintain a vendor accessibility scorecard

Track vendor accessibility performance over time. Which vendors consistently deliver accessible products? Which vendors require repeated remediation requests? Use this data to inform future procurement decisions.

Connecting to Governance

Procurement requirements are a component of the broader accessibility governance framework. They ensure that accessibility standards extend beyond internally developed products to encompass the entire technology ecosystem.

Procurement data also feeds into accessibility metrics and maturity assessments.

Key Takeaways

  • Third-party tools that are inaccessible create barriers your organization cannot easily fix.
  • Require WCAG 2.2 Level AA conformance and current VPATs in RFPs and contracts.
  • Conduct your own accessibility evaluation during trials; do not rely solely on vendor claims.
  • Include accessibility remediation obligations and audit rights in contracts.
  • Train procurement staff, establish review workflows, and track vendor accessibility performance over time.

Sources

More in Process

Inclusive Design Process Guide: Building Accessibility Into Every Stage Guide Continuous Accessibility Monitoring Accessibility in Design Reviews Nothing About Us Without Us: The Principle That Shapes Inclusive Design

View all Process articles →