Government agencies remain legally responsible for the accessibility of all digital services they provide, including those delivered through third-party vendor platforms under ADA Title II.
In almost every ADA accessibility audit we conduct, the conversation reaches a point where an agency contact says something like: "But that's the payment portal vendor. We didn't build that. Can we really be held responsible for it?"
The answer is yes. Unequivocally.
The fact that a digital service is delivered through a third-party vendor's platform does not transfer the government agency's ADA Title II obligation to that vendor. The agency is responsible for ensuring that every digital surface through which it delivers services to the public is accessible — including surfaces built, hosted, and operated by someone else.
This surprises a significant number of agencies. And it creates a significant amount of exposure, because the third-party tools embedded in most government websites are among the most consistently inaccessible components in the entire digital environment. Payment portals, permit systems, chatbots, scheduling tools, mapping platforms, form builders, survey tools, document management systems — each one is a potential accessibility failure that the agency is legally responsible for addressing.
Understanding how that responsibility works, how to evaluate vendor tools, what to do when vendors have accessibility gaps, and how to structure contracts to protect the agency's compliance posture going forward is the subject of this guide.
Why Third-Party Tools Still Create ADA Liability
ADA Title II requires that state and local government entities provide equal access to their programs, services, and activities. The operative phrase is programs, services, and activities — not "programs, services, and activities that we built ourselves."
When a government agency uses a third-party payment portal to collect utility bills, that payment portal is how the agency delivers the service of bill payment to the public. When a government agency uses a third-party permit portal for building permit applications, that portal is how the agency delivers permitting services. When a government agency embeds a third-party scheduling system for appointment booking, that system is how the agency delivers scheduling services.
In each case, the service is the agency's. The platform is the vendor's. The accessibility obligation is the agency's.
The DOJ has been consistent on this point in enforcement activity and guidance. Title II entities cannot delegate their ADA obligations to private vendors. A government agency that says "our vendor is responsible for accessibility" is not describing a legal defense — it is describing a contractual arrangement that does not affect the agency's legal exposure one bit.
The practical consequence is that when an enforcement inquiry opens and the DOJ asks an agency to demonstrate the accessibility of its online payment portal, the response cannot be "that is our billing vendor's system, not ours." The inquiry is into the accessibility of the agency's bill payment service. The vendor is the implementation detail.
The Scope of the Problem: How Many Third-Party Tools Are on Your Website?
Before assessing the accessibility of vendor tools, most agencies need to simply inventory what they have. The number is almost always higher than anyone expects.
Consider a mid-sized city government website. A typical inventory might include:
Payment and billing:
- Online utility bill payment (vendor: [billing platform])
- Business license renewal payment (vendor: [business licensing platform])
- Parks and recreation program registration (vendor: [parks management platform])
- Court fine payment (vendor: [citation payment platform])
- Permit fee payment (vendor: [permit platform])
Service delivery:
- Building permit application portal (vendor: [permit management system])
- Public records request system (vendor: [records management platform])
- Online zoning inquiry and appeal submission (vendor: [planning platform])
- Job application system (vendor: [ATS platform])
- Volunteer registration (vendor: [volunteer management platform])
Communication and engagement:
- Live chat or chatbot (vendor: [chat platform])
- Newsletter signup (vendor: [email marketing platform])
- Social media embedded feeds (vendor: [social platforms])
- Public comment portal for environmental reviews (vendor: [engagement platform])
Mapping and data:
- GIS mapping tools (vendor: [Esri / ArcGIS / Mapbox])
- Property lookup and assessment data (vendor: [assessment platform])
- Flood zone map viewer (vendor: [GIS platform])
Content and media:
- Embedded video (YouTube — Google's platform)
- Document viewing (embedded PDF viewer platform)
- Translation widget (vendor: [translation service])
Calendaring and scheduling:
- Online appointment booking (vendor: [scheduling platform])
- Facility reservation system (vendor: [reservation platform])
- Event registration (vendor: [events platform])
That is potentially 20 to 30 third-party tools for a single mid-sized city. Each one is a publicly accessible digital service. Each one carries an accessibility obligation. Most agencies have evaluated the accessibility of zero of them.
What a VPAT Is (and What It Doesn’t Tell You)
VPAT stands for Voluntary Product Accessibility Template. It is a standardized document in which a technology vendor describes their product's conformance with accessibility standards — typically Section 508 and WCAG 2.1 AA.
Understanding what a VPAT is, what it tells you, and — critically — what it does not tell you is essential for using VPATs effectively in vendor accessibility evaluation.
What a VPAT Is
A VPAT is a self-assessment document. The vendor fills it out. There is no independent verification process, no third-party auditing requirement, and no certification that the contents are accurate. A vendor can write anything in a VPAT. There is no enforcement mechanism for VPAT inaccuracy beyond the reputational and legal consequences of misrepresentation.
The VPAT format is standardized — maintained by the IT Industry Council (ITI) — and the most current version for WCAG conformance is the VPAT 2.4 Rev 508 (WCAG) or VPAT 2.4 Rev INT (international). A VPAT lists every WCAG 2.1 success criterion and asks the vendor to indicate whether their product supports the criterion, supports it with exceptions, does not support it, or is not applicable.
What a VPAT Tells You
Known conformance gaps. When a vendor honestly discloses that their product "does not support" specific WCAG criteria — or "supports with exceptions" and describes those exceptions — that disclosure is valuable. It tells you where the product has known accessibility failures. A VPAT showing "does not support" for 2.1.1 (Keyboard) is telling you directly that the product has keyboard navigation failures.
The vendor's awareness of accessibility. The quality and completeness of a VPAT tells you a great deal about a vendor's accessibility maturity. A VPAT that marks everything as "Supports" without any exceptions or caveats is almost certainly not an honest assessment — no complex software product has zero accessibility exceptions. A VPAT with detailed, honest disclosure of specific limitations and workarounds demonstrates accessibility awareness.
The product version assessed. A VPAT should specify the version of the product it covers and the date of assessment. This matters because VPATs age — a product that was assessed two years ago may have significantly different accessibility status today, either better or worse.
What a VPAT Does Not Tell You
Independent verification. A VPAT is self-reported. A vendor who writes "Supports" for every criterion without actually testing their product has not lied to you in a provable way. The VPAT requires no evidence.
The actual user experience. A VPAT that says a product "supports" keyboard navigation does not mean the keyboard navigation is good, intuitive, or equivalent to mouse navigation — only that some keyboard navigation exists. "Supports with exceptions" can mean anything from a minor edge case to a major workflow failure.
Current accuracy. A VPAT dated 18 months ago does not reflect the current state of the product. Software updates frequently — and each update can introduce accessibility regressions. A VPAT is a point-in-time snapshot.
Your specific implementation. VPATs are written for the product, not for your specific implementation of the product. A product that supports WCAG 2.1 AA in its standard configuration may have accessibility gaps in the specific configuration your agency has deployed.
How to Read a VPAT
When evaluating a vendor VPAT, work through it in two passes.
First pass — identify "Does Not Support" and "Supports with Exceptions" entries. These are the disclosed accessibility gaps. For each one, read the remarks column — what specifically is the exception or failure? Is it in a core workflow (form submission, navigation, payment) or in an edge case? For "Supports with Exceptions" entries, is the exception minor or substantive?
Second pass — evaluate the plausibility of "Supports" entries. For a complex, interactive product — a payment portal, a permit management system, a scheduling platform — ask whether it is plausible that the product achieves full conformance with every listed criterion without any exceptions. If a product that includes custom dropdowns, date pickers, file uploads, and multi-step form flows claims zero exceptions for 2.1.1 Keyboard, 2.4.3 Focus Order, and 4.1.2 Name, Role, Value, that claim is implausible. The VPAT may not be accurately reflecting the product.
Third pass — assess the age and version. When was the VPAT produced? What version of the product does it cover? Is that the version your agency is using? A VPAT more than 18 months old should be treated as potentially outdated and a current VPAT should be requested.
How to Test Vendor Tools for Accessibility
VPATs tell you what vendors say about their products. Testing tells you what is actually true. Both are necessary.
For each third-party tool in your vendor inventory, conduct these basic tests before acceptance and on a schedule after deployment:
The Keyboard Navigation Test
Open the vendor tool. Put your mouse aside. Attempt to complete the primary workflow — make a payment, submit an application, complete a form, book an appointment — using only keyboard navigation.
Tab through every interactive element. Confirm every field receives focus. Confirm dropdowns can be opened and navigated with keyboard. Confirm date pickers can be operated with keyboard. Confirm file upload components work with keyboard. Confirm the submit action can be completed with keyboard. Confirm the completion confirmation is accessible.
If any step cannot be completed without a mouse, that step is an accessibility barrier the agency is responsible for addressing.
The Screen Reader Test
With NVDA running on Chrome (or VoiceOver on Safari), navigate the vendor tool using keyboard commands. Tab to each form field and confirm the label is announced. Submit with intentional errors and confirm error messages are announced. Complete the workflow successfully and confirm the confirmation is announced.
This test catches failures that keyboard testing alone misses — fields that receive focus but have no label, error messages that appear visually but fire no screen reader announcement, confirmation screens that render visually but are not announced.
The Automated Scan Test
Run axe DevTools on the vendor tool pages. Note all violations. Map them to WCAG criteria. Compare the findings to the vendor's VPAT — do the automated findings align with what the VPAT disclosed? Are there failures in areas the VPAT marked as "Supports"?
Automated scan findings that contradict VPAT claims are a signal to request explanation from the vendor.
What to Do When Vendor Tools Fail Accessibility
Most vendor tools have accessibility gaps. The question is what to do about them.
Step 1: Document the Gaps Formally
Before contacting the vendor, document the specific accessibility gaps you have identified — through VPAT review, your own testing, or both. Create a gap log that records:
- The specific WCAG criterion that is not met
- The specific element or workflow where the failure occurs
- A description of the barrier the failure creates
- Whether the issue was disclosed in the VPAT or discovered through testing
- The date the issue was identified
This documentation serves two purposes: it gives you specific, actionable items to raise with the vendor, and it creates the paper trail that demonstrates you identified the issue and took steps to address it.
Step 2: Raise the Issues Formally With the Vendor
Contact the vendor's accessibility team or account manager with a formal written communication — not a phone call, a written record — identifying the specific accessibility gaps and requesting:
A remediation timeline for each identified issue. A VPAT update that accurately reflects the current product's conformance status. A commitment to notify the agency when updates introduce new accessibility issues. A commitment to accessibility testing before major product releases.
The response — or non-response — from the vendor is itself important documentation. A vendor who responds with a detailed remediation timeline is behaving differently from a vendor who dismisses the concerns or provides vague assurances with no timeline.
Step 3: Build Accessible Alternative Pathways
While vendor remediation is in progress — or when vendor remediation is not forthcoming — the agency must provide accessible alternative pathways for residents who cannot use the inaccessible tool.
The accessible alternative pathway must be:
Communicated. The existence of the alternative pathway must be clearly communicated on the page where the inaccessible tool appears. A resident who encounters the inaccessible payment portal should not have to navigate to the accessibility statement to discover that they can pay by phone. The alternative should be on the same page, clearly labeled.
Functional. The alternative must actually work. A phone number for alternative payment that is only staffed during business hours is not a functional alternative for a resident trying to pay a bill at 8pm. The alternative must reach someone who can help or must be an automated system that is itself accessible.
Equivalent. The alternative must provide access to the same service. A resident who cannot use the online permit application because it is inaccessible should be able to complete the same permit application through the alternative pathway — not a reduced set of services or a different process with additional burdens.
Document the accessible alternative pathway — what it is, where it is communicated, and how residents access it — in the agency's compliance record.
Step 4: Escalate Through Contract Leverage
If a vendor does not respond to informal accessibility requests or provides timelines that are not acceptable, the next step is to escalate through whatever contract leverage the agency has.
For vendors whose contract is approaching renewal: accessibility requirements should be written into the renewal contract before signing. The leverage here is significant — a vendor who wants to retain the contract has an incentive to address accessibility concerns before renewal.
For vendors with existing contracts that include service level agreements: if the SLA includes provisions about standards compliance or regulatory compliance, accessibility failures may constitute an SLA breach. Consult with legal counsel about whether the contract provides remedies.
For vendors whose contract provides for termination for cause: if accessibility failures constitute material non-compliance with a contractual obligation, termination for cause may be available. This is a significant escalation that is rarely necessary, but it is available in some contract structures.
Step 5: Document Everything for the Compliance Record
Every communication with a vendor about accessibility — every request, every response, every commitment, every delay — should be documented and retained. This documentation demonstrates that the agency identified the issue, took action to address it, and has been engaged in good faith effort to remediate it.
An agency that identified a vendor accessibility gap six months ago, raised it formally with the vendor, received a remediation commitment with a timeline, and is monitoring against that timeline is in a fundamentally different compliance position than an agency that knows the gap exists and has taken no action.
The documentation tells the story of good faith effort. Without documentation, there is no story to tell.
How to Write Accessibility Requirements Into Vendor Contracts
The most powerful tool an agency has for managing vendor accessibility is the contract. Accessibility requirements written into a vendor contract at signing or renewal are enforceable obligations — not aspirational requests.
The following contract language provisions address the primary accessibility obligations for vendor-provided digital services.
Provision 1: Technical Standard
"Vendor warrants that the Software, including all user-facing interfaces, shall conform to the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA as published by the World Wide Web Consortium. Vendor shall maintain WCAG 2.1 Level AA conformance throughout the term of this Agreement."
This provision establishes the baseline technical standard and makes it an ongoing obligation, not a point-in-time delivery requirement.
Provision 2: VPAT Delivery and Update
"Vendor shall provide a current Voluntary Product Accessibility Template (VPAT) for the Software within 30 days of contract execution and shall update the VPAT within 60 days of any major product release or any change to the Software that materially affects its accessibility conformance. VPATs shall accurately reflect the current conformance status of the Software and shall identify all known accessibility exceptions and limitations."
This provision ensures the agency has current documentation of the product's accessibility status and that the vendor keeps it current.
Provision 3: Regression Notification
"Vendor shall notify Agency within 10 business days of any product update, release, or configuration change that introduces or is reasonably expected to introduce an accessibility regression — meaning a reduction in conformance with WCAG 2.1 Level AA from the previously established conformance level."
This provision catches the common problem of a vendor update that breaks accessibility that was previously working. Without this notification requirement, the agency may not discover a regression until a resident complains or the next accessibility audit.
Provision 4: Remediation Obligation and Timeline
"In the event that Agency identifies an accessibility failure in the Software — meaning a failure to meet one or more WCAG 2.1 Level AA success criteria — Vendor shall acknowledge the identified failure in writing within 10 business days and shall provide a remediation plan with a timeline for correction within 30 business days. Critical accessibility failures that prevent users from completing a core transaction shall be remediated within 90 days of identification. All other accessibility failures shall be remediated within 180 days of identification."
This provision establishes enforceable remediation timelines and creates the escalation path for unresolved failures.
Provision 5: Testing and Audit Rights
"Agency reserves the right to conduct accessibility testing of the Software at any time during the term of this Agreement, using automated testing tools and manual testing methods including keyboard navigation and screen reader testing. Vendor shall cooperate with Agency's accessibility testing requests and shall provide a test environment for Agency's use upon request."
This provision ensures the agency can verify vendor claims and conduct ongoing monitoring without vendor interference.
Provision 6: Subcontractor Obligations
"Vendor shall ensure that all subcontractors and third-party components used in the delivery of the Software meet the accessibility requirements set forth in this Agreement. Vendor remains responsible for the accessibility of the Software regardless of which components are provided by subcontractors."
This provision prevents vendors from pointing to their own subcontractors as the reason for accessibility failures — the same way agencies cannot point to their vendors.
The Vendor Accessibility Evaluation Scorecard
When evaluating vendors during a procurement process, use a standardized accessibility evaluation scorecard to compare candidates objectively. Include these evaluation criteria:
VPAT Quality (20 points)
- VPAT exists and is current (within 18 months): 5 points
- VPAT uses current VPAT format (2.4 or later): 3 points
- VPAT disclosures appear honest and specific (not "Supports" across the board for complex functionality): 7 points
- VPAT identifies specific exceptions with details: 5 points
Demonstrated Testing (25 points)
- Vendor can demonstrate keyboard navigation through primary workflow: 10 points
- Vendor can demonstrate screen reader compatibility in primary workflow: 10 points
- Vendor provides third-party accessibility audit report: 5 points
Contract Terms (25 points)
- Vendor accepts WCAG 2.1 AA conformance obligation in contract: 10 points
- Vendor accepts regression notification requirement: 5 points
- Vendor accepts remediation timeline provisions: 10 points
Track Record (15 points)
- Vendor can provide references from government clients regarding accessibility: 10 points
- No public record of significant accessibility-related legal actions: 5 points
Roadmap and Commitment (15 points)
- Vendor has a documented accessibility roadmap: 7 points
- Vendor has a named accessibility lead or team: 5 points
- Vendor participates in accessibility standards development or industry accessibility groups: 3 points
A vendor scoring below 60 out of 100 on this scorecard should be considered a high-risk selection from an accessibility compliance standpoint, regardless of other product capabilities.
Managing the Ongoing Vendor Accessibility Portfolio
Vendor tool accessibility is not a one-time evaluation at procurement. It requires ongoing management across the lifecycle of each vendor relationship.
At procurement: VPAT evaluation, demonstration testing, contract language negotiation.
At implementation: Pre-launch accessibility testing of the specific implementation configuration before go-live.
Ongoing (annually): VPAT review for updates, keyboard and screen reader testing of primary workflows, automated scan of embedded tool pages.
After major updates: Regression testing following any significant product release. The vendor's notification provision should trigger this testing, but the agency should also proactively test after major releases.
At renewal: Full accessibility review prior to contract renewal. Renewal is the point of maximum leverage — use it to require remediation of outstanding gaps as a condition of renewal or to incorporate stronger contract provisions.
The vendor accessibility portfolio — the inventory of third-party tools, their VPAT status, their known gaps, the accessible alternatives in place, and the contract provisions covering each — is a component of the agency's overall ADA compliance documentation record. It demonstrates that the agency has assessed its full digital environment and is managing third-party tool accessibility as an ongoing operational responsibility.
Related:
FAQ: Third-Party Tool Accessibility and ADA Liability
Is a government agency responsible for the accessibility of third-party tools embedded in its website? Yes. ADA Title II requires that state and local government entities provide equal access to their programs, services, and activities — including services delivered through third-party vendor platforms. A government agency cannot delegate its ADA accessibility obligations to a vendor. When an agency uses a third-party payment portal, permit system, or scheduling tool to deliver public services, that tool is part of the agency's service delivery and its accessibility is the agency's responsibility. The DOJ has been consistent in enforcement activity that Title II entities cannot escape their obligations by pointing to their vendors.
What is a VPAT and how should government agencies use them? A Voluntary Product Accessibility Template (VPAT) is a self-assessment document in which a vendor describes their product's conformance with accessibility standards. VPATs are not independently verified and are not a guarantee of accessibility. Government agencies should request current VPATs from all vendors whose tools are embedded in public-facing digital services, evaluate them by identifying disclosed gaps and assessing the plausibility of claimed conformance, and supplement VPAT review with their own keyboard navigation and screen reader testing. A VPAT more than 18 months old should be treated as potentially outdated and a current VPAT should be requested.
What should a government agency do when a vendor tool has known accessibility gaps? The response to vendor accessibility gaps has five components: document the specific gaps formally; raise them with the vendor in writing requesting a remediation timeline; build accessible alternative pathways for residents who cannot use the inaccessible tool in the interim; use contract leverage — particularly at renewal — to require remediation as a condition of continuation; and document every communication and commitment. An agency that has identified gaps, raised them with the vendor, established accessible alternatives, and documented the process is in a defensible compliance position. An agency that knows about gaps and has taken no action is not.
What accessibility language should government agencies include in vendor contracts? The most important contract provisions are: a WCAG 2.1 AA conformance warranty making accessibility an ongoing obligation throughout the contract term; a VPAT delivery and update requirement ensuring current documentation of accessibility status; a regression notification requirement so the agency is informed when product updates introduce accessibility failures; an enforceable remediation timeline for identified failures (90 days for critical failures blocking core transactions); audit rights allowing the agency to conduct independent accessibility testing; and a subcontractor obligation clause ensuring the vendor cannot point to their own vendors as a defense.
How often should government agencies test third-party vendor tools for accessibility? Vendor tools should be tested at procurement (as part of evaluation before selection), at implementation (before the tool goes live in the agency environment), annually (keyboard navigation and screen reader testing of primary workflows plus automated scan), and after major product updates (regression testing to confirm new versions have not introduced accessibility failures). The vendor contract's regression notification provision should trigger post-update testing, but agencies should also proactively test after any significant product release.
What is an accessible alternative pathway and when is one required? An accessible alternative pathway is a mechanism through which residents who cannot use an inaccessible third-party tool can access the same service through an accessible channel — phone payment, in-person service, email-based request. An accessible alternative is required whenever a third-party tool has accessibility gaps that prevent some residents from using it independently, and it must be in place from the moment the gap is identified until it is remediated. The alternative must be communicated on the same page as the inaccessible tool (not only in the accessibility statement), must be genuinely functional during the hours residents need it, and must provide access to the equivalent service rather than a reduced or more burdensome alternative process.