Education Website Accessibility: A Practical Guide for Schools and Universities

Education platforms accumulate accessibility debt faster than almost any other sector. Content comes from hundreds of authors (faculty, administrators, librarians, students), is published continuously, and lives across a public site, a CMS, and an LMS like Moodle, Canvas, or Blackboard. A single course can mix HTML pages, embedded video, downloadable slides, and third-party tools.

The baseline standard is WCAG 2.2 Level A and AA. Most failures cluster in a handful of predictable areas: low-contrast text on branded color schemes, images without alt text, forms and quizzes that break under keyboard navigation, and video with no captions. WCAG 2.2 added criteria that hit education hard, including 2.5.8 Target Size (Minimum), which requires interactive targets of at least 24 by 24 CSS pixels (a common problem in dense course navigation), and 2.4.11 Focus Not Obscured (Minimum), which sticky headers and chat widgets frequently violate.

Documents are the single biggest source of inaccessible content in education. A PDF created by scanning a printed page is just an image: a screen reader finds no text, no headings, and no reading order. Even "born-digital" PDFs exported from Word often lose their tag structure.

To make course documents usable:

• Use real heading styles (Heading 1, Heading 2) instead of just enlarging bold text, so screen readers can build a navigable outline.
• Add alt text to charts, diagrams, and figures; mark purely decorative images as decorative.
• Export to tagged PDF and confirm the tag tree and reading order, rather than trusting the default export.
• Provide an accessible HTML alternative for complex material like lab manuals or math-heavy content, which is often easier than fixing the PDF.
• Set the document language and a meaningful title so assistive tech announces it correctly.

When you onboard faculty, give them a one-page authoring checklist so accessible documents become the default, not a remediation project after the fact.

Recorded lectures, orientation videos, and promotional clips all need captions. WCAG 1.2.2 (Captions, Prerecorded) is a Level A requirement, meaning it is non-negotiable, not a nice-to-have. Auto-generated captions from your video platform are a reasonable first draft, but uncorrected machine captions routinely mangle discipline-specific vocabulary, proper nouns, and equations, which makes them legally and pedagogically insufficient on their own.

Practical targets for a video accessibility program: accurate synchronized captions on all prerecorded video with audio, a transcript for audio-only content like podcasts (1.2.1, Level A), and live captions for synchronous classes where feasible (1.2.4, Level AA). Where a video conveys essential information visually without narration (a silent demonstration, an on-screen-only diagram), you also need audio description or an equivalent text alternative.

The LMS is where accessibility gets hardest because it is interactive. A multiple-choice quiz, a drag-and-drop matching exercise, or a discussion forum must be fully operable without a mouse. WCAG 2.2's 2.5.7 Dragging Movements (Level AA) requires that any drag-based interaction (sorting answers, building a timeline) offer a single-pointer alternative such as click-to-place.

Key checks for LMS-delivered content: every interactive element reachable and operable by keyboard with a visible focus indicator; custom widgets that expose correct names, roles, and states; data tables (grade books, schedules) with proper header associations; and color never used as the only way to convey meaning, such as marking a wrong answer in red alone. Verify these the way a student using assistive tech would, with real screen-reader testing rather than visual inspection alone.

Remember that procuring a platform that claims conformance does not transfer your obligation. Vendor accessibility statements describe the empty shell; the moment your staff upload an untagged PDF or an uncaptioned video, the responsibility is yours.

The legal landscape is more aligned than it looks. In the EU, public-sector schools and universities fall under the Web Accessibility Directive (2016/2102), which is implemented through the harmonized standard EN 301 549. Private education providers and certain digital products and services can fall under the European Accessibility Act (Directive (EU) 2019/882), whose requirements apply from 28 June 2025. In practice both routes point to EN 301 549 and a WCAG 2.2 Level A and AA target, so the technical goal is the same.

In the US, the ADA does not name a specific WCAG version, but WCAG 2.1/2.2 Level AA is the standard used in settlements and Department of Justice guidance, and the 2024 Title II rule directs public entities (including public colleges and schools) toward WCAG 2.1 AA. Institutions subject to Section 508 work against WCAG 2.0 AA. The pragmatic conclusion: build to WCAG 2.2 AA and you satisfy the strictest requirement across all of these frameworks at once.

Both regimes also expect a published accessibility statement describing your conformance status, known issues, and a contact route for problems. You can produce one with the accessibility statement generator and keep it current as you remediate.

Trying to fix everything at once stalls. Sequence it: start with the highest-traffic pages and the courses with the most enrolled students, fix documents and captions in active courses first, and bake accessible authoring into your content templates so the backlog stops growing.

Begin with a baseline measurement. Run a free automated scan with AccessScan to surface machine-detectable issues like contrast failures and missing alt text across your public pages, then layer in manual keyboard and screen-reader checks for everything automation cannot see. Pair contrast fixes with the contrast checker so brand colors meet the 4.5:1 ratio for normal text and 3:1 for large text (at least 18pt, or 14pt bold) and UI components before they ship.