EdTech Accessibility: Engineering for WCAG Compliance and the ADA Title II Deadline

The Department of Justice's 2024 rule under Title II of the Americans with Disabilities Act changed the compliance landscape for every public school district and public higher education institution in the country. For the first time, web content and mobile apps operated by state and local government entities — including K-12 districts and public universities — must conform to WCAG 2.1 Level AA, with compliance deadlines phased based on the population size of the jurisdiction served. That mandate doesn't stop at the district's own website. It extends to every LMS, assessment platform, parent portal, and third-party EdTech tool a district procures and puts in front of students, staff, and families.

For EdTech vendors and the engineers building district-facing software, accessibility is no longer a legal afterthought handled by a compliance widget. It's a product requirement with real procurement consequences: districts are increasingly asking vendors for VPATs before a contract is signed, and an accessibility defect discovered after deployment is far more expensive to fix than one caught in a pull request. This article covers what WCAG 2.1 AA actually requires at an engineering level, why overlay-based "quick fixes" don't satisfy it, how to build accessibility testing into CI/CD, and what procurement teams should expect from vendors.

Table of Contents

• What WCAG 2.1 AA Actually Requires: The Four Principles
• Keyboard Navigation and Focus Management
• Screen Readers, ARIA, and Semantic HTML
• Color Contrast and Visual Design Constraints
• Captions and Time-Based Media
• Why Accessibility Overlays and Widgets Fall Short
• Building Accessibility Testing into CI/CD
• Section 508, VPATs, and Procurement Realities

Key Takeaways

• WCAG 2.1 AA compliance is now a legal requirement for public school districts under the DOJ's 2024 Title II rule, and that obligation flows down to any EdTech vendor whose product a district deploys.
• Accessibility overlays and widgets typically address only a narrow slice of WCAG success criteria and commonly introduce new keyboard and screen reader problems; they are not a substitute for accessible engineering at the component level.
• A defensible accessibility program combines automated testing (tools like axe-core in CI) with mandatory manual and assistive-technology testing, since automated scanners typically catch only a minority of real-world WCAG failure types.
• Districts are increasingly requiring a current VPAT during procurement, and vendors without an accurate one are commonly excluded from RFP consideration before technical evaluation even begins.

What WCAG 2.1 AA Actually Requires: The Four Principles

WCAG 2.1 is organized around four principles, commonly abbreviated POUR: Perceivable, Operable, Understandable, and Robust. Each principle contains guidelines, and each guideline contains testable success criteria rated A, AA, or AAA. Level AA is the bar set by the DOJ rule and is also the de facto standard referenced by Section 508 and most state procurement policies, so engineering to AA is the practical target regardless of which specific regulation applies to a given deployment.

Perceivable covers text alternatives, captions, and color contrast. Operable covers keyboard access, timing, and navigation. Understandable covers predictable behavior, readable content, and clear error messages. Robust means content works reliably across browsers and assistive technologies — in practice, valid semantic markup that doesn't depend on a specific screen reader quirk. What makes 2.1 meaningfully harder than 2.0 for EdTech is the added criteria around reflow and orientation, which matter directly for the tablets and Chromebooks dominating K-12 device fleets — a gradebook that only works in landscape orientation fails 2.1 AA even if it passed 2.0.

Keyboard Navigation and Focus Management

Keyboard operability is where EdTech products fail audits most often, and it's also the cheapest category of defect to prevent if it's designed in from the start. Every interactive element — buttons, dropdowns, modals, drag-and-drop exercises common in interactive courseware — must be reachable and operable with a keyboard alone, in a logical order matching the visual layout.

Custom components built from divs and spans styled to look like buttons or checkboxes typically don't receive keyboard focus or fire on Enter/Space unless a developer explicitly wires up tabindex, key handlers, and roles. Modals need to trap focus while open and return it sensibly on close, and drag-and-drop interactions common in matching exercises and assessments need an equivalent keyboard path, commonly a select-and-move pattern rather than a physical drag gesture. Skip links that let a keyboard or screen reader user bypass repetitive navigation are a small addition with an outsized benefit for daily assistive-technology users. A useful discipline is requiring every new interactive component to pass a keyboard-only smoke test before merge — unplug the mouse, complete the primary flow, confirm the focus indicator stays visible at each step — which catches a large share of Operable-principle defects well before a formal audit would.

Screen Readers, ARIA, and Semantic HTML

