Under the DOJ’s 2024 update to ADA Title II, outsourcing a platform does not outsource responsibility. If an institution provides a digital service to students, it is accountable for that service meeting WCAG 2.1 Level AA — regardless of who built it. Accessibility gaps often surface after launch, when leverage is limited and remediation is costly.
That makes procurement the point where accessibility risk is controlled — or inherited.
Building a defensible procurement strategy under ADA Title II for higher Under the DOJ’s 2024 rule, public colleges and universities are responsible for ensuring that digital services — including LMS platforms, registration portals, and financial aid systems — conform to WCAG 2.1 Level AA.
Even when those systems are provided by third-party vendors.
Integrating accessibility into vendor selection, contracts, and oversight is not optional under Title II. It is the moment where leverage is built.
Yet, our survey reveals that only 38% of educational institutes rely on independent testing to verify vendor claims.
Without structured procurement controls, institutions risk accepting accessibility assurances they cannot validate. The following steps outline how to close that gap.
Step 1: Build leverage early
If you wait until an LMS or student portal is launched to think about accessibility, you have already lost your primary source of leverage.
You must decide that accessibility is a core requirement before you even start looking for a solution. Our survey found that nearly 40% of institutions only sometimes consider accessibility during procurement.
To ensure this priority is clear from the start:
- Define the standard: In every RFP and project brief, explicitly state that all deliverables must conform to WCAG 2.1 Level AA.
- Assign weight to accessibility: When scoring vendor bids, give accessibility the same importance as security or cost. If a student can’t register for classes or access course materials, the product isn't functional.
- Set the expectation: Make it clear to potential partners that accessibility defects are "showstoppers" that can pause project milestones, implementation, or payments.
Why this matters: Procurement is where leverage is built — or lost.
Procurement determines whether accessibility is enforceable — or expensive.
Under Title II, if requirements aren’t built into the contract, your institution inherits the risk.
Step 2: Share the responsibility correctly
A successful strategy relies on a clear division of labor.
By defining roles upfront, you ensure that when a barrier is found, there is a clear path to a fix rather than a cycle of finger-pointing between the IT department and the vendor.
In practical terms, it can mean dividing ownership as follows:
- The vendor’s job (The Platform): The vendor is responsible for the code, navigation menus, and overall framework of tools like Canvas or Blackboard. They must ensure their "engine" supports your WCAG 2.1 AA obligations.
- Your job (The Content): Your institution is responsible for what you put "inside" the engine. This includes faculty-authored syllabi, images uploaded by staff (ensuring they have alt text), and the accessibility of PDFs or videos posted in the LMS.
Our survey results show institutions are split on vendor responsibility: 50% say ownership is very clear, while the other 50% report it is unclear.
Why this matters: Shared responsibility is not share liability
When ownership is unclear, fixes stall. If a barrier appears in an LMS or portal, teams may debate who is responsible instead of resolving it quickly. Under Title II, the institution remains accountable — even when the platform is vendor-owned.
Step 3: Write accountability into the contract
Your contracts should include enforceable language that protects your agency and provides a safety net if a product falls short. To create this legal protection, your agreements should include:
- Vendor-paid fixes: A commitment by the vendor to fix any accessibility bugs in their platform code at their own expense, not yours.
- Updates stay accessible: A rule that future software updates must not break or remove any existing accessibility features.
- Approval to launch: A "gatekeeper" clause that allows you to delay a launch if the product fails a final accessibility test.
Budget still shapes accessibility leverage
What did our panel of 300 High Education experts say? 31% report budget constraints as a limitation in what can be required or enforced in procurement.
Why this matters: Budget decisions don’t remove responsibility — they shift it
When procurement buys remediation debt instead of leverage, institutions lose the authority to compel fixes after launch. Vendors may label barriers as “known issues” leaving institutions to manage costly workarounds.
Step 4: Verify vendor claims
Most vendors provide a VPAT (Voluntary Product Accessibility Template) to show their product is accessible. Once a vendor fills out a VPAT, it becomes an ACR (Accessibility Conformance Report). You must treat this document as a starting point, not a guarantee. To ensure you aren't stuck with a vendor’s mistakes, you should:
- Verify the version: Check that the report matches the exact software version you are buying. If a vendor gives you a report from an older version, ask for the current one.
- Look for "remarks": A reliable report doesn't just say "Supports"—it explains how the feature works for people with disabilities in the "Remarks" column. If the notes are blank, the product hasn't been properly tested.
- Challenge "perfect" scores: No complex platform is 100% accessible. If a vendor claims total support with zero known issues, ask them to provide their testing methodology or a roadmap for future fixes.
When it comes to verifying vendor accessibility claims, our respondents provided interesting insights. While 45% of institutions rely on vendor documentation during procurement, 56% say independent validation gives them greater confidence — yet only 38% actually conduct independent testing.
Why this matters: Defensibility depends on verification — not documentation alone
Treating a VPAT as proof of compliance is a mistake. It is vendor-provided documentation — not independent verification. A defensible posture requires validating claims, not relying on them. A VPAT shows what a vendor says; independent testing shows what users experience.
Supporting a defensible procurement strategy
With the April 2026 deadline for ADA Title II approaching, a defensible procurement posture requires more than vendor documentation. It requires independent validation, accurate reporting, and ongoing oversight.
accessiBe’s accessServices provide professional support for accessibility testing, VPAT development, and documentation management — helping institutions identify barriers automated tools may miss and maintain current, publicly available Accessibility Conformance Reports (ACRs) as digital services evolve.
Accessibility in procurement is not about selecting a perfect vendor. It is about maintaining enforceable standards and structured oversight over time.
Speak with a Title II accessibility expert for a one-on-one review of your procurement strategy.
Frequently asked questions about Higher Ed procurement and Title II
Q1. Are public universities responsible for the accessibility of third-party vendor platforms?
A1. Yes. Under ADA Title II, your institution is legally responsible for the accessibility of any digital service it "provides or makes available," regardless of whether the platform is owned or hosted by a third-party vendor. This includes Learning Management Systems (LMS), enrollment portals, and financial aid tools.
Q2. What is the difference between a VPAT and an ACR?
A2. A Voluntary Product Accessibility Template (VPAT) is the blank form used to document a product’s accessibility. Once a vendor completes this form, it becomes an Accessibility Conformance Report (ACR). While these documents are standard in procurement, you should treat them as a starting point and verify the claims through independent testing to ensure they accurately reflect the current software version.
Q3. How can we ensure vendor accountability in our contracts?
A3. To protect your institution, contracts should include enforceable language requiring the vendor to conform to WCAG 2.1 Level AA. Key clauses should include vendor-paid fixes for accessibility bugs, a requirement that future updates do not break accessibility features, and the right to delay launch if a product fails a final accessibility test.
Q4. Who is responsible for the content inside a third-party platform?
A4. Responsibility is typically shared. The vendor is responsible for the "engine"—the code, navigation, and framework of the platform itself. Your institution is responsible for the content put "inside" that engine, such as faculty-uploaded syllabi, lecture videos, and course readings.
Q5. Can we buy a product that isn't fully accessible if we provide a workaround?
A5. Under Title II, you cannot rely solely on a reactive "upon request" model or phone workarounds for essential student services. When procurement "buys remediation debt" by selecting an inaccessible platform, the institution inherits the legal risk. Digital services must be accessible by default to provide equal access to all students.
Q6. What should we do if a vendor provides a "perfect" ACR with no errors?
A6. No complex platform is 100% accessible. If a vendor claims total support with zero known issues, you should ask for their specific testing methodology and a roadmap for future fixes. Independent validation is often necessary to confirm what users actually experience.
Q7. How can accessiBe help our institution manage vendor accessibility?
A7. As part of an end-to-end accessibility platform combining the best in AI automation, human expertise, and developer tools, accessiBe’s accessServices provides professional support for procurement efforts. We offer manual accessibility testing to verify vendor claims, professional VPAT creation to document your own digital assets, and expert-led audits to help you identify barriers that automated tools might miss.
