Accessibility with a deadline: ADA Title II and interactive content

This describes a published federal rule and how it shapes product decisions. It isn't legal advice.

Accessibility in US K-12 was always a legal obligation. What changed is that it now has dates on it, and districts have started asking a question they used to skip.

The rule and the dates

The Department of Justice published a final rule under Title II of the Americans with Disabilities Act in April 2024, setting a technical standard for the web content and mobile applications of state and local government entities. That includes public school districts.

The standard is WCAG 2.1 Level AA. The compliance dates are 24 April 2026 for public entities with a total population of 50,000 or more, and 26 April 2027 for smaller entities and special district governments, which is where a great many school districts sit.

Two clarifications that matter for vendors.

The obligation is the district's, not yours. But a district can't meet it using inaccessible software, so it arrives at your door as a procurement requirement, alongside everything in passing a district security review, and increasingly as a contract term with remediation obligations attached.

Section 508 gets named in the same breath and is a slightly different thing. It binds federal agencies and federal procurement directly. Districts aren't federal agencies. But many states have adopted equivalent requirements, and 508 is the vocabulary everyone's paperwork uses, so you'll be asked about it regardless. Answer against both.

WCAG 2.2 AA is the current W3C recommendation and is what to build to. The rule names 2.1 as the floor. Building to 2.2 costs little more and ages better.

The VPAT, and why honesty outperforms

The artefact a district asks for is a VPAT, completed, which makes it an Accessibility Conformance Report. It comes in editions: WCAG, Revised Section 508, EN 301 549, and a combined international one. For US K-12, provide the WCAG and Revised 508 editions.

Each criterion gets one of: Supports, Partially Supports, Does Not Support, Not Applicable, Not Evaluated.

Here's the thing that runs against instinct. A report saying Supports on every line reads as a vendor who didn't test.

Reviewers who do this for a living have never seen a complex interactive product that fully supports every criterion. A clean report signals one of two things, and neither is that your product is perfect. An honest report with several Partially Supports, each with a specific note about what fails and for whom, and a dated remediation plan, is more persuasive. It's the only kind they've ever seen turn out to be true.

Write it from actual testing. Say who tested, with what assistive technology, in what version, on what date. An ACR without a methodology statement is an opinion.

The part that's genuinely hard

Standard interface accessibility is well-trodden. Semantic markup, focus management, contrast, labels, error messaging. Do it properly and move on.

The expensive part in educational software is the interactive content itself, the thing your product exists for. A simulation with live readouts. A drag-and-drop construction. A grapher with a slider. A number line a student places a point on. These have no established pattern and can't be solved by picking a better component library.

Four requirements, using a slider that changes a graph as the example.

A keyboard path. Tab to the control, arrows to change the value, and a documented larger step, because moving a range of 0 to 100 in single steps isn't a usable interaction. Every state the mouse can reach, the keyboard must reach.

An announced state. When the value changes, a screen reader user needs to know what changed and what happened as a result. That's a live region with text carrying meaning. Not "value 42" but "amplitude 42, wavelength unchanged, peak height doubled". Throttle it so dragging doesn't produce a hundred announcements.

A non-visual equivalent of the output. A graph is an image to a screen reader. alt="chart" isn't an alternative, it's an admission. What carries the same information is a structured alternative: a data table of the plotted values, or a text summary describing shape, direction, extrema and intercepts. For an exploratory tool, a table that updates with the control is usually the right answer and isn't difficult.

A second channel for anything colour encodes. If the red line is velocity and the blue line is acceleration, they also need shape, pattern or direct labels.

Mathematics deserves its own paragraph

If your product renders equations, the failure here is total. A screen reader either reads the mathematics or says nothing at all.

The mechanism is MathML. KaTeX emits MathML alongside its visual output by default, and MathJax can be configured to provide assistive MathML, so if you use either at their defaults you're likely in reasonable shape.

The failures come from elsewhere: mathematics rendered to canvas, mathematics shipped as images, LaTeX never rendered to MathML at all, or an output mode configured to visual-only for performance.

Test it. Turn on a screen reader, navigate to an equation, listen. Ten minutes, and it's the only way to know.

Braille is the adjacent concern. Students using refreshable braille displays meet mathematics in Nemeth or UEB, and getting there generally goes through MathML, which is another reason to make sure it exists.

Accommodations already exist, and are legally owed

This is the piece most product teams miss entirely.

A student with an IEP under IDEA, or a 504 plan under the Rehabilitation Act, has documented accommodations. Extended time. Text read aloud. A calculator. A masked or simplified screen. Directions in another language. Answers given by a different mode.

These aren't preferences, and they aren't settings a teacher should re-enter per activity. They're legally owed to the child, and districts increasingly state in RFPs that your product should honour them consistently.

What to build: an accommodation profile on the user, set once by an administrator or teacher, applied everywhere. Extended time affects every timed activity. Read-aloud is available on every text surface. Calculator permission persists across every item that respects it.

Note that accommodations generally live in a special education system, not in the roster feed, so you usually won't receive them automatically. The realistic design is district-configurable per student, with the profile as the single point of truth inside your product.

The assistive technology to actually test with

Test against what students use, which isn't what your team has installed.

• ChromeVox, built into ChromeOS. The most likely screen reader a US K-12 student encounters, and frequently untested by vendors.
• NVDA with Firefox and Chrome on Windows.
• JAWS with Chrome on Windows, still standard in many districts.
• VoiceOver on macOS and iPadOS.
• Read&Write, Snap&Read, Kurzweil. Text-to-speech and reading support tools deployed at scale by districts, which interact with your DOM in ways a screen reader doesn't.

That last category catches people. A reading support extension that highlights and speaks text behaves badly against text rendered in canvas, against aggressively virtualised lists, and against content that re-renders while it's being read.

Where to start if you're behind

In order of return:

1. Keyboard-complete your primary interaction. The one component your product is built around. Everything else is downstream.
2. Check mathematics reads. Ten minutes, potentially total.
3. Give every visualisation a real text alternative. A data table is acceptable and often better than prose.
4. Build the accommodation profile. Asked about in procurement, and not large.
5. Test with ChromeVox on a Chromebook, because that's the actual deployment.
6. Write an honest ACR with dates against what isn't fixed.

The last one unlocks the purchase. Districts don't require perfection. They require a credible, evidenced plan, because they're working towards a deadline themselves and need to show progress.