A university admissions portal, a K-12 school’s parent communication site, and a corporate e-learning platform for onboarding new hires all face the same underlying question: does the site meet the legal and technical bar required when minors, students, or employees hand over personal data to learn something. Compliance for educational websites and online learning platforms sits at the intersection of privacy law, accessibility regulation, and plain operational hygiene, and getting it wrong tends to surface at the worst possible time – during an audit, a parent complaint, or a procurement review by a school district’s legal counsel.
This isn’t a niche concern anymore. Online learning traffic grew sharply after 2020 and never fully receded – Coursera reported over 148 million registered users by the end of 2023, and thousands of smaller LMS deployments (Moodle, Canvas, TalentLMS) run inside school districts and companies with far less legal support than a platform of that size.
What makes education sites legally different
Most compliance guidance assumes a general commercial audience. Education breaks that assumption in three specific ways.
First, a meaningful share of users are minors. In the US, the Children’s Online Privacy Protection Act (COPPA) applies once a site “knowingly” collects personal information from children under 13 – and FERPA (Family Educational Rights and Privacy Act) governs how student education records are shared, even by third-party edtech vendors acting on a school’s behalf. In the EU, GDPR sets the age of consent for information society services at 16 by default, though member states can lower it to 13 (Ireland and the UK use 13, Germany uses 16).
Second, accountability is layered. A school district signs a contract with an LMS vendor, but the district remains responsible to parents and regulators for what that vendor does with student data. This is why data processing agreements matter more here than in a typical B2C context – see Data Processing Agreements – When Your Site Needs Them for what such an agreement needs to actually cover, not just reference in a footer link.
Third, accessibility obligations are often stricter and better enforced. Title II of the ADA, as updated by the Department of Justice’s April 2024 rule, requires state and local government entities – including public schools and universities – to meet WCAG 2.1 Level AA by April 24, 2026 for larger districts and April 24, 2027 for those under 50,000 residents. That deadline is closer than most district IT teams realize.
Common mistakes practitioners actually make
A GRC lead auditing an edtech platform tends to find the same three issues repeatedly. Cookie consent banners that look compliant but don’t actually block tracking scripts until consent is given – the banner renders correctly, but Google Analytics or a chat widget fires on page load regardless of the user’s choice. Visual inspection misses this every time; it requires checking network requests before consent is granted, which is exactly the gap covered in Cookie Consent Monitoring: Beyond Visual Verification.
Second mistake: treating accessibility as a one-time remediation project rather than an ongoing state. A district pays for a WCAG audit in January, fixes the flagged issues, and then a marketing team pushes a new PDF-heavy newsletter template in September that reintroduces contrast failures and missing alt text. Accessibility compliance is a moving target tied to every content update, not a certificate you earn once.
Third: assuming a vendor’s SOC 2 report substitutes for a data processing agreement covering student records specifically. SOC 2 speaks to security controls; it says nothing about whether the vendor can use student data to train models, sell aggregated analytics, or retain records after a contract ends. Those terms need to be in the DPA itself.
A practical starting checklist
An experienced compliance officer working through a new edtech deployment typically walks through this sequence before launch:
1. Confirm the age range of users and map which law applies – COPPA for under-13 US users, FERPA for any US student education record, GDPR/UK GDPR for EU/UK minors, with age-of-consent thresholds checked per country.
2. Verify the privacy policy names every third-party subprocessor that touches student data, not just a generic “we may share data with partners” clause.
3. Test the cookie consent mechanism technically – confirm no tracking cookie fires before opt-in, across desktop and mobile.
4. Run an automated accessibility scan (axe-core, WAVE) plus manual keyboard navigation testing on the enrollment and assessment flows specifically, since those are the pages students can’t avoid.
5. Get a signed DPA from every vendor with contractual language on data deletion timelines after a student leaves or a course ends.
The myth worth retiring
A persistent misconception is that COPPA and FERPA obligations disappear once a platform serves adult learners – corporate training, university continuing education, professional certification. That’s only true if the platform genuinely has no users under 18. Many “adult” platforms have dual-use traffic: a high school dual-enrollment program running through a university’s LMS, or a coding bootcamp with a 17-year-old enrolled alongside adults. One verified minor account is enough to trigger COPPA’s knowledge standard, and ignorance of that user’s age is not a reliable defense once a complaint is filed.
Monitoring beyond the initial audit
Education platforms change constantly – new course content, new integrations (Zoom, Stripe for tuition payments, a proctoring tool like Proctorio), semester-driven redesigns. Each change can silently break a compliance control that passed review months earlier. A TLS certificate that expires mid-semester, a security header removed during a CDN migration, or a consumer rights notice that vanishes after a template update are exactly the kind of gaps Accessibility Compliance: More Than Just a Checkbox discusses in terms of ongoing verification rather than point-in-time certification.
Frequently asked questions
Does a small private tutoring website need to worry about FERPA?
FERPA applies to schools and agencies that receive federal funding, not directly to private vendors – but if that tutoring service contracts with a public school district, FERPA obligations typically flow through via the district’s contract terms, making the vendor a “school official” bound by the same restrictions.
Is WCAG 2.1 AA legally required for a private university’s website?
Private institutions that receive federal funding (most do, through student financial aid programs) fall under Section 504 of the Rehabilitation Act, which courts have increasingly interpreted alongside WCAG 2.1 AA as the practical standard, even though Section 504 itself doesn’t name WCAG explicitly.
How long should student data be retained after a course ends?
There’s no single legal number – it depends on the applicable law and contract terms, but a defensible default is to define a specific retention period (commonly 1–3 years after last activity) in the DPA and enforce automatic deletion rather than retaining data indefinitely by default.
Educational platforms carry a compounded compliance burden that general commercial sites don’t – minors, layered accountability between institution and vendor, and accessibility deadlines with real enforcement dates attached. Treating each of privacy, cookies, security headers, and accessibility as a static checklist item rather than a continuously monitored state is where most gaps quietly form between one semester and the next.