Accessibility compliance for schools, colleges, and edtech
Public schools and universities are now on an ADA Title II clock, and edtech vendors inherit the pressure. Here is what actually applies to education and where source-code scanning fits.
A university web team emailed us in the spring with a problem I hear a lot in education now. Their public-facing site was in decent shape. The nightmare was everything behind the login: the course registration portal, the housing application, the financial aid dashboard, the three internally built React apps nobody on the current team wrote. An Office for Civil Rights complaint had landed about one page in the registration flow, and legal wanted to know how many other pages had the same problem. Nobody could answer, because nobody had ever scanned the code.
That gap — public site fine, the actual software students use every day untested — is the story of accessibility in education right now. And the regulatory calendar just made it urgent.
Why education got a hard deadline
In April 2024 the U.S. Department of Justice published a final rule under Title II of the Americans with Disabilities Act that, for the first time, sets a specific technical standard and a specific date for the web content and mobile apps of state and local governments. Public schools, community colleges, and public universities are state and local government entities. This rule is aimed squarely at them.
The standard the rule adopts is WCAG 2.1 Level AA. The compliance dates are tied to population: entities in jurisdictions of 50,000 or more people had to comply by April 24, 2026, and smaller entities plus special district governments have until April 24, 2027. If you run technology for a large public university system, that first date is already behind you. If you are a small district or a rural college, you have one more budget cycle, not several.
Two things trip people up here. First, "web content" in the rule is broad. It covers the sites students see, but also the web applications, PDFs, and mobile apps an institution provides or contracts for. Your learning management system, your registration portal, your building-access app — all in scope. Second, the rule adopts WCAG 2.1 as the legal floor. WCAG 2.2 is the current version and adds success criteria that 2.1 does not have, several of which matter enormously for the kind of complex, form-heavy software schools run. Building to 2.2 is the sensible target even when the regulation names 2.1, because you get the newer criteria for free and you are not rewriting to the same standard in two years.
The other laws already in the room
Title II is the loud new arrival, but education has lived under accessibility obligations for a long time, and they stack.
Section 504 of the Rehabilitation Act applies to any program that receives federal financial assistance, which is nearly every public school and most colleges. Section 508 sets accessibility requirements for federal agencies and flows down to institutions through federal contracts and grants. The U.S. Department of Education's Office for Civil Rights has been resolving complaints about inaccessible campus websites, library databases, and course materials for years — you can read the resolution agreements OCR publishes to see the pattern, and I would recommend anyone in edtech procurement actually read a few before signing a vendor. If you sell education software into Europe, the European Accessibility Act enforcement deadline passed on June 28, 2025, and it reaches consumer-facing digital products regardless of where your company is headquartered.
None of this is hypothetical anymore. The distinction that used to save institutions — "our public brochure site is compliant" — does not survive contact with a rule that explicitly covers the applications students are required to use to enroll, learn, and graduate.
Edtech vendors inherit all of it
If you build software that schools buy, everything above is now your sales problem whether or not you intended it to be. Procurement teams at universities are increasingly required to document that the tools they license meet a technical accessibility standard before a contract is signed. That documentation request is showing up in RFPs as a hard gate, not a nice-to-have.
The near-universal form of that request is a VPAT — a Voluntary Product Accessibility Template, which produces a document called an Accessibility Conformance Report describing how your product measures against WCAG. I want to be straight about this: inklu does not generate VPATs or ACRs today. That is on our roadmap, not in the product. What inklu does produce today are WCAG 2.2 violation reports and compliance-formatted reports for AODA, ADA Title II, and the EAA, which are the evidence you build a VPAT on top of. If a school's procurement team is asking how you evaluate vendors, our guide to how procurement evaluates accessibility vendors is a useful thing to hand them.
Where the violations actually hide in education software
Having scanned a fair amount of institutional and edtech code, the failures cluster in predictable places, and almost all of them are in the parts you cannot see from the marketing homepage.
Forms are the first. Registration, financial aid, admissions, housing — education runs on long multi-step forms, and they are consistently the worst-tested surface. Inputs without associated labels, error messages that are announced to sighted users through color alone, required-field indicators that a screen reader never hears. We wrote up the form patterns that fail in React because it is the single most common cluster we open pull requests against.
Data tables are second. Grade books, course catalogs, schedule grids, transcript views. These are frequently built as generic <div> grids with no table semantics, no header associations, no way for assistive technology to tell a student which cell belongs to which course. Keyboard access is third: date pickers you cannot operate without a mouse, custom dropdowns that trap focus, modal dialogs that let focus escape to the page behind them. And color contrast runs through all of it, because education design systems tend to lean on a single institutional brand color that was chosen by a marketing committee, not a contrast checker.
The common thread is that these live in application code — the JSX, the CSS, the components your team owns — not in a CMS someone can fix by editing a page. That is exactly the surface a source-code scanner is built for.
Where a scanner helps, and where it does not
I will be honest about the boundary, because education has a specific shape that makes it matter.
inklu scans web apps and codebases against WCAG 2.2 using axe-core plus a layer of our own rules, and it opens GitHub pull requests with AI-generated fixes for what it finds. It supports HTML, CSS, JSX including TSX, and SCSS. A web scan costs 2 tokens, a repository scan costs 8, and each auto-fix pull request costs 1 — the full breakdown is on the pricing page. For the internally built portals and applications a school or edtech company owns the code to, this closes the loop from detection to a reviewable fix without a human hand-writing every correction.
What it does not do is remediate the things education has a lot of that are not application code. Scanned PDFs of syllabi and lecture notes are their own remediation problem and inklu does not fix them. Third-party courseware you license but do not own the source to is outside what a source-code scanner can touch — that is a procurement conversation, which is why the VPAT gate matters. Video captioning and audio description are separate workflows. A scanner is the right tool for the software your engineers write, and being clear about that boundary is more useful than pretending one tool solves an entire institution's obligations.
Two more things worth knowing given how sensitive student data is. inklu runs in the US East region only, and it purges source code after each scan — nothing is retained. For a team that has to think about FERPA-adjacent data handling before letting any tool near a repository, ephemeral scanning is a genuinely relevant property, though it is not a substitute for your own data-handling review.
A practical order of operations
If you are staring at this from inside a school or an edtech company, the sequence that works is boring and effective. Inventory the applications students and staff actually log into, not just the public site — that list is usually longer than anyone expects. Scan the ones you own the code for, and triage by where the required workflows are: enrollment, payment, and coursework first, because those are the flows a student cannot opt out of and the ones OCR complaints tend to name. Fix the application code you control, wire a scan into your CI so new violations do not silently reappear — the mechanics are in our CI/CD writeup — and for everything you license rather than build, get the vendor's conformance documentation in writing before renewal.
The deadline that already passed for large public institutions is not the end of anything. Accessibility obligations in education do not have a finish line; they have a maintenance cost, and the schools that treat it as an ongoing engineering practice rather than a one-time audit are the ones that stop getting complaints.
If you run technology for a school or build software that schools buy and want to see what a scan turns up in the applications behind your login, book a demo at inklu.io, or email us at hello@inklu.io.