Digital Accessibility Procurement That Holds Up

A signed contract cannot make an inaccessible product accessible. Digital accessibility procurement must establish what compliance means, which standards apply, how performance will be verified, and what happens when defects are found. Without those controls, an organization can buy a platform that looks compliant in sales materials but creates barriers for employees, students, residents, customers, and other users.

For public agencies, educational institutions, and businesses with legal exposure, accessibility needs to be evaluated as a functional requirement alongside security, privacy, integrations, pricing, and support. The procurement process is where your organization has the most leverage to require evidence, set remediation timelines, and avoid inheriting costly accessibility debt.

Start Digital Accessibility Procurement Before the RFP

Accessibility requirements often appear near the end of a request for proposal as a short request for a VPAT. That approach is too narrow. A Voluntary Product Accessibility Template, or VPAT, is a reporting format. The completed report, commonly called an Accessibility Conformance Report or ACR, can be useful evidence, but it is not a guarantee that the product will work for every user, configuration, or workflow.

Before contacting vendors, define the actual user journeys the product must support. A learning management system, for example, must be assessed differently from a public WordPress site, a document portal, a payment application, or an internal employee dashboard. Procurement teams should involve the people who understand those workflows: web administrators, IT, content owners, security teams, legal counsel, disability services, and users with disabilities when possible.

Document the standards and legal requirements that apply to the purchase. Many US organizations reference WCAG 2.1 Level AA or WCAG 2.2 Level AA, while federal procurement commonly relies on Section 508 requirements. State, local government, higher education, and private-sector obligations can vary by jurisdiction, funding source, and the nature of the service. The contract language should be reviewed against the organization’s specific requirements rather than copied from a generic template.

Scope matters as much as the standard. Ask whether the requirement covers the core application, mobile apps, help center content, templates, integrations, customer portals, downloadable documents, implementation services, and future releases. A vendor may accurately report that its software meets certain criteria while excluding a feature your organization plans to use every day.

Build Requirements Around Real Use, Not Marketing Claims

A useful accessibility requirement is testable. “The solution must be accessible” establishes intent, but it does not give evaluators enough information to compare vendors or enforce performance after launch. Translate broad goals into expected outcomes tied to common barriers and critical workflows.

For a public-facing website or WordPress implementation, that may include keyboard operation of navigation and forms, meaningful alternative text processes, correctly labeled fields, visible focus indicators, sufficient color contrast, accessible error messages, semantic heading structure, and captions or transcripts where media requires them. It should also include the ability to create and maintain accessible content after implementation.

This distinction is essential for content management systems. A technically accessible theme can still produce inaccessible pages when editors upload untagged PDFs, paste poorly structured content, publish images without alternative text, or add third-party widgets that cannot be used by keyboard. Procurement should evaluate the controls available to prevent these failures, not merely the default interface.

For WordPress sites, require vendors or implementation partners to address the full publishing environment: themes, custom templates, custom post types, page builders, menus, widgets, forms, embedded media, PDFs, and linked pages. Accessibility issues commonly originate in the pieces added after a site launch. A limited homepage review will not reveal those risks.

Evaluate Evidence, Not a Single Compliance Document

An ACR should be part of due diligence, not the finish line. Review it for date, version, testing methods, supported environments, known exceptions, and the specificity of each response. A report that says “supports” across every criterion with little explanation provides less confidence than one that identifies limitations, describes tested workflows, and includes a credible remediation plan.

Ask vendors how they test. Automated testing is valuable because it can find recurring issues at scale, such as missing form labels, invalid heading structures, empty links, and some contrast problems. It cannot reliably determine whether alternative text is meaningful, whether keyboard interaction is logical, or whether a complex workflow is understandable with a screen reader. Strong evidence combines automated scanning, manual keyboard testing, assistive technology testing, and review by accessibility professionals.

A practical evaluation should request evidence for the workflows your organization will use. If a vendor sells an online application process, have them demonstrate completing it without a mouse. If the system produces PDFs, request an accessible sample output. If administrators will build pages or publish documents, ask them to show the authoring controls and publishing safeguards.

The following evidence is particularly useful when comparing vendors:

• A current ACR that identifies the product version, standards evaluated, test approach, and known exceptions.
• Demonstrations of critical user journeys using keyboard-only navigation and, where appropriate, screen reader interaction.
• Documentation showing how accessibility defects are reported, prioritized, remediated, and communicated to customers.
• A product roadmap or written remediation plan for material issues, with owners and target dates.
• Information on whether accessibility testing covers updates, new features, templates, integrations, and customer-configured content.

Evidence requirements should be proportionate to risk. A low-impact internal tool may warrant a lighter review than a public benefits portal, online course platform, or system used for employment, healthcare, financial, or emergency communications. The principle remains the same: evaluate the experience people will actually have.

Put Accessibility Obligations in the Contract

Accessibility promises that remain in proposal responses can be difficult to enforce. The agreement, statement of work, and acceptance criteria should state the applicable standard, the covered products and services, the evidence expected, and the vendor’s responsibilities when nonconformance is discovered.

Avoid language that only requires the vendor to use “commercially reasonable efforts.” That phrase may be appropriate in some business terms, but it is not a measurable accessibility commitment. More useful language requires conformance to the identified standard, establishes a process for reporting defects, and sets remediation deadlines based on severity and user impact.

The contract should also address updates. Software changes can introduce new accessibility barriers even when a product performed well at purchase. Require accessibility to be considered in releases, extensions, and redesigns. Vendors should notify customers of material known issues, provide an accessible alternative or workaround when feasible, and remediate defects without forcing the customer to purchase a separate accessibility package.

Acceptance testing is another critical safeguard. Define which workflows will be tested before launch or payment milestones, who can report failures, and what happens if critical barriers remain unresolved. Depending on the purchase, remedies may include withholding acceptance, requiring corrective work, extending support, or allowing termination for material nonconformance. Legal counsel should tailor these provisions to the organization’s risk tolerance and procurement rules.

Account for Shared Responsibility

Most digital systems have shared accessibility responsibility. A software vendor controls the product code and interface components. The customer may control content, user permissions, configuration, documents, branding, and integrated services. An agency may control the theme and custom development. If those boundaries are not documented, every party may assume someone else is responsible.

Define responsibilities in operational terms. Who reviews uploaded PDFs? Who verifies that editors add alternative text? Who tests a new form before publishing? Who approves a third-party plugin or embedded tool? Who monitors accessibility after a platform update? These questions turn accessibility from a one-time vendor selection exercise into an accountable process.

For WordPress, an automated accessibility checker can support that process by scanning published content, templates, custom post types, menus, widgets, and other site components for detectable WCAG and Section 508 issues. WP ADA Compliance Check can also provide issue-level remediation guidance and publishing controls, helping teams identify problems before inaccessible content becomes part of the public site. Automation does not replace expert review, especially for context-dependent requirements, but it gives site managers a repeatable control between formal audits.

Treat Procurement as the First Accessibility Test

The most effective procurement teams do not ask whether a vendor has an accessibility statement and move on. They ask whether the product supports essential tasks, whether the evidence is current and specific, whether the vendor has a credible defect process, and whether the contract makes those commitments enforceable.

That discipline protects more than a compliance checklist. It gives your organization a practical basis for selecting technology that people can use, maintaining it as requirements change, and addressing barriers before they become a public failure or legal dispute.