ADA title II procurement and vendor accessibility: Make compliance operational, not optional

If a public entity provides or makes a website, application, or digital service available through a vendor arrangement, the accessibility obligation still applies to that vendor-delivered experience. In other words, vendor-hosted or vendor-built public-facing interfaces can create Title II exposure if they aren’t accessible.

Here’s what you should do to make accessibility a procurement requirement rather than a post-launch scramble:

• Embed accessibility into sourcing and evaluation so vendors know compliance isn’t negotiable before they bid.
• Write enforceable contract language with acceptance criteria, audit rights, and remediation SLAs that get used.
• Build testing and monitoring into delivery to catch gaps before they reach the public.
• Tie vendor performance to measurable accessibility KPIs so renewals reward compliance, not just speed to market.

First, let’s define how the Americans with Disabilities Act (ADA) Title II intersects with procurement decisions.

Put engineering accessibility in contracts

Accessibility compliance doesn’t happen by accident. It gets built into RFPs, locked into contracts, tested before launch, and monitored after go-live.

I’ve watched too many procurement teams treat accessibility like a footnote. It’s something Legal mentions once, then everyone forgets until a complaint lands. By that point, fixing the problem costs several times more than prevention would have, especially when you include legal fees, emergency engineering work, and opportunity costs.

The vendors who ship inaccessible products often aren’t malicious. They simply didn’t know compliance was mandatory, measurable, or a part of payment.

Start with RFPs that mean business

Score accessibility like you score cost and timeline. Ask vendors for an Accessibility Conformance Report (ACR) that uses the current VPAT template. The ACR should document conformance against the accessibility standard you’re requiring, typically WCAG 2.1 Level AA (Title II minimum). Consider WCAG 2.2 Level AA (future-proof target) as something more aspirational.

Write contracts that work

Vague language such as “vendor will comply with applicable laws” is unhelpful. Your lawyer knows it. Your vendor’s lawyer knows it. Instead, be specific.

• Conformance: All web content and deliverables meet WCAG 2.1 Level AA (for Title II compliance) throughout the contract term. Where applicable, vendor will provide an Accessibility Conformance Report (ACR/VPAT) addressing Revised Section 508 requirements.
• Evidence: Provide a current ACR (this is required) and update it with major releases.
• Acceptance: Check for zero blocker defects. Run keyboard navigation and screen reader tests before sign-off.
• Testing rights: You can test anytime. Vendor remediates defects within [X] days with proof of fix.
• Flow-down: Vendor’s subcontractors inherit the same accessibility duties.
• Accessibility statement: Vendor will maintain a public accessibility statement documenting conformance level and contact information for accessibility feedback.

These aren’t aspirational. They’re plug-and-play clauses for your next template.

Test before you pay

Acceptance criteria should include accessibility checkpoints: Can users navigate with keyboard only? Do screen readers announce form errors? Does color contrast work for low-vision users? If any blockers are present, that means the vendor fixes them before payment clears.

Audit after launch

Vendors release updates that sometimes break what used to work. Build periodic reviews into your contract with rights to test, request evidence, and require attestations of continued conformance. If your usage data shows high abandon rates tied to assistive tech, that’s your cue to investigate.

Common challenges and solutions in accessibility compliance

Most accessibility failures happen because nobody owns it, nobody’s trained on it, and everybody assumes someone else is handling the compliance piece.

Even organizations with strong accessibility policies struggle with follow-through. Your procurement team doesn’t know how to evaluate a VPAT. Your IT team thinks accessibility is a “nice to have” that can wait until after launch. Legal assumes it’s an IT problem. IT assumes it’s a Legal problem.

Meanwhile, your vendor ships an inaccessible portal, and it becomes an issue for the public entity, especially when the portal is part of how the public accesses services or programs. Title II also prohibits discrimination carried out through contractual or other arrangements.

The legacy system trap

You’re stuck with a CMS from 2012 that was never designed with accessibility in mind. Your payment processor uses a third-party widget you can’t control. Your chatbot integration doesn’t expose keyboard focus. Fixing any of this requires a budget you don’t have and political capital you’re saving for other battles.

Start with what you can control. New procurements get accessibility requirements written in from day one. Contracts up for renewal should get amended to include conformance clauses and testing rights. Legacy systems that touch the public get prioritized for replacement based on risk. For example, a portal for permit applications should rank higher than an internal FAQ nobody reads.

