AI Summary
ADA Title II requires public K–12 districts, colleges, and universities to bring web content and mobile apps into conformance with WCAG 2.1 Level AA. On April 20, 2026, the Department of Justice issued an Interim Final Rule extending compliance dates by one year (DOJ 91 Fed. Reg. 20902), giving entities serving 50,000 or more people until April 26, 2027, and smaller entities until April 26, 2028. For EdTech and LMS vendors the practical effect is procurement rather than litigation: districts increasingly require a current VPAT or Accessibility Conformance Report, plus a completed HECVAT in higher education, before a product clears vendor review.
Here is the scenario that ends EdTech deals in 2026. Your product is strong, your pricing works, the district likes your demo. Then procurement asks for your Accessibility Conformance Report, and you do not have one.
That is ADA Title II web accessibility compliance from a vendor's seat. You are not the regulated party. Your buyers are, and they can only meet their obligation by buying software that already meets it.
The deadline moved in April 2026. The standard did not. This guide covers what Title II requires of you, where automated tooling stops working, and which documents clear a district RFP.
In This Guide
What does ADA Title II require of EdTech vendors?
ADA Title II binds public entities, not their vendors directly. The requirement reaches you contractually instead, through RFP criteria, accessibility clauses, and conformance documentation requests.
The technical standard is WCAG 2.1 Level AA. It covers web content and mobile apps a public entity provides, including most password-protected course content at public institutions. AAA is not required.
Here is the current compliance schedule:
ADA Title II & HHS Compliance Deadlines
| Covered entity | Compliance date | Standard |
|---|---|---|
| Public entities serving 50,000+ people | April 26, 2027 | WCAG 2.1 Level AA |
| Public entities serving under 50,000 | April 26, 2028 | WCAG 2.1 Level AA |
| Special district governments | April 26, 2028 | WCAG 2.1 Level AA |
| HHS-funded recipients, 15+ employees | May 11, 2027 | WCAG 2.1 Level AA |
| HHS-funded recipients, under 15 employees | May 10, 2028 | WCAG 2.1 Level AA |
One detail catches vendors off guard. Population is calculated at the state level, which means nearly all public universities fall under the earlier 2027 date rather than the later one.
Who owns what: the platform and content split
LMS ADA Title II compliance splits along a line that decides who gets blamed when an audit fails. The accessibility of the platform itself is the vendor's responsibility. The accessibility of the content published inside it is the institution's.
That sounds clean until you look at a real LMS. Every faculty member uploading a PDF, recording a lecture, or building a quiz is producing content inside the institution's obligation, using your authoring interface.
So sophisticated buyers ask a second question after the VPAT. Do your authoring tools help instructors produce accessible content by default, or quietly let them publish barriers at scale? A conformant platform that makes inaccessible output easy is a liability your buyer inherits.
Why did the DOJ extend the deadline, and does it help you?
The Interim Final Rule (91 Fed. Reg. 20902) moved dates. It did not weaken the standard, narrow the scope of covered content, or suspend the underlying civil rights obligation. That obligation predates the 2024 rule, which only set a technical benchmark for meeting it.
That distinction matters for how you plan. A vendor treating April 2027 as the start of accessibility work has misread the rule. Districts are running procurement cycles now for contracts that will be active on the compliance date, which means vendor evaluation is already applying the standard.
WebAIM's John Northup framed it well in May 2026: the extension is not a reprieve from accessibility, but a reprieve from panic. Rushed timelines produce superficial fixes and overlay products. A well-used year produces prioritized remediation and better procurement practices.
The market data says treat this as urgent. WebAIM's February 2026 analysis of the top one million home pages found 95.9% had detectable WCAG failures, up from 94.8% a year earlier. Average errors rose to 56.1 per page, a 10.1% increase.
After six consecutive years of improvement, the trend reversed.
Working with a compliance deadline on your roadmap?
Our technical scoping call maps WCAG requirements against your current architecture before development starts.
The Accessibility Procurement Gate: four stages buyers actually check
Most vendors treat accessibility as one task: run a scanner, fix what it flags, call it done. That fails at procurement, because a scan answers only the first of four questions an evaluation team asks.
We call this sequence the Accessibility Procurement Gate. Each stage closes a different category of risk, and skipping one leaves a gap your buyer's reviewer will find.
The Accessibility Procurement Gate Framework
| Stage | What it does | What it cannot do | Output |
|---|---|---|---|
| 1. Scan | Detects programmatically verifiable failures: contrast, missing alt attributes, unlabeled inputs, empty buttons | Judge whether alt text is meaningful, or whether focus order is logical | Error list |
| 2. Audit | Human evaluation with assistive technology across real user workflows | Scale to every page on every release | Findings report |
| 3. Document | Records conformance criterion by criterion, including known gaps | Substitute for actual remediation | VPAT / ACR |
| 4. Defend | Keeps conformance stable as the product ships new code | Work if accessibility checks sit outside CI | Regression suite |
Stage 4 is the one most vendors miss. Conformance is a state your product occupies on a given day, not a certificate you earn permanently. Without automated checks in the release pipeline, a product that passed audit in March can fail by June.
The arithmetic is unforgiving. A labeling failure caught at pull request costs a developer an hour. Caught during a pre-RFP audit, it costs a remediation cycle, a re-test, and an updated ACR, against a deadline you do not control.
Can AI-powered digital accessibility tools make you compliant?
No. AI-powered digital accessibility tools close part of the gap, never all of it. The UK Government Digital Service found automated scanners detect roughly 30–40% of known WCAG issues, with independent estimates ranging from 25–40% depending on the tool.
This is the most expensive misunderstanding in EdTech accessibility work. A clean automated report does not mean a conformant product. It means the machine-checkable subset passed.
Automated Detection Capability Matrix
| Failure type | Automated detection | Why |
|---|---|---|
| Low contrast text | Reliable | Computable ratio against a threshold |
| Missing alt attribute | Reliable | Attribute is present or absent |
| Missing form labels | Reliable | Programmatic association is verifiable |
| Empty links and buttons | Reliable | Accessible name is empty or not |
| Meaningful alt text | Not detectable | alt="image47.png" passes the presence check |
| Logical focus order | Not detectable | Requires judgment about content sequence |
| Keyboard traps | Not detectable | Often triggers only in specific interaction states |
| Screen reader narrative quality | Not detectable | Requires listening to the actual output |
| Dynamic content announcements | Not detectable | Depends on timing and user context |
Generative AI does help at two points. It drafts alt text at scale for image-heavy course libraries, subject to human review. And it generates test scaffolding so checks run on every pull request instead of once before an audit.
What it does not do is close the judgment gap. Overlays that claim otherwise are a legal risk, not a remediation strategy.
What is a VPAT, and does your EdTech product need one?
VPAT accessibility documentation is the currency of education procurement. A VPAT (Voluntary Product Accessibility Template) is the blank standardized form used to record how a product measures against an accessibility standard.
Once you complete it, it becomes an ACR (Accessibility Conformance Report). Buyers usually say "VPAT" when what they actually need is an ACR. Level Access notes that the distinction is fundamental to procurement literacy.
The word "voluntary" is misleading in the current market. Federal agencies have required these reports under Section 508 for years, and education procurement has followed.
VPAT vs. ACR Comparison
| Dimension | VPAT | ACR |
|---|---|---|
| What it is | Blank template | Completed report |
| Produced by | ITI (standards body) | Vendor or third-party evaluator |
| Editions | WCAG, 508, EN 301 549, INT | Matches the template edition used |
| Procurement value | None on its own | The document buyers evaluate |
| Requires testing first | N/A | Yes — claims must reflect real results |
Three practical notes:
- Choose the right edition. The WCAG edition covers most education sales. Use the INT edition if you sell across jurisdictions, since it consolidates US, EU, and international standards.
- Documented gaps do not disqualify you. An honest report noting partial support, with a remediation roadmap in the remarks column, generally survives evaluation. A report claiming full support that a reviewer disproves does not.
- Third-party evaluation carries more weight. Self-assessments raise questions about both technical capability and bias, and procurement teams weigh independently issued reports more heavily.
The document most vendors forget: HECVAT
Higher education adds a second gate. The HECVAT (Higher Education Community Vendor Assessment Toolkit) is EDUCAUSE's standardized questionnaire covering vendor security, privacy, IT accessibility, and compliance in one workbook.
HECVAT 4, released February 2025, merged the old Full, Lite, and On-Premise versions and added dedicated IT accessibility and AI governance sections. Many institutions require both a HECVAT and a VPAT for each product purchased.
Neither is a certification. What they decide is whether your product reaches technical evaluation at all, which makes them sales assets rather than compliance paperwork.
Where do accessibility failures actually come from?
The WebAIM data is uncomfortable for engineering teams. The same six failure categories have topped the list for seven consecutive years, and together account for 96% of all errors detected.
Top 6 WCAG Failures (WebAIM 2026 Analysis)
| Failure type | % of home pages affected (2026) | Direction since 2025 |
|---|---|---|
| Low contrast text | 83.9% | Increased |
| Missing image alt text | 53.1% | Decreased |
| Missing form input labels | 51.0% | Increased |
| Empty links | 46.3% | Increased |
| Empty buttons | 30.6% | Increased |
| Missing document language | 13.5% | Decreased |
None of these are obscure edge cases. They are basics, and they are getting worse rather than better.
The likely cause sits in how modern software gets built. WebAIM attributes the reversal to rising page complexity and ARIA usage, both of which correlate with more errors. It points at two drivers: heavier reliance on third-party frameworks and libraries, and AI-assisted coding practices.
The numbers are stark. Pages using ARIA averaged 59.1 errors against 42 for pages without it, and ARIA attributes rose 27% in a single year.
This is the argument for running accessibility checks inside the sprint. If a component library introduces a labeling failure, you want it caught at pull request review, not during a pre-RFP audit.
This is how we structure EdTech engagements at Hireplicity. WCAG 2.1 AA checks run on every UI component throughout the sprint, alongside FERPA data handling verification and COPPA age-gate testing.
Worth being precise about what that buys you. It covers the machine-checkable 30–40% and nothing beyond it. The judgment-dependent criteria still need human evaluation before an ACR can honestly claim conformance.
Need accessibility checks in your release pipeline?
We review your current test coverage and CI setup, then deliver a written gap analysis before any engagement starts.
How does Australia's DDA compare to ADA Title II?
Australian EdTech buyers apply a parallel framework. The Disability Discrimination Act 1992 (DDA) makes it unlawful to discriminate in the provision of goods, services, and facilities, and has been interpreted to cover websites and mobile applications.
Two differences matter. The DDA covers both public and private organisations, so it reaches further than Title II. And enforcement runs through complaints to the Australian Human Rights Commission rather than a fixed date, so there is no grace period to plan around.
In April 2025, the AHRC published guidelines recommending WCAG 2.2 Level AA, one step beyond what Title II requires. Government agencies also work to the Digital Inclusion Standard, with ICT procurement aligned to EN 301 549.
The gap is smaller than it sounds. If you already build to WCAG 2.1 AA for the US market, WCAG 2.2 adds nine success criteria covering focus appearance, target size, dragging alternatives, and cognitive accessibility.
Clear those nine, and one product line serves both markets.
Frequently asked questions
On April 20, 2026, the DOJ issued an Interim Final Rule extending the original deadlines by one year. Public entities serving populations of 50,000 or more must conform to WCAG 2.1 Level AA by April 26, 2027, and smaller entities and special district governments have until April 26, 2028. The technical standard is unchanged.
No. The UK Government Digital Service found automated scanners catch only 30–40% of known WCAG issues. Scanners verify computable properties such as contrast ratios and attribute presence, but cannot judge whether alt text is meaningful or whether a screen reader announcement makes sense. Human evaluation closes the rest.
Increasingly, yes. Education procurement teams commonly request an Accessibility Conformance Report during vendor evaluation, and products without one are often removed from consideration before technical review. Documented gaps with a remediation plan are generally acceptable; unsupported claims of full conformance are not.
Title II covers public entities. Private institutions fall under Title III, and EdTech vendors are not directly covered by either. In practice the standard reaches vendors through contracts, because public entities must procure software that lets them meet their own obligation.
A VPAT documents how your product measures against accessibility standards, becoming an ACR once completed. A HECVAT is EDUCAUSE's broader questionnaire covering security, privacy, IT accessibility, and AI governance in one workbook. Higher education institutions commonly require both documents for each product being purchased, and neither is a certification.
The DDA covers both public and private organisations, making it broader in scope than Title II. It has no fixed compliance deadline, because enforcement runs through complaints to the Australian Human Rights Commission. AHRC guidance recommends WCAG 2.2 Level AA, one version ahead of the Title II requirement.
The bottom line
ADA Title II web accessibility compliance is a procurement gate before it is a legal one. The DOJ extension gave covered entities another year, but districts are evaluating vendors now against contracts that will be live in 2027, and the standard itself never moved.
The vendors clearing that gate do three things. They run automated checks continuously rather than before an audit, and pair them with human evaluation. Then they document conformance honestly, gaps included, in a report a reviewer can verify.
If accessibility is currently a pre-launch scramble rather than part of your build process, that is a solvable engineering problem. It is also far cheaper to solve before an RFP than during one.
Ready to build accessibility into your delivery process? Taylor Basilio or a senior architect will review your stack, surface your WCAG and FERPA requirements, and give you a written scope document. No commitment required.
Build WCAG 2.1 AA Conformance Into Your Product
Schedule a 30-minute architecture review with Taylor Basilio. We will evaluate your current codebase, map your WCAG and FERPA gaps, and deliver a written scope document in 48 hours.
Sources & References
- U.S. Department of Justice — Interim Final Rule, Nondiscrimination on the Basis of Disability; Accessibility of Web Information and Services of State and Local Government Entities (91 Fed. Reg. 20902) (April 20, 2026) — https://www.federalregister.gov/documents/2026/04/20/2026-06954/
- WebAIM — The WebAIM Million 2026 Report on the Accessibility of the Top 1,000,000 Home Pages (February 2026) — https://webaim.org/projects/million/
- WebAIM — An Extension is Not an Excuse (John Northup, May 2026) — https://webaim.org/blog/an-extension-is-not-an-excuse/
- UK Government Digital Service — Automated accessibility tool audit results — https://alphagov.github.io/accessibility-tool-audit/
- Level Access — VPATs and ACRs: What You Need to Know — https://www.levelaccess.com/blog/vpats-and-acrs-what-you-need-to-know/
- Australian Human Rights Commission — Guidelines on Equal Access to Digital Goods and Services — https://humanrights.gov.au/
- Australian Government Digital Transformation Agency — Digital Inclusion Standard (Criterion 4: Make it accessible) — https://www.digital.gov.au/policy/digital-experience/digital-inclusion-standard/dis-criterion-4-make-it-accessible
- EDUCAUSE — Higher Education Community Vendor Assessment Toolkit (HECVAT 4) — https://www.educause.edu/hecvat