The first rule of ARIA is not to use it when native HTML already does the job: a native <button> is keyboard-operable, focusable, and announced correctly by screen readers with zero extra work, while a styled div pretending to be a button requires the developer to reconstruct all of that manually and correctly.

Where custom components are unavoidable — data grids, date pickers, tabbed courseware navigation — ARIA roles and states need to accurately reflect what the component is doing. A common, costly pattern is ARIA that's present but wrong: an aria-expanded attribute that never updates, or an aria-label that duplicates visible text in a way that becomes confusing when read aloud. Form fields need programmatically associated labels rather than placeholder text alone, and validation errors need to be announced via an ARIA live region at the moment they occur, not just as a visual color change. This matters most in assessment and gradebook interfaces, where a student using a screen reader needs to know unambiguously which question they're answering and whether an answer was submitted — information a sighted student gets for free from layout that a non-visual user needs conveyed through correct semantics.

Color Contrast and Visual Design Constraints

WCAG 2.1 AA sets minimum contrast ratios between text and background — commonly cited as 4.5:1 for normal text and 3:1 for large text — and separately requires that color not be the only means of conveying information. This second requirement is the one design teams miss most often: a red border marking a required field or an incorrect answer, with no accompanying icon or text, fails for users with color vision deficiency even when the contrast ratio itself is compliant.

In EdTech this shows up in places design systems don't always anticipate: progress charts in student dashboards relying purely on color-coded legends, status indicators in teacher rosters (submitted, late, missing) shown only as colored dots, and correct/incorrect feedback in adaptive learning tools shown only through green or red highlighting. The fix — pairing color with an icon, pattern, or label — is straightforward, but it needs to be enforced as a component-library rule, not a per-feature decision, or it will regress with every new feature.

Captions and Time-Based Media

Video and audio are common across EdTech, from recorded lectures to explainer content embedded in courseware. WCAG 2.1 AA requires accurate synchronized captions for prerecorded video with audio, plus audio description or a text alternative for content that conveys meaning visually without corresponding narration. Live video, increasingly common in synchronous instruction, has caption requirements too.

Auto-generated captions from a video platform are typically a reasonable starting point but commonly require human review before they meet the accuracy bar WCAG expects, particularly for subject-specific vocabulary and multiple speakers. Engineering teams building or integrating video functionality should treat caption generation and storage as a required step in the content pipeline, and should validate at ingestion time that a caption track exists before content is allowed to publish.

Why Accessibility Overlays and Widgets Fall Short

Accessibility overlay widgets — third-party scripts that add a floating icon promising to fix compliance by adjusting font size, contrast, and spacing on top of existing markup — have become widely and specifically criticized by accessibility experts and disability advocacy organizations, and increasingly cited by plaintiffs' attorneys as evidence of superficial compliance rather than a defense against it.

The technical problem is straightforward: an overlay operates on top of the DOM after the page has already rendered and typically cannot fix defects in the underlying markup and component behavior — a div masquerading as a button, missing form labels, broken focus order, ARIA states that never update. In some documented cases, overlay scripts have interfered with a user's own assistive technology, overriding settings a screen reader or magnifier user already configured, making the experience worse for the population the tool claims to serve. An overlay can adjust text size and contrast, but it cannot make a custom dropdown keyboard-operable or associate a data table's headers with its cells, and vendors that lean on one as their entire strategy typically cannot produce a VPAT that withstands scrutiny. The durable fix is accessible engineering at the source — semantic HTML, correct ARIA where necessary, keyboard support, color-independent status indicators — treated as a standard part of the definition of done, not a layer bolted on afterward.

Building Accessibility Testing into CI/CD

Accessibility testing that happens only right before a release, or only after a complaint, is too late to be cost-effective. The reliable pattern is layered: automated scanning on every pull request, combined with scheduled manual and assistive-technology testing that automated tools cannot replace.

Tools like axe-core (via jest-axe for unit tests, Cypress or Playwright plugins for end-to-end flows, and Lighthouse for periodic full-page audits) can be wired into CI to fail a build when new violations appear, and they're genuinely good at catching missing alt text, insufficient contrast, missing form labels, and invalid ARIA values. What they typically can't evaluate is whether an experience actually makes sense to a real assistive-technology user — whether reading order is logical or a keyboard flow is merely technically possible versus actually usable. Automated coverage commonly catches only a minority of the WCAG criteria that matter in practice, which is why a credible program also budgets for manual testing as a non-negotiable part of the release process: keyboard-only walkthroughs of critical flows, testing with actual screen readers (VoiceOver and NVDA are common baseline choices), and periodic testing with real assistive-technology users where feasible. Embedding accessibility acceptance criteria into tickets and gating major releases on a manual test pass is what separates teams that pass audits from teams that ran a scanner once and called it done.