Nobody knows what they’re supposed to do

Your procurement officer doesn’t know what questions to ask vendors about accessibility. Your project manager doesn’t know what WCAG 2.2 Level AA conformance means in practical terms. Your QA team runs automated scans but has never tested with a screen reader.

Training doesn’t have to be elaborate. A few hours on ADA standards, digital accessibility best practices, and evaluation methods will get you most of the way there. Teach Procurement how to score a VPAT. Show IT how to run basic keyboard and screen reader tests. Give Legal sample contract language they can use.

The “we’ve always done it this way” problem

Your organization has been buying software the same way for 15 years. Vendors promise everything and deliver whatever they feel like. Nobody enforces acceptance criteria because “we need to launch on time.” Accessibility gets treated as a checkbox instead of a gate that determines whether you accept delivery and release payment.

Change the incentives. Make accessibility a scored criterion in RFPs, weighted equally to cost and timeline. Tie vendor payment to passing acceptance tests that include keyboard navigation and screen reader compatibility. Build audit rights into contracts so you can verify conformance after launch, not just take the vendor’s word for it.

Design and technology for inclusion

Universal design and web accessibility practices create better products that work for everyone, disabled or not, while meeting compliance requirements by default.

That means when you require vendors to design inclusively from the start, you’re forcing better decisions across the board. I’ve seen procurement teams treat accessibility as a burden, something that slows development or limits creativity. What really happens? Products built with keyboard navigation, clear focus indicators, and semantic HTML work better for power users, mobile users, and anyone navigating without a mouse. Captions help people watch videos in noisy environments or on mute. High-contrast text benefits users with aging eyes, not solely those with diagnosed low vision.

Build inclusive design into vendor requirements

Your RFP should ask vendors how they incorporate inclusive design principles into their process. Do they test with assistive technology users? Do they follow established accessible design patterns for common components? Do they design for keyboard-first interaction before layering on mouse convenience?

Vendors who treat accessibility as an add-on will struggle. Vendors who design inclusively from discovery through deployment will deliver products that pass acceptance testing without drama.

Align with current standards

For Title II, the DOJ rule sets WCAG 2.1 Level AA as the minimum. You can require WCAG 2.2 Level AA contractually to future-proof but don’t confuse that with the DOJ rule’s baseline. If your organization is also subject to Section 508 (for example, due to federal agency scope, federally funded program requirements, or an adopted state policy), include those requirements alongside the DOJ’s Title II ADA web/mobile rule.

Prove universal design benefits

When vendors balk at accessibility requirements, remind them that accessible products reach more users, reduce support costs, and perform better in testing. Keyboard navigation speeds up workflows for all users. Clear error messaging reduces form abandonment. Properly structured content improves SEO and content reuse. Accessible PDFs work better with mobile readers and translation tools.

Require assistive tech testing, not just automated scans

Automated tools catch a portion of accessibility issues. The rest require human testing with assistive technology (AT), such as screen readers, voice control, and magnification software. Your vendor’s acceptance plan should include AT user testing, not simply running an automated checker and calling it done.

Strategies for disability inclusion in tech development

Accessibility must be built into every phase of the software development lifecycle, from the moment a vendor starts discovery through deployment and ongoing support.

That means you can’t let vendors treat accessibility as a final QA checklist item they run through the week before launch. They’ll fail, ask for an extension, or ship anyway and promise to fix it in the next release. This promise will evaporate once the invoice clears.

When accessibility is included throughout discovery, design, development, and testing, vendor digital content and products ship compliant instead of arriving late with a remediation backlog longer than your budget can handle.

Set checkpoints at every stage, not only at the end

Your vendor’s contract should spell out accessibility requirements for each phase.

Discovery and design: Vendors document how they’ll meet WCAG 2.1 Level AA (Title II minimum) before writing code. Wireframes get reviewed for keyboard navigation patterns, focus management, and color contrast. Catching a contrast issue in Figma takes five minutes. Catching it after deployment takes five weeks.

Development: Code reviews include accessibility checks for all web content. Developers use semantic HTML and only use ARIA when necessary (not as duct tape for bad markup). They also test with keyboard navigation as they build. If your vendor is inventing custom components instead of using proven accessible patterns, ask them why they’re reinventing the wheel and charging you for it.

