Accessibility requirements should be written into every website and software RFP because procurement decisions determine whether an organization buys inclusive technology or inherits years of avoidable remediation, legal exposure, and user frustration. In practical terms, an RFP, or request for proposal, is the document that tells prospective vendors exactly what they must deliver, how they will be evaluated, and which standards they must meet before a contract is awarded. For digital accessibility, that means turning broad intentions like “the product should be usable by everyone” into precise contractual requirements tied to recognized benchmarks, documented testing, governance processes, and post-launch support obligations.
I have worked on procurements where accessibility was mentioned in one sentence near the end of a questionnaire, and I have worked on procurements where it was embedded into technical requirements, scoring criteria, implementation milestones, acceptance testing, training, and maintenance language. The difference is dramatic. When accessibility is vague, vendors overstate compliance, project teams assume issues can be fixed later, and buyers discover late in implementation that core workflows fail with keyboard navigation, screen readers, zoom, captions, or color contrast. When accessibility is explicit, vendors know they must provide evidence, product teams plan remediation before launch, and organizations gain leverage to require fixes without renegotiating the scope.
This topic matters for compliance and implementation because procurement is one of the earliest control points an organization has. If the purchasing team, legal counsel, IT, and business owners ask the right questions before selection, they can prevent inaccessible systems from entering the environment. If they ask weak questions, the cost of remediation shifts downstream into change requests, delayed launches, inaccessible customer journeys, employee complaints, and in some sectors formal enforcement action. A strong accessibility RFP also improves product quality for all users by driving better structure, clearer forms, more reliable interaction patterns, stronger documentation, and more disciplined release management.
The core standards and documents are well established. Most website and software RFPs should reference WCAG 2.1 AA or WCAG 2.2 AA, depending on organizational policy and market readiness, and should require conformance across relevant user journeys, not only selected templates. Buyers should also request a current VPAT, meaning a Voluntary Product Accessibility Template completed against the applicable Accessibility Conformance Report format, plus evidence of manual testing with assistive technologies, defect logs, remediation timelines, and accessibility governance practices. Section 508 may matter for US public sector procurement, EN 301 549 is central in Europe, and ADA risk is often a driver in the United States even though it is not itself a technical standard. The key principle is simple: buy against recognized criteria, require evidence, and write enforcement into the contract.
What accessibility requirements belong in every website and software RFP
Every accessibility RFP should state the required conformance standard, the scope of the digital product, the evidence the vendor must submit, and the conditions under which the buyer can reject deliverables. The minimum requirement should identify the applicable standard by version and level, such as WCAG 2.2 AA for web content and software interfaces delivered through browsers, native applications, or hybrid platforms where the criteria apply. The language should say that accessibility applies to all public-facing pages, authenticated areas, forms, dashboards, documents, media, customer support flows, and administrative functions included in the purchase.
Good RFPs also define accessibility beyond code. Vendors should be required to address keyboard operability, screen reader compatibility, focus management, error identification, labels and instructions, semantic structure, heading hierarchy, alt text, reflow, zoom, captions, transcripts, color contrast, status messages, target sizes where applicable, and support for user settings. If the product generates PDFs, emails, charts, or exported reports, the requirement should explicitly cover those outputs. If the solution includes third-party widgets, payment components, maps, chat, identity services, or embedded video players, the vendor should remain accountable for accessibility across those integrated experiences.
The strongest language I have used makes accessibility a measurable acceptance criterion rather than a marketing claim. Instead of asking vendors whether they “support accessibility,” the RFP should require them to describe their testing methodology, list the assistive technologies used, identify known issues, and explain how defects are prioritized and fixed. It should also require named roles. Buyers should know whether the vendor has an accessibility lead, trained designers, QA analysts who perform keyboard and screen reader testing, and engineers familiar with ARIA, semantic HTML, accessible native controls, and platform accessibility APIs.
How to evaluate vendor claims and documentation
Many buyers receive polished assurances that a platform is accessible, only to discover that the evidence is thin. A VPAT is useful, but it is not enough on its own. It is a vendor-completed disclosure document, not a certification. In reviews I have led, the most reliable proposals combine a recent VPAT with detailed notes on test scope, issue severity, version numbers, and remediation status. If a vendor says “supports with exceptions,” the buyer should ask exactly which user tasks are affected, whether workarounds exist, and when fixes will ship.
Ask for the date of the last accessibility audit, who performed it, and whether it included manual testing. Automated scanners such as axe DevTools, WAVE, Lighthouse, and Siteimprove are valuable, but they do not detect many real barriers, including poor focus order, missing context in alt text, misleading labels, inaccessible drag-and-drop interactions, or screen reader confusion in dynamic components. A credible vendor should be able to explain a repeatable process that combines automation, expert manual review, and testing with common assistive technologies such as JAWS, NVDA, VoiceOver, TalkBack, Dragon, magnification tools, and keyboard-only operation.
Scoring should reward transparency. Vendors that disclose known defects, publish remediation roadmaps, and explain internal controls are usually safer choices than vendors that claim perfect compliance without details. I have seen proposals lose credibility when every criterion is marked “supports” but demo sessions reveal inaccessible modal dialogs, unlabeled form fields, or charts announced as empty graphics. During procurement, request a live demonstration of critical tasks using a keyboard and screen reader. Five minutes of observation often reveals more than fifty pages of boilerplate.
Contract terms, acceptance criteria, and ongoing accountability
Accessibility requirements fail when they disappear after vendor selection. The contract should restate the standard, bind the vendor to the representations made in the proposal, and define remediation obligations. It should specify that accessibility defects are warranty issues when they cause nonconformance with agreed requirements. It should also require timely correction at no additional cost, especially for defects present at launch or introduced through updates. Without this language, buyers can end up paying again to fix problems they already asked the vendor to prevent.
Acceptance criteria should be explicit. Deliverables should not be considered complete until accessibility testing is performed on agreed user journeys and critical defects are resolved or formally accepted with documented rationale. Severity definitions help. For example, a blocker may be any issue that prevents completion of a core task using keyboard or screen reader access; a high-severity issue may substantially impede understanding or operation; moderate issues may create friction without fully blocking task completion. This structure lets procurement, legal, IT, and business owners align on what “ready” means.
Training and support terms matter too. Vendors should provide accessible documentation, administrator guidance, and user support channels that can handle accessibility-related tickets. If the product is configurable, the contract should clarify which party is responsible for accessible templates, content entry, workflow changes, and custom code. Many accessibility failures come from this shared-responsibility gap. A platform may be capable of accessible output, yet the implementation team can still create inaccessible forms, PDFs, videos, or design patterns. Procurement documents should assign those responsibilities in plain language.
| RFP component | What to require | Why it matters |
|---|---|---|
| Standard | WCAG 2.2 AA, plus Section 508 or EN 301 549 where applicable | Creates an objective baseline for evaluation and contracting |
| Evidence | Current VPAT, audit summary, known issues list, testing methodology | Separates substantiated claims from generic assurances |
| Demo | Live keyboard and screen reader walkthrough of key tasks | Validates accessibility in real workflows, not just documents |
| Acceptance | Accessibility testing tied to go-live approval | Prevents inaccessible releases from being treated as complete |
| Remediation | Contractual fix timelines and no-cost correction of nonconformance | Protects the buyer after implementation and during updates |
Requirements for different product types and procurement models
Website, SaaS, mobile app, and enterprise software procurements need different emphasis, even when they use the same baseline standard. For websites, the RFP should focus on templates, components, forms, search, navigation, media, and content authoring workflows. For SaaS platforms, include authenticated experiences, role-based dashboards, data visualizations, exports, notification systems, and administration tools. For native mobile apps, require support for platform accessibility features such as iOS VoiceOver and Android TalkBack, dynamic text sizing, contrast, focus order, touch target sizing, orientation, and compatibility with external keyboards where relevant.
Enterprise software often introduces another challenge: configuration and customization. In systems like Salesforce, ServiceNow, Microsoft Dynamics, Adobe Experience Manager, or Workday, a vendor may provide an accessible core product while an implementation partner creates inaccessible custom components or business processes. In those cases, the RFP should distinguish platform conformance from implementation deliverables and require both the software vendor and the implementation partner to meet accessibility obligations. That includes accessible design artifacts, coded customizations, reports, documents, and end-user training materials.
Procurement models also affect the language. In a competitive RFP, accessibility can be a weighted scoring category with mandatory thresholds. In a request for information, the goal is to screen the market and identify vendors with mature practices before issuing a formal solicitation. In cooperative purchasing or sole-source situations, buyers lose some competitive leverage, so the contract must carry more enforcement weight. Renewal and expansion procurements should never assume prior accessibility remains adequate. New modules, redesigned interfaces, AI features, and analytics layers often introduce fresh barriers that need renewed review.
Governance, internal roles, and common procurement mistakes
Strong accessibility procurement depends on internal governance as much as vendor language. The most effective teams involve procurement, legal, IT security, digital accessibility specialists, UX, engineering, and the business owner early in the process. Someone must own the requirements, someone must evaluate technical evidence, and someone must verify accessibility during implementation. When these roles are unclear, accessibility falls between departments. Procurement assumes IT will check it, IT assumes the vendor has already validated it, and legal sees the issue only after a complaint or launch delay.
The most common mistake is treating accessibility as a binary yes-or-no question. Real evaluation is more nuanced. Buyers should ask where the product conforms, where it does not, how severe the gaps are, whether fixes are already scheduled, and whether the nonconformances affect essential tasks. Another common mistake is requesting a VPAT but not reading it critically. If multiple rows contain vague language like “partially supports” without meaningful remarks, the document is not decision-ready. A third mistake is excluding accessibility from scoring, which signals that it is optional no matter what the narrative text says.
This hub topic connects directly to implementation planning, audits, design systems, content operations, training, and legal compliance. Procurement & Vendor Management is where those downstream disciplines start. A good RFP should point to related internal standards for design review, user acceptance testing, document accessibility, media accessibility, and release governance so vendors understand the full operating environment they are entering. If your organization manages digital procurement regularly, build a reusable accessibility rider, standard questionnaire, contract clause library, and evaluation rubric. Those assets improve consistency and reduce risk across every future purchase.
The practical takeaway is straightforward: put accessibility requirements in the RFP with the same precision you use for security, privacy, uptime, and data handling. Name the standard, define the scope, require evidence, test real workflows, score vendor maturity, and write remediation duties into the contract. That approach reduces rework, strengthens compliance, and produces better digital experiences for customers, employees, students, patients, and residents. If you are updating procurement templates now, start by revising your standard RFP and contract language so every new website and software purchase is evaluated for accessibility from day one.
Frequently Asked Questions
Why should accessibility requirements be included in every website and software RFP?
Accessibility requirements belong in every website and software RFP because procurement is where accessibility is either built into the project from the start or pushed into an expensive cleanup phase later. An RFP defines what vendors must provide, how proposals will be scored, and what standards must be met before a contract is awarded. If accessibility is missing or vague at that stage, organizations often end up purchasing products that exclude users with disabilities, create operational barriers for employees and customers, and require costly remediation after launch.
Including clear accessibility requirements also reduces legal and reputational risk. Many organizations are subject to laws, regulations, contractual obligations, or internal policies that require digital accessibility. If a vendor is not required to demonstrate conformance up front, buyers may inherit compliance gaps that become difficult to fix once the product is deployed across teams, departments, or public-facing services. In practice, strong RFP language helps ensure vendors treat accessibility as a core deliverable rather than an optional enhancement.
Just as important, accessible procurement leads to better overall technology outcomes. Products that are usable with keyboards, screen readers, captions, scalable text, sufficient color contrast, and predictable navigation tend to work better for everyone, including aging users, mobile users, and people in temporary or situational constraints. Putting accessibility into the RFP signals that inclusion, usability, and long-term maintainability are part of the buying decision, not afterthoughts.
What accessibility standards should an RFP require vendors to meet?
At minimum, most website and software RFPs should require conformance with the Web Content Accessibility Guidelines, usually WCAG 2.1 AA or WCAG 2.2 AA, depending on the organization’s policy, legal environment, and project timeline. WCAG is the most widely recognized technical standard for digital accessibility and provides a practical framework for evaluating websites, web applications, mobile experiences, and many software interfaces. Referencing a specific version and level is important because general phrases like “must be accessible” are too ambiguous to enforce effectively.
For software procurement, the RFP should also ask vendors to identify which standards and legal frameworks their product aligns with, such as Section 508 where relevant, EN 301 549 for certain markets, or internal enterprise accessibility policies. The exact list will depend on the organization’s jurisdiction and industry, but the key is to require measurable, testable criteria rather than broad promises. Vendors should be asked to map product features to applicable standards and disclose any known exceptions, limitations, or partially conforming areas.
Strong RFPs go beyond naming standards and require supporting evidence. For example, vendors should provide a current accessibility conformance report, often in the form of a VPAT, along with test methodologies, dates of evaluation, assistive technologies used in testing, and a remediation plan for known issues. This is important because claiming alignment with WCAG is not the same as proving it. The most effective RFP language requires both conformance to recognized standards and documentation that shows how the vendor validated accessibility in real-world testing.
What specific accessibility requirements should be written into the RFP besides a general standards reference?
A strong RFP should include both technical requirements and process requirements. On the technical side, it should state the accessibility standard the product must meet, identify the scope of covered components, and require compatibility with common assistive technologies such as screen readers, screen magnification, speech input, keyboard-only navigation, and captioning or transcript support where applicable. It should also address accessible authentication, error identification, focus order, form labeling, responsive reflow, color contrast, document accessibility, multimedia accessibility, and support for users who cannot use a mouse.
On the process side, the RFP should require vendors to explain how accessibility is integrated into design, development, quality assurance, and release management. Buyers should ask whether the vendor conducts manual accessibility testing, who performs that testing, how often regressions are checked, and whether accessibility defects are tracked with the same seriousness as security or functional bugs. It is also valuable to require an accessibility roadmap for any areas not yet conforming, including timelines, responsible roles, and the vendor’s commitment to fix issues discovered during implementation.
The RFP should also cover training, support, and post-launch obligations. For example, vendors may be required to provide accessible user documentation, accessible training materials, and a named accessibility contact for escalation. Contracts can require remediation of accessibility defects within defined service levels and specify that future updates must maintain or improve accessibility. These details matter because accessibility is not a one-time checklist item; it is an ongoing product quality requirement that must be supported throughout the life of the software or website.
How can organizations evaluate whether a vendor’s accessibility claims are credible?
The best way to evaluate vendor claims is to require evidence, ask detailed follow-up questions, and make accessibility part of the scoring process instead of treating it as a pass-fail checkbox. A vendor should be able to provide a recent VPAT or accessibility conformance report, describe the methodology used, identify which product version was tested, and explain whether testing included manual review in addition to automated scanning. Organizations should be cautious when a vendor submits generic accessibility statements with no product-specific documentation or relies solely on automated tools, since automated tests catch only a portion of accessibility issues.
It is also important to examine the quality of the documentation itself. A credible accessibility report is usually specific, transparent, and candid about limitations. It should identify areas that support, partially support, or do not support the standard and include meaningful remarks rather than vague assurances. If a vendor claims full conformance but cannot explain how they tested keyboard access, screen reader behavior, dynamic content updates, or accessible error handling, that is a sign the claim may not be reliable.
Many organizations strengthen evaluation by conducting their own validation during procurement. This can include product demonstrations focused on keyboard navigation, screen reader compatibility, zoom and reflow behavior, captioning, and accessible workflows for critical tasks. Some buyers also include accessibility specialists or users with disabilities in the review process. This approach is especially valuable because it tests whether accessibility works in the actual user experience, not just on paper. In short, credible vendors welcome detailed scrutiny and can show mature accessibility practices, not just polished marketing language.
What contract terms should follow the RFP to ensure accessibility is delivered after the vendor is selected?
An RFP is only the starting point. To make accessibility enforceable, the resulting contract should carry forward the requirements in clear legal and operational terms. That means identifying the accessibility standards the product must meet, requiring that accessibility representations made during procurement remain binding, and specifying what happens if the delivered product does not conform. Without contract language, even a strong RFP can lose force once implementation begins and competing priorities emerge.
Useful contract terms often include warranties of accessibility conformance, obligations to remediate defects at the vendor’s expense, timelines for fixing critical issues, and requirements that updates or new releases do not reduce accessibility. Organizations may also require periodic updated VPATs or conformance reports, cooperation with accessibility testing during implementation, and participation in issue resolution if barriers are identified by users, auditors, or internal teams. For software that will be customized, the contract should clarify who is responsible for ensuring accessibility in configured workflows, templates, integrations, and content.
It is also wise to define acceptance criteria tied to accessibility. For example, final acceptance can depend on successful accessibility review of key user journeys rather than simple delivery of functionality. Support terms should include a path for reporting accessibility defects and escalation commitments comparable to other high-priority issues. These provisions help ensure accessibility survives beyond vendor selection and becomes part of implementation, maintenance, and continuous improvement. In practical terms, the combination of strong RFP language and enforceable contract terms gives organizations the best chance of buying technology that is inclusive from day one and sustainable over time.