Section 508, VPATs, and Procurement Realities

Section 508 of the Rehabilitation Act requires federal agencies, and by extension programs purchased with certain federal funding, to procure accessible technology. Its technical standards were harmonized with WCAG some years ago and have continued to track it as the referenced baseline, so engineering to WCAG 2.1 AA satisfies the substance of both the DOJ's Title II rule and Section 508 — there isn't a meaningfully different technical bar for one versus the other, just different enforcement mechanisms and different purchasers asking for proof.

That proof, in procurement terms, is increasingly a VPAT — a Voluntary Product Accessibility Template documenting, criterion by criterion, how a product conforms to WCAG (and, where relevant, Section 508 and EN 301 549 for vendors selling internationally). A VPAT is only as credible as the testing behind it: one populated from a quick automated scan and marketing optimism tends to fall apart under district or state-level scrutiny. Engineering teams should treat VPAT accuracy as a shared responsibility with product and legal, and re-verify it whenever a significant UI change ships rather than only at initial launch. An accurate, current VPAT has become a genuine competitive differentiator in RFP responses, and its absence, or an obviously inaccurate one, is increasingly disqualifying before evaluators even look at feature functionality.

Getting accessibility right in EdTech is inseparable from getting the rest of the architecture right — it touches the same component libraries, integration surfaces, and data flows covered in our related articles on LMS integration architecture for higher education and student data privacy under FERPA, COPPA, and state EdTech laws. If your team is evaluating what WCAG 2.1 AA conformance requires for your product, preparing a VPAT for an upcoming district RFP, or building an accessibility testing pipeline from scratch, get in touch with Halkwinds to talk through your specific architecture and timeline.

Frequently Asked Questions

Does the DOJ's Title II rule apply directly to our EdTech company, or only to the school district?

The legal obligation technically attaches to the public entity — the district, public university, or state agency — not directly to a private vendor. In practice, though, a district can't satisfy its own compliance obligation by deploying an inaccessible vendor product, so districts are pushing WCAG 2.1 AA requirements and VPAT requests into contracts and RFPs. For a vendor selling into K-12 or public higher education, the practical effect is the same as if the rule applied directly.

Is Level AA actually enough, or should we build to AAA to be safe?

WCAG 2.1 AA is the level referenced by the Title II rule, by Section 508, and by essentially every state procurement policy we've encountered, so it's the correct engineering target. AAA includes some criteria that are genuinely impractical to satisfy for certain content types, and full AAA conformance is not typically expected in EdTech procurement. It's reasonable to adopt individual AAA criteria where they're low-cost and clearly beneficial, without committing to full AAA as a program goal.

Can we just buy an accessibility overlay to get compliant quickly before an audit?

An overlay can improve a few cosmetic properties, but it doesn't fix the underlying markup, keyboard behavior, or ARIA semantics that most WCAG success criteria actually test, and it won't produce a VPAT that survives scrutiny. Publicized litigation and advocacy criticism of overlay-only strategies has made procurement and legal teams specifically wary of vendors that rely on one, making it a reputational risk on top of a technical one.

What's the minimum viable accessibility testing setup for a small EdTech team?

Start with axe-core wired into your existing test suite (jest-axe for component tests, a Playwright or Cypress plugin for key end-to-end flows) so obvious violations fail CI automatically. Pair that with a lightweight manual checklist — a keyboard-only pass and one screen reader pass (VoiceOver on Mac or NVDA on Windows, both free) — run against critical flows before each release. That combination is commonly sufficient to catch the large majority of practical defects for a team not yet ready to invest in dedicated accessibility QA.

How often does a VPAT need to be updated?

There's no single mandated cadence across every purchaser, but the practical expectation from districts and state procurement offices is that a VPAT reflects the current product, not a snapshot from a major version ago. Any release that meaningfully changes UI components or introduces new interactive features is a reasonable trigger to re-test and update it, and many vendors re-verify at least annually so the document doesn't go stale during a multi-year contract.