QA: No product passes testing with blocker-level defects. Your acceptance criteria should be unambiguous: keyboard-only navigation works, screen readers can complete all tasks, and color contrast meets minimums. If the vendor asks for a waiver or wants to ship with “minor known issues,” your answer is no. (Unless you enjoy explaining to your legal team why you accepted a product that violates civil rights law.)

Test with users with disabilities

Your vendor’s QA person fumbling through NVDA for the first time isn’t the same as someone who uses a screen reader daily testing the interface. Build user research and testing with users with disabilities into the vendor’s scope. Pay participants for their time. Use their feedback to fix problems before launch, not after the Department of Justice sends a letter.

Tie renewals to accessibility performance

Track vendor accessibility metrics the same way you track uptime or security patches. How many defects were introduced in the past year? How quickly were they remediated? Is the vendor maintaining conformance or letting it slip with each update?

When renewal time comes around, vendors with strong accessibility records get preference. Vendors who consistently ship defects or procrastinate on fixes lose points. Or they lose the contract. Sometimes both.

Manage exceptions and non-compliance

Exceptions to accessibility requirements need clear governance, expiration dates, and remediation plans. When vendors fail to comply, you escalate through increasingly painful consequences until they fix it or you find someone else who will.

The word exception is where accessibility programs die. A vendor asks for a temporary waiver on some “minor” issue. You grant it because the launch deadline is looming and everyone’s tired. Six months later, that exception is still sitting there, unresolved, quietly undermining your compliance posture. The vendor has moved on to the next project and has conveniently forgotten that the fix was ever promised. Meanwhile, you’re the one explaining to Legal why that form still doesn’t work with screen readers.

If you grant exceptions, make them hurt a little

Sometimes you genuinely need a temporary exception. Maybe there’s a technical limitation in a legacy integration that can’t be fixed until the next major version, or you’re contractually stuck with a third-party component for another year. Fine. But document every detail so the exception can’t become permanent.

What’s the specific issue? “Form doesn’t work with screen readers” tells you nothing. “Submit button lacks accessible label; screen reader announces ‘button’ with no context” gives developers something they can fix.

What's the business impact? How many users can’t complete this task? What workaround exists? And “call this phone number during business hours” is not a workaround for a 24/7 digital service.

When does this expire? Set a hard date tied to the vendor’s next release or your contract renewal. No open-ended exceptions that turn into permanent gaps.

Corrective action plans need teeth

When a vendor misses an accessibility requirement, “we’ll fix it soon” doesn’t work. You need a named owner (not “the dev team” but an actual person whose performance review depends on delivery), a specific timeline tied to your SLA, and proof of fix. Updated ACR, passing test results, documentation of the change. Track each defect from identification to closure. When vendors blow past deadlines, you should escalate.

Make non-compliance expensive

Your contract needs escalating consequences for vendors who procrastinate. Service credits that increase the longer a defect sits unresolved. Payment holdbacks until the vendor demonstrates conformance. Requirements to replace non-conformant components at the vendor’s expense, not yours.

And if the vendor consistently ships defects or refuses to remediate? Invoke your termination clause and find a vendor who takes accessibility seriously. The threat only works if you’re willing to follow through. Vendors know when you’re bluffing, and they’ll call it every time.

The trick is writing these remedies into your contract before problems surface. Trying to negotiate consequences after the vendor has already shipped inaccessible code and cashed your check? Good luck with that.

Build a vendor ecosystem that ships accessible by default

ADA Title II compliance happens when accessibility becomes the easiest path forward for vendors. When your RFPs score it heavily, your contracts enforce it clearly, and your acceptance testing enters payment on it.

The tactics aren’t complicated. Write specific contract clauses that cite WCAG 2.1 Level AA (Title II) and, where applicable, Revised Section 508. Require current ACRs. Test with keyboard navigation and screen readers before you accept delivery. Tie renewals to accessibility track records. Flow obligations down to subcontractors so nobody escapes accountability.

The shift happens when vendors learn that inaccessible products lose points in evaluation, procrastination on remediation costs them fees, and failure to maintain conformance costs them contracts. Eventually, accessibility becomes part of how they build, not something they retrofit under pressure.

Your constituents get equitable access. Your legal team sleeps better. And you stop fixing the same problems with every new contract.

Ready to operationalize accessibility across your vendor lifecycle? Request a demo to see how Siteimprove builds accessibility into procurement from the start.