Accessibility Compliance in EdTech Product Development Under WCAG and Section 508

Section 508's technical bar is WCAG 2.0 Level AA. It hasn't moved since the Access Board set that bar in the 2017 ICT Refresh, with compliance required by January 18, 2018. Everything else in accessibility law has kept moving forward, and Section 508 is still standing at that intersection.

The actual gap is this. ADA Title II, finalized in 2024, requires WCAG 2.1 AA for public entities. The design community has already moved on to WCAG 2.2 as the working target for new builds. And WCAG 3.0 dropped a working draft in March 2026, signaling that the ceiling is about to move again. WCAG 2.2 also picked up nine new success criteria beyond 2.1, things like keyboard focus indicators, minimum target sizes, and consistent help mechanisms, and now carries the ISO/IEC 40500:2025 designation, putting global procurement weight behind it.

So when a vendor hands you a Section 508 conformance claim as proof of "compliance," what they're actually handing over is a floor poured in 2018. The enforcement and procurement landscape is operating against a ceiling that's a lot higher and still rising. Your team is navigating with a chart from 2018 while the coastline has moved.

The Standards Hierarchy EdTech Teams Operate Inside

Here are the three layers, each enforcing differently.

Section 508 covers federal agencies and their vendors, enforced through procurement paperwork, VPATs, and agency audits. ADA Title II covers state and local government bodies, which for EdTech means public school districts, community colleges, and state universities, enforced through DOJ action and OCR complaints. ADA Title III applies to private schools and universities as places of public accommodation, with WCAG standards informing the accessibility obligations in that space. Section 504 reaches almost every institution that touches federal student aid, producing broad federal exposure across higher education.

As an EdTech vendor, you get hit from both directions at once. Your own products can draw Title III claims directly, and every public institution buying their software is under its own Title II obligation to hit WCAG 2.1 AA, which flows straight down into the vendor's procurement paperwork.

And that's before the rest of the stack piles on. FERPA's "School Official Exception" governs how vendors touch student data. COPPA's revised opt-in consent model has a compliance deadline of April 22, 2026. The European Accessibility Act took effect June 28, 2025, and it applies to SaaS sold to EU consumers no matter where the company is headquartered. Colorado's HB 21-1110 required WCAG 2.1 AA for state and local government digital services, education platforms included, by July 1, 2024, extended to July 1, 2025 for entities showing good-faith progress under HB 24-1454. Several other states run their own ICT accessibility statutes too.

SOC 2 Type II is a security certification. It says nothing about FERPA, nothing about COPPA, and nothing about WCAG. EdTech teams conflate these constantly, and it's an easy mistake to make since both appear on the same vendor questionnaire. But passing a SOC 2 audit and being accessible are two completely separate achievements.

Whichever standard is strictest sets the real ceiling you have to build to.

ADA Title II Deadlines Reshaping Public EdTech Procurement

DOJ finalized its ADA Title II web rule in April 2024. Every state and local government entity, public school districts, community colleges, and state universities included, now has to conform to WCAG 2.1 Level AA across web content and mobile apps. The original deadlines were April 24, 2026 for entities serving populations of 50,000 or more, and April 26, 2027 for smaller entities and special districts.

Then, in April 2026, DOJ issued an Interim Final Rule pushing both dates back a year. Larger entities now have until April 26, 2027. Smaller entities get until April 26, 2028. What didn't budge: the standard itself, the scope, or the exceptions.

Treat that extension as a scheduling adjustment on DOJ's enforcement calendar. OCR complaints don't wait for a federal deadline. Private Section 504 suits don't wait either. State laws like Colorado's are running on their own separate clocks.

The exceptions built into the rule are narrower than they sound on paper. Password-protected LMS course content is exempt right up until a student with a relevant disability enrolls in that course, at which point the exception evaporates. If you build a compliance plan around that exception, you produce a rush remediation job the week a student needs it least.

If you're a public institution buyer, you are working against a real deadline, whether or not you've internalized it. If your EdTech product lacks a current Accessibility Conformance Report (ACR) or Voluntary Product Accessibility Template (VPAT), it is turning into a hard sell to schools. Procurement offices increasingly won't sign without one.

How Enforcement Lands: Lawsuits and Procurement

UsableNet's report found that more than 5,000 digital accessibility lawsuits were filed in 2025, close to a 20% jump over the prior year. Of those filings, 1,427, somewhere around 45 to 46% of the federal total, targeted companies that had already been sued before.

That repeat-defendant number is the real story, more than the raw volume. A huge share of these organizations settled once, patched the surface, and got sued again for the exact same underlying defect. If you settle without fixing the root cause, you substantially increase the risk of a second lawsuit.

Settlements run from $5,000 to $75,000 per the Clym 2025 figures, and that's before attorney fees, redesign costs, and ongoing monitoring get added on. High-profile cases regularly clear $100,000 once all of that's tallied. Higher ed represents a modest slice of annual filings by volume, but the dollar exposure per case runs high because remediation in a university system means fixing everything at once. Notable settlements over uncaptioned course video remain a reference point for how Title III reaches into online learning content.

Overlay widgets don't provide the legal shield you might think they do. UsableNet's midyear report found that about 22.6% of ADA filings in the first half of 2025 targeted sites already running an overlay or widget. The FTC made the point even sharper in 2025, requiring overlay provider accessiBe to pay $1 million to settle claims it made deceptive promises about the product's ability to deliver WCAG compliance.

Federal procurement is tightening its own grip too. GSA pulled 12 products off IT Schedule 70 in 2024 over missing or inaccurate VPATs, and procurement officers hold the power to reject a product, cancel a contract, or demand remediation at the vendor's own cost. Meanwhile the federal government's own conformance is sliding: GSA's FY 2025 Governmentwide Section 508 Assessment found only 37% of top-viewed public web pages fully conformed, and the governmentwide score dropped from 1.79 to 1.74 on a 5-point scale, the lowest mark ever recorded.

Where EdTech Products Fail WCAG in Practice

The WebAIM Million 2025 report found detectable WCAG conformance failures across the vast majority of the world's top one million home pages. The 2026 edition shows errors still present across 3.9% of all page elements, with average page complexity up 22.5% in a single year. Pages are getting more complicated and the error rate isn't shrinking to match.

The recurring offenders, consistent across WebAIM and Section 508 procurement audits alike, include the following: missing image alt text, insufficient color contrast, form fields with no labels, links with empty text, and video or audio with no captions or transcripts.

EdTech has its own specialty failures on top of that list. LMS content built from source documents that were never accessible to begin with is visible constantly across Canvas, Moodle, Blackboard, and Google Classroom. Math content rendered as a static image instead of MathML leaves screen reader users with no equation, no text equivalent, just a gap where the formula should be. Data visualizations fall squarely under Title II's definition of "web content," meaning the same rules for text alternatives, contrast, and keyboard navigation apply to a bar chart as to a paragraph, yet plenty of platforms still treat charts as pure decoration. PDFs remain a perennial failure zone. And dynamic, JavaScript-heavy interfaces, single-page app routing, modals, live regions, and third-party widgets bolted on after the fact, create exactly the kind of failure points a standard automated scan glides right past.

There's a structural reason education's accessibility problems run deep: the content doesn't come from one engineering team. It comes from thousands of individual authors, professors, instructional designers, and administrators, each uploading a slide deck or a scanned worksheet with zero accessibility training. That's why an accommodation-on-request model breaks down at scale, and why you have to build accessibility into the pipeline itself rather than patch it in per request. AI-generated content adds a fresh wrinkle here too. AI tools can draft a course module or generate alt text suggestions, but you still need a human check against WCAG, PDF/UA, and EPUB Accessibility standards before the output goes anywhere near a student. Generation is not the same step as verification.

The population at stake isn't a rounding error. Around 15% of U.S. public school students receive special education services under IDEA, and roughly 19% of undergraduates report having a disability. That's a meaningful share of every single institution's enrolled population.

Why Automated Testing Alone Cannot Close Gaps

Automated scanners catch somewhere around 30 to 40% of WCAG issues by most estimates, though Deque Systems' 2025 figures put automated WCAG coverage closer to 57% by volume. Even a generous reading of either number leads to the same conclusion: a human review must find the majority of failures.

Automation is genuinely good at the mechanical stuff. Missing alt text, contrast ratios, unlabeled form fields, and empty links get caught reliably by a scanner running in a CI/CD pipeline. What automation cannot do is sit in a screen reader and notice that the reading order jumps around, or that a modal traps keyboard focus and won't let go, or that an interface is technically operable but cognitively exhausting to use. Those failures are the ones that actually stop a student from finishing an assignment, and no automated crawler reliably detects them.

The DHS Trusted Tester program, now at version 5.1.3 as of April 2024, remains the closest thing to an approved manual protocol for the federal supply chain. That update improved the course's plain language, dropped the passing score from 90% to 85%, and added a feedback mechanism for participants, though it didn't specifically deepen evaluation of interactive elements, PDFs, or keyboard operability.

A testing program that holds up under scrutiny needs four components working together: automated scanning wired directly into the CI/CD pipeline to catch regressions before they ship, manual expert review against WCAG 2.1 AA at minimum, hands-on testing with screen readers and keyboard-only navigation, and testing with actual people with disabilities, which remains the standard regulators and courts find most convincing.

Fixing an accessibility issue during design costs a fraction of what it costs to fix after launch, once the flaw is baked into thousands of pages of content. That's the whole logic behind shift-left testing: catch it early, and build accessibility criteria directly into your definition-of-done checklist rather than treating it as a final QA pass. Newer AI-assisted tools, Axe Dev Tools Mobile among them, have pushed automated coverage further into native mobile apps and dynamically rendered UI states. That's real progress, though it is not a replacement for a human reviewer evaluating whether a real person could actually use the product.

Building Durable Conformance, Not Minimum Compliance

POUR, Perceivable, Operable, Understandable, and Robust, works better as a running checklist during your development process than as a definition memorized once and forgotten.

Perceivable means text alternatives for every piece of non-text content, a 4.5:1 contrast minimum, captions on every video, and transcripts for every audio file. Operable means full keyboard navigation with no traps, no flashing or strobe effects, and focus that never gets hidden behind other content, a requirement WCAG 2.2 formalized as success criterion 2.4.11. Understandable means errors get flagged with actual guidance on how to fix them, navigation stays consistent from page to page, and the page declares its own language. Robust means semantic HTML as the default, MathML instead of image-rendered equations, and ARIA used only where plain HTML genuinely falls short.

SaaS products built on JavaScript-heavy frameworks carry their own scoping complexity. Third-party integrations, modal windows, single-page app routing, live regions, and widgets added after initial build all need accessibility testing baked into your component library specification. Data visualizations deserve particular attention given that public schools account for roughly 70% of the K-12 EdTech market. A chart that fails accessibility review becomes a procurement disqualifier.

And the liability doesn't stop at the vendor's own code. Public institutions can't hand off their Title II obligations to a vendor and call the risk gone, and vendors can't hand off their own ACR accuracy to a third-party widget nobody bothered to test. Every embedded component, whether built in-house or licensed from somewhere else, becomes part of the product's conformance claim the moment it ships. There's no such thing as someone else's accessibility bug once it's living inside the product a school actually bought.