EdTech Accessibility Compliance for Software Builds

EdTech platforms must meet WCAG 2.2 Level AA, Section 508, and, where applicable, ADA Title III requirements before launch. Retrofitting costs 3 to 5 times more than building compliant from day one. Compliance affects architecture, component libraries, video infrastructure, and your testing pipeline, not just colour contrast and font size.

This post is written for EdTech founders and product leads who are either planning a new software build or preparing to scale an existing platform into institutional markets, specifically K-12 districts, higher education, and corporate L&D. If you are selling to a school district, a state university system, or any federally funded programme, accessibility compliance is a procurement requirement. Not a nice-to-have. Procurement teams will send you a VPAT before they send you a contract.

Most general guides on accessibility treat this as a design problem. For EdTech, it is an engineering problem that touches your architecture decisions from week one. A quiz engine built on a custom canvas element, a video player that does not expose its controls to screen readers, a drag-and-drop activity with no keyboard equivalent: each of those can disqualify you from a district RFP worth six figures. The stakes are real. And the technical decisions that create these problems get made early in the build, often before anyone has thought about compliance at all.

Here is what you actually need to know before you write a line of code.

So, what do the standards actually require?

Three regulatory frameworks govern EdTech accessibility in the US market, and they overlap in ways that confuse even experienced teams. And honestly? Most founders do not figure this out until a procurement officer sends back a VPAT request and the whole deal stalls.

WCAG 2.2 Level AA is the international technical standard published by the W3C. It defines four principles: perceivable, operable, understandable, and robust. Level AA is the threshold that matters commercially. Level A covers the floor, and Level AAA is aspirational, often impractical for dynamic applications. The 2.2 update, which replaced 2.1 as the active standard in late 2023, added nine new success criteria. The ones EdTech teams consistently underestimate are 2.4.11 through 2.4.13 (focus appearance), 2.5.7 (dragging movements), and 3.2.6 (consistent help). If your platform has interactive assessments or manipulatives, 2.5.7 alone can require significant rework.

Section 508 applies to federal agencies and any entity receiving federal funding, which includes most public schools and universities. Technically, Section 508 references the WCAG 2.0 Level AA standard. But in practice, procurement officers increasingly expect 2.2 conformance. The gap between what the law technically requires and what your buyer actually expects is something to handle carefully in your VPAT. Not the same thing. Worth understanding the difference before you sign anything.

ADA Title III has been increasingly applied to software products through Department of Justice rulemaking and case law. The DOJ published a final rule in April 2024 explicitly adopting WCAG 2.1 Level AA for state and local government web content. Private sector EdTech platforms are not directly covered by that rule, but plaintiff attorneys and institutional buyers both watch these developments closely. Building to WCAG 2.2 AA puts you ahead of where the law is moving. I think that is the only sensible position here.

The architecture decisions that create compliance debt

Compliance is not something you layer on after your MVP is feature-complete. The decisions that cause the most expensive remediation problems are made in the first sprint. That is not an exaggeration. We have seen it enough times to say it with some confidence.

This is similar to how architectural decisions in your technical infrastructure carry long-term consequences. What investors look for in SaaS architecture often includes compliance-ready design patterns, and for good reason.

Component library selection is probably the single biggest decision you will make on this front. Libraries like Radix UI, Headless UI, and Adobe's React Spectrum are built with accessibility semantics embedded. They surface ARIA roles, manage focus correctly, and expose keyboard navigation patterns that sighted users never notice but screen reader users depend on entirely. Libraries that prioritise visual flexibility over semantic structure, or custom-rolled component systems built quickly to hit a launch date, consistently produce the worst accessibility debt. One EdTech startup we work with spent $140,000 on a remediation engagement after choosing a visually impressive component library that had almost no ARIA support. They had to rebuild their assessment engine from scratch. That is not a rounding error on anyone's budget.

Video and media infrastructure is the second major category. WCAG 1.2 requires captions for pre-recorded video, audio descriptions for visual content, and transcripts for audio-only content. If your platform hosts instructor-created video, you need a captioning workflow that is either automated with human review or fully manual. Vendors like Rev, 3Play Media, and Verbit integrate with platforms at different price points. Automated captioning alone sits around $0.25 per minute. Human-reviewed captioning runs $1.50 to $3.00 per minute. At scale, that is a real operating cost line, not a footnote. If you are building a platform where users upload video, you need to decide at architecture stage whether you are providing captioning tooling, requiring it, or accepting the compliance risk of neither.

Assessment and interaction design is where EdTech diverges most sharply from general web accessibility guidance. Drag-and-drop, timed assessments, canvas-based drawing activities, and interactive simulations all have specific accessibility requirements that a basic WCAG checklist walkthrough will not surface. WCAG 2.5.7 requires that any functionality using a dragging movement has a single-pointer alternative. That means every drag-and-drop question in your quiz engine needs a keyboard-operable or click-based alternative pathway. If you have a simulations product or a coding environment, the complexity goes up substantially. Platforms like Khan Academy and Duolingo have published parts of their accessibility engineering work publicly. Studying their approaches for interactive content is more useful than most third-party guides. Most teams skip this research. Which costs them later.

Authentication flows are consistently overlooked. Session timeouts must warn users before expiry and allow extension, per WCAG 2.2.1. If your LMS auto-logs users out after 20 minutes of inactivity during a long assessment, you need to handle that warning accessibly. Small issue. Frequently cited in platform audits.

What a compliant build actually costs, honestly

Numbers vary significantly by platform complexity, but here are realistic ranges based on builds in the EdTech space in 2026.

For a new build with accessibility integrated from the start, expect 15 to 25 percent additional development time compared to a baseline build that ignores compliance. On a $300,000 initial build, that is $45,000 to $75,000 in additional engineering time. That sounds like a lot. It is not, relative to the alternative.

Accessibility audits from firms like Deque, TPGi, or Level Access run $15,000 to $60,000 depending on scope, and that is before any remediation work. Remediation on a platform that was not built with accessibility in mind commonly runs two to four times the audit cost. A district RFP worth $500,000 disappearing because you could not produce a credible VPAT is a far worse outcome than spending $60,000 more on the original build. Engineering audits at key moments in your product development can prevent this exact scenario, which is worth understanding before you hit that wall.

Personally, I think the math here is obvious. But we keep seeing teams skip it anyway.

If you are selling into K-12 at any meaningful scale, budget for annual audits and a maintained VPAT. Accessibility is not a one-time certification. WCAG versions update, your product changes, and institutional buyers may request re-audits as part of contract renewals. Not sometimes. Often times.

Building your VPAT: what buyers are actually reading

A Voluntary Product Accessibility Template (VPAT) is a structured document where you self-report your conformance against each WCAG success criterion. The current version is VPAT 2.5, which covers WCAG 2.1. You will likely want to address 2.2 criteria in a supplementary section, or use an updated template as it becomes available.

Look, procurement teams at larger institutions have seen enough VPATs to recognise when one was written by a marketing team to sound compliant versus when it was produced by someone who actually tested the product. "Supports with exceptions" is a credible answer. "Supports" across the board for a complex interactive platform is not. Buyers will push back, and if they discover the VPAT was inaccurate during an evaluation, the deal is over. Full stop.

The most defensible VPATs are produced after formal testing with both automated tools and actual assistive technology users. NVDA and JAWS on Windows, VoiceOver on macOS and iOS, and TalkBack on Android cover the primary screen reader environments your users are likely using. Testing with real users who rely on these tools will surface issues that automated scanners, which catch roughly 30 to 40 percent of WCAG failures, will never find. That gap, 30 to 40 percent detection on automated tools, is the part that burns teams. Automated scans feel thorough. They are not.

When to bring in an accessibility specialist

Most EdTech teams bring in accessibility consultants after a failed audit or a lost deal. My advice? Do not wait for that moment. The better model is embedding accessibility review into your design and engineering process before components are built. Before. Not during, not after.

If your team does not have in-house expertise, a fractional accessibility consultant during the architecture and design phase, typically a $5,000 to $15,000 engagement, will return its cost many times over. They will flag component library risks, review your interaction design patterns, and give your engineers a specific set of implementation criteria rather than the abstract language of the WCAG documentation. Abstract language that, and let's be real, most engineers do not have time to interpret correctly under deadline pressure.

For ongoing compliance as your platform grows, assign ownership explicitly. Accessibility debt accumulates the same way technical debt does: invisibly, through hundreds of small decisions made by people who were not thinking about it. One person on your product or engineering team who owns the accessibility backlog and reviews new features against WCAG criteria is more effective than periodic external audits alone. We keep saying this to clients. Most of them nod and then do not actually assign the role. You know how that goes.