WCAG 2.1 AA for your LMS: what the ADA Title II deadline actually requires

If you've landed here, something made accessibility urgent — a deadline, an OCR complaint, a procurement questionnaire, or a student's request. The good news is that the requirement is knowable and the work is doable. The trap is thinking a color-contrast fix, an automated scan, or an accessibility "overlay" gets you there. It doesn't, and this guide explains what actually does — every regulatory and statistical claim tied to its primary source, the same way we wrote the FERPA and HIPAA guides.

Three things people confuse: WCAG, Section 508, and ADA Title II

Almost every accessibility mistake we see starts by mixing these three up. They are not the same, and they point at different versions of the standard.

• WCAG is the W3C technical standard — the actual checklist. It has versions: 2.0 (2008), 2.1 (2018), and 2.2 (2023). It is a standard, not a law.
• Section 508 is federal law for federal agencies' technology and their contractors. Its Revised Standards reference WCAG 2.0 Level AA (effective January 18, 2018).
• ADA Title II is civil-rights law for state and local government — including public schools, community colleges, and public universities. Its 2024 web rule references WCAG 2.1 Level AA, with the 2027 and 2028 deadlines below.

WCAG 2.2 is the newest W3C Recommendation and a sound future-proofing target — conforming to 2.2 also satisfies 2.1 and 2.0 — but no current U.S. regime legally mandates it. (2.2 isn't simply "2.1 plus nine"; it adds nine criteria and formally retired one, so treat it as a distinct version, not an increment.)

Are you covered, and by when?

The ADA Title II web rule (28 CFR Part 35) binds state and local governments and their agencies, special-purpose districts, and — named explicitly on ada.gov — public schools, community colleges, and public universities. A contractor delivering the service on the entity's behalf is bound too. There are two deadlines, keyed to the population the entity serves:

• April 26, 2027 — entities serving 50,000 or more people.
• April 26, 2028 — entities serving fewer than 50,000, and any special district government regardless of the population it serves.

Population is attributed by an entity-specific test, not a flat "always the state." Most entities use 2020 U.S. Census data; a smaller unit within a larger government uses the larger government's population; and independent school districts use the most recent Small Area Income and Poverty Estimates (SAIPE). Applying that test, a public university that is an instrumentality of the state generally lands in the 50,000+ tier — the April 26, 2027 deadline.

“It's behind a login” is not an exemption

This is the single most valuable correction for an LMS admin. The draft rule proposed an exception for password-protected course content that would only fall away once an institution was told a specific student needed accessible materials. DOJ dropped that exception from the final rule. Password-protected class and course content at public K–12, secondary, and postsecondary institutions must meet WCAG 2.1 AA like any other content — you can't wait for a disabled student to enroll before making the course usable.

The final rule (28 CFR 35.201) does have exactly five exceptions, and it's worth knowing them so you don't over-rely on the wrong one:

1. Archived web content meeting all the stated conditions.
2. Preexisting conventional electronic documents — unless they're currently used to apply for or access a service.
3. Third-party content the government didn't post.
4. Individualized, password-protected conventional documents about a specific person, property, or account.
5. Preexisting social-media posts.

The one people reach for is number four — but read it closely. It covers a file about a specific person (a student's own grade letter, a bill), not shared course materials. Your syllabus, lecture slides, quizzes, and SCORM modules are not named, and they are not exempt.

What conformance actually requires in a course

Level AA conformance means meeting every Level A and AA success criterion — 50 of them in WCAG 2.1 — not a curated subset. "We fixed contrast" is not conformance. Here are the criteria that most often break inside real courses, grouped by WCAG's four principles, with how each one fails in practice. (Percentages are home-page failure rates from the WebAIM Million, February 2026.)

Perceivable

1.1.1 Text Alternatives (A). Meaningful images need equivalent alt text; decorative ones are marked empty. It breaks with charts and diagrams that have no alt or "image1.png", alt that omits the trend a sighted student sees, scanned-image PDFs that are pictures of text, and Storyline images auto-added to the focus order with no label. Missing alt hit 53.1% of pages — and whether alt is accurate is human judgment a scanner can't make.

1.4.3 Contrast (Minimum) (AA) and 1.4.11 Non-text Contrast (AA). Body text needs a 4.5:1 ratio, large text (18pt, or 14pt bold) needs 3:1, and UI component boundaries and meaningful graphics need 3:1. It breaks with pale brand-palette body text, faint links, low-contrast green/red quiz feedback, and institutional-color buttons that miss 3:1. Low-contrast text is the number-one detectable failure at 83.9% of pages.

1.2.2 Captions (A) and 1.2.5 Audio Description (AA). Captions carry all speech plus meaningful non-speech audio, synchronized; audio description narrates on-screen information that isn't spoken (slide bullets, a diagram being pointed at, an on-screen URL). It breaks when you rely on YouTube auto-captions (a draft to correct, not a deliverable), lecture capture with no caption pass, or screencasts where the demo is only visible: "click here… now this."

1.3.1 Info & Relationships (A). Structure shown visually — headings, lists, tables, labels — must be encoded in the markup. This is the backbone criterion for course documents. It breaks with Word/PDF "headings" that are just big bold text (so heading-jump navigation is lost), tables built without header cells or scope, Storyline text boxes where bullets aren't real lists, and multi-column layouts that read out of order.

1.4.10 Reflow (AA) and 1.4.4 Resize Text (AA). Content must work at 400% zoom (or 320px wide) without two-directional scrolling, and text must scale to 200% without clipping. It breaks with fixed-width themes and tables, SCORM/Storyline packages published at a fixed pixel stage that won't reflow, non-reflowing PDFs, and text baked into images that pixelates when enlarged.

Operable

2.1.1 Keyboard (A) and 2.1.2 No Keyboard Trap (A). Every function must work by keyboard alone, and focus must always be able to Tab back out. It breaks with interactive packages — drag-and-drop, matching, sequencing, ranking, hotspot — that have historically lacked full keyboard access (a real gap, but version- and authoring-dependent, so verify per package), and with modals or custom widgets that trap focus. This is only testable by a human tabbing through.

2.4.7 Focus Visible (AA). A visible focus indicator must always show where the keyboard user is. It breaks with themes or CSS that use outline:none to "clean up" the design, and faint focus rings that vanish against a slide background.

2.4.4 Link Purpose in Context (A). Link text should make the destination clear. It breaks with pervasive "Click here / Read more / Download", bare URLs, and identical "Start" buttons. Empty links hit 46.3% of pages. The fix is plain: "Download the Week 3 lab rubric (PDF)."

2.4.2 Page Titled (A). Each page needs a descriptive title. It breaks when every course page is titled "Dashboard" or "Moodle", or documents export with a blank or filename title.

Understandable

3.1.1 Language of Page (A). The default human language must be set in code so the screen reader picks the right voice and pronunciation. Missing document language hit 13.5% of pages. (3.1.2 extends this to foreign-language passages — worth knowing for language courses.)

3.3.2 Labels or Instructions (A). Form fields need visible labels and instructions. It breaks with quiz, enrollment, and login fields that have placeholder-only or no programmatic label. Missing form labels hit 51% of pages.

Robust

4.1.2 Name, Role, Value (A). Every control — including custom widgets — must expose its name, role, and state. It breaks with custom dropdowns, sliders, star ratings, and accordions coded as unlabeled <div>s (the screen reader says nothing, or just "clickable"), and with Storyline results slides that show a tick or cross visually but tell a screen-reader user nothing — so the student never learns their score. Empty buttons hit 30.6% of pages.

4.1.3 Status Messages (AA, added in 2.1). Updates that don't move focus — "Draft saved", "question flagged", "5 minutes remaining", inline validation errors — must be announced through ARIA live regions. It breaks with silent auto-save toasts, silent timer warnings, and silent validation in quiz players and dashboards.

Why a passing scan doesn't mean an accessible course

Automated scanners are useful for triage and genuinely bad as a verdict. Two figures explain why, and they come from different places, so we keep them separate:

• By criteria: only roughly 20–30% of WCAG success criteria are meaningfully machine-testable. The conservative headline is that automated tools catch about 30% of the criteria.
• By issue volume: Deque's study of its own axe tooling (2,000+ audits, 13,000+ pages, ~300,000 issues) found automation fully covered about 57% of issues by volume — because the machine-detectable failures (contrast, missing alt, missing labels) are also the most numerous. That's a vendor study of one toolset, not a property of "scanners" in general.

W3C and WebAIM make the qualitative point plainly: tools "can not determine accessibility, they can only assist," and "the absence of detected errors does not indicate that a page is accessible." What a tool cannot verify is exactly what matters most: whether alt text is accurate, whether reading and focus order are logical, whether a keyboard widget actually works, whether captions are correct, and what a screen reader announces. That's the other ~70% of the criteria — and it's where course content lives.

Two traps specific to e-learning: content locked inside a SCORM or Storyline package can't be seen by standard page scanners at all, and passing the authoring tool's own built-in checker doesn't make it accessible — that checker misses keyboard operability, meaningful alt, and results-conveyance. And overlays or one-click "accessibility" widgets do not achieve conformance; issues have to be fixed at the source and re-verified. (Our free SCORM Inspector reads a package's structure in your browser, which is a useful start — but it's a structural check, not an assistive-technology test.)

Where Moodle helps — and where deployments still fail

Moodle is a strong starting point, and it's important to state its posture accurately. Moodle core targets WCAG 2.1 AA, and its current stated conformance target is WCAG 2.2 AA: Moodle reports that its core software was audited to WCAG 2.2 AA by a third party (GrackleDocs, accreditation dated October 3, 2025, covering Moodle LMS v5.1, v5.0.3, and v4.5.7), on a representative sample of pages per release — not the whole product, and never your content. (We cite moodledev.io for the current figure; the marketing site still shows older 2.1 AA dates.)

Here's the gap that decides everything: an audit of the core software does not make your deployment conformant. There is no official WCAG certification authority; this is a third-party consultant's attestation of a page sample. The real failures live in the parts a core audit never touches — uploaded PDFs, Word and PowerPoint files, SCORM and Storyline packages, video captions, images, math, quiz widgets, plus theme contrast and focus and any plugin UI.

Moodle does ship help, and it's worth using honestly. The free Brickfield Accessibility Starter Toolkit has been bundled in Moodle core since version 3.11 (May 2021). It's detection-only — a per-course error report and heatmap — while bulk, automated remediation is the paid edition. It flags a subset of machine-detectable issues in Moodle-native content, and it does not inspect uploaded PDFs, SCORM, or video, nor judge the screen-reader experience. Moodle also ships an in-editor accessibility helper, though which editor is the default and which checker is present depends on your release — so verify against your actual Moodle version rather than assuming. Theme-level contrast and focus work is theme development; name/role/value and ARIA fixes in Moodle-native and plugin UI are development and custom build work.

How we get you there: audit, test, fix at the source, re-verify

The work is a sequence, and the order matters — because the expensive, high-value findings are the ones automation can't reach.

• 1Automated triage. Run a scanner (axe, WAVE, Lighthouse, or the LMS checker) to catch the high-volume, machine-detectable failures fast and prioritize. Labeled as triage, never as a verdict.
• 2Manual and assistive-tech testing — where the other ~70% is found. A keyboard-only pass (reachable? no trap? focus visible? interactions operable?), a screen-reader pass with NVDA, JAWS, and VoiceOver (headings, labels, alt, tables, live regions announced correctly?), zoom and reflow at 400%, a caption and audio-description review, and a math-voicing check.
• 3Fix at the source, not with an overlay. Retag the PDF and add OCR, apply real heading styles in Word and PowerPoint, add labels and ARIA name/role/value in widgets, re-caption video and add audio description, re-author the Storyline interaction for keyboard, convert equations to MathML or MathJax.
• 4Re-verify and document. Re-scan and re-test with the same assistive technology, then document conformance in a VPAT/ACR your procurement and compliance officers can accept — scoped to a defined point in time.

The differentiator is that we work by content type, because each one breaks and gets fixed differently:

What you can hand to procurement

Compliance and procurement officers look for deliverables they recognize, and you'll leave an engagement with them: an accessibility audit report, a prioritized remediation plan, the remediated source files, and a VPAT/ACR (a conformance report) for the assessed scope, plus re-verification after the fixes land. One honest scope note to set expectations internally: a VPAT covers the product or scope assessed — not your whole catalog — and because courses change, your deployment needs assessment on an ongoing basis, not once.

This sits alongside the rest of the regulated-LMS cluster: FERPA and HIPAA for student and health data, and it's far cheaper to build accessibility in during an LMS migration than to retrofit it afterward.

Start with an accessibility audit of one course
Pick a representative course; we run the full triage, manual, and assistive-tech pass and hand back a plain findings report with a prioritized plan. We reply within one business day — or call (615) 396-7139.

Questions we get about LMS accessibility