How to Read an RFP's Accessibility Requirements and Win the Bid

The Language Is Changing

If you have been bidding on municipal contracts for any length of time, you have probably noticed something different in recent RFPs. Where accessibility requirements used to be a vague line about "ADA compliance" buried in the general terms, they are now showing up as dedicated sections with specific technical standards, documentation requirements, and contract obligations that can determine whether your proposal advances past initial review.

This shift is not accidental. The DOJ's Title II final rule directed municipalities to embed accessibility into their procurement processes. The DOJ's own guidance recommends that public entities require detailed accessibility information from vendors before signing contracts. States like Massachusetts, Minnesota, Virginia, and Arizona have already formalized this into standardized procurement language. The rest of the country is catching up fast as the April 2026 deadline approaches.

For contractors who understand what these requirements actually ask for, this is a competitive opportunity. For those who do not, it is a disqualification trap.

The Four Things Procurement Officers Are Looking For

Municipal procurement language around accessibility varies in complexity, but it almost always comes down to four categories. Understanding what each one means — and what a strong response looks like — is the difference between a competitive proposal and one that gets filtered out.

1. A Specific Technical Standard

Modern RFPs do not just say "ADA compliant." They reference a specific standard, almost always WCAG 2.1 Level AA. Some forward-looking municipalities are already citing WCAG 2.2, which adds nine additional success criteria focused on cognitive accessibility, low vision, and mobile users.

When you see language like "Vendor shall ensure all deliverables conform to WCAG 2.1 Level AA," that is not decorative. It is a measurable technical specification with 50 testable success criteria. The procurement officer expects you to know what those criteria are and how you verify conformance against them.

A strong response acknowledges the specific standard, describes your testing methodology (both automated and manual), and references the specific tools you use. A weak response says "we are committed to accessibility" without demonstrating familiarity with the actual requirements.

2. A VPAT or Accessibility Conformance Report

The Voluntary Product Accessibility Template (VPAT) is a standardized document developed by the Information Technology Industry Council. When completed for a specific product, it becomes an Accessibility Conformance Report (ACR). This is the document that procurement teams use to evaluate how well your deliverable meets each WCAG criterion.

A VPAT is structured as a series of tables where each row corresponds to a specific WCAG success criterion. For each criterion, you report one of four conformance levels:

Supports — The product fully meets the criterion with no known defects.

Partially Supports — Some aspects meet the criterion, but limitations exist. You must describe what works and what does not.

Does Not Support — The product does not meet the criterion. You must explain the gap and, ideally, describe your remediation plan.

Not Applicable — The criterion does not apply to the product's functionality.

Here is what most contractors get wrong about VPATs: procurement officers do not expect a perfect score. They expect an honest one. A VPAT that shows "Supports" across every criterion with no explanatory remarks raises more red flags than one that shows a handful of "Partially Supports" entries with clear remediation timelines. The Massachusetts vendor accessibility contract language explicitly states that failure to provide a current ACR may result in disqualification — but having an ACR with documented defects does not automatically disqualify you.

What disqualifies you is not having one at all.

If your deliverable is a custom project that does not yet exist — a website build, a portal development, an application — you cannot produce an ACR for a product that has not been built yet. In that case, your response should include your accessibility testing methodology, examples of past accessible work, your remediation process, and a commitment to deliver a completed ACR at launch. Minnesota's procurement guidelines specifically address this by requiring organizational attestations when a product ACR is not yet possible.

3. Accessibility Warranties and Remediation Clauses

After the technical standard and documentation requirements, the third component you will encounter is contract language around warranties and remediation obligations. This is where the legal teeth are.

Typical warranty language looks something like this: the vendor warrants that deliverables will conform to WCAG 2.1 Level AA at the time of delivery and will maintain that conformance throughout the contract term. If non-conformance is identified, the vendor will remediate the issues within a specified timeframe — often 30 days — at no additional cost to the municipality.

Some contracts go further. The DOJ's guidance suggests municipalities include language that prohibits vendors from disclaiming accessibility warranties. This means you cannot include boilerplate terms-of-service language that limits your liability for accessibility failures. If the RFP includes this provision and your standard contract template disclaims it, you need to address that conflict before you submit.

The key nuance here is that accessibility warranties are complex because WCAG conformance can be affected by content decisions made after delivery. A CMS you build might be fully accessible at launch, but if municipal staff add images without alt text or create documents with broken heading structures, conformance degrades through no fault of yours. Strong contracts address this by distinguishing between the vendor's responsibility for the platform and the client's responsibility for content, with cooperation clauses that require both parties to maintain accessibility.

If an RFP's warranty language feels one-sided, your response should propose specific, fair terms rather than simply accepting or objecting. Procurement officers generally prefer contractors who demonstrate they understand the nuance over those who rubber-stamp everything or push back without offering alternatives.

4. Indemnification

The heaviest obligation you will see in accessibility procurement language is indemnification — the requirement that you, as the vendor, hold the municipality harmless from claims, damages, costs, and expenses arising from accessibility failures in your deliverables.

Massachusetts is one of the most explicit examples, requiring vendors to "indemnify and hold the Commonwealth harmless from any and all claims, damages, costs, and expenses arising from or relating to any failure of the Deliverables to meet the accessibility requirements." The DOJ's guidance recommends this approach for all public entities.

This is where the April 2026 deadline translates directly into financial exposure for contractors. If a municipality is sued over an inaccessible portal you built, the indemnification clause means you bear the cost. With first-time ADA penalties reaching $75,000 and typical lawsuit settlements ranging from $5,000 to $50,000 plus attorney fees and mandatory remediation, that exposure is not theoretical.

Your response to indemnification requirements should demonstrate that you have the processes in place to minimize the risk. Documented scanning, a clear remediation workflow, and an audit defense log showing your compliance efforts are the evidence that makes an indemnification commitment manageable rather than reckless.

How to Position Compliance as a Differentiator

Most of your competitors are going to do one of two things when they encounter accessibility requirements in an RFP: either ignore them and hope the evaluation committee does not weight them heavily, or respond with generic language about being "committed to accessibility" without substance.

Both approaches fail. Here is what a winning response looks like.

Lead with your methodology, not just your commitment. Describe the specific combination of automated and manual testing you perform. Name the tools — axe-core, WAVE, Lighthouse, screen readers like NVDA or JAWS. Explain that automated tools catch approximately 30 to 40 percent of WCAG issues and that you supplement with manual keyboard navigation testing, screen reader testing, and human review of alt text and reading order. This signals technical fluency that generic commitments do not.

Include evidence of past compliance work. If you have delivered accessible projects to other municipalities, reference them. If you have scan reports or remediation logs from previous work, offer them as supporting documentation. Procurement officers evaluating accessibility are often doing so for the first time — concrete examples help them understand what good looks like.

Provide a compliance timeline for the project. Show that accessibility is built into your project plan from the start, not bolted on at the end. Reference accessibility checkpoints at design, development, and pre-launch stages. Note that you will deliver a completed ACR at project close. This addresses the procurement officer's concern that accessibility will slip through the cracks if it is not explicitly planned.

Address the overlay question directly. If the RFP does not explicitly exclude overlay widgets, you can still differentiate by stating that your approach is source-level remediation rather than third-party script injection. After the FTC's $1 million settlement with the largest overlay vendor and the data showing that nearly a quarter of 2025 ADA lawsuits targeted sites with overlays installed, procurement officers are increasingly skeptical of widget-based approaches. Proactively stating that you fix code rather than mask issues positions your bid favorably.

Offer ongoing monitoring, not just a one-time fix. Accessibility is not a checkbox — it is a maintenance commitment. If your proposal includes a post-launch monitoring plan with periodic rescans and a documented process for addressing regressions, you are addressing a concern that most competitors do not even acknowledge.

The Documentation Package That Wins

When you put it all together, a competitive accessibility response to a municipal RFP includes:

A completed VPAT or ACR for existing products, or a detailed methodology statement with a commitment to deliver an ACR at launch for custom projects.

A description of your testing approach that covers both automated scanning and manual review.

A project timeline with accessibility milestones integrated into each phase.

A proposed remediation workflow that defines how issues are identified, prioritized, tracked, and verified.

An audit defense log or sample documentation showing your compliance tracking process.

References from past municipal projects where you delivered accessible work.

This is more documentation than most competitors will provide. That is exactly the point. In a procurement environment where accessibility is becoming a gatekeeper requirement, the contractor who shows up with a complete compliance package does not just meet the minimum — they make the evaluation committee's job easier. And making the evaluator's job easier is one of the most reliable ways to move to the top of the scoring rubric.

The municipalities asking these questions are not trying to create busywork. They are trying to avoid being the next entity in a DOJ investigation or a headline-making accessibility lawsuit. The contractors who help them do that will be the ones who keep winning work.

---

This post is for informational purposes only and does not constitute legal advice. Consult with qualified legal counsel for guidance specific to your situation.