Moodle Accessibility and ADA Title II Compliance in 2026

The US Department of Justice's ADA Title II web accessibility rule is a United States federal regulation for state and local government web content and mobile applications, including public education services covered by Title II. The 2024 rule adopted WCAG 2.1 Level AA as the technical standard, and the DOJ's April 2026 interim final rule extended the compliance dates. As of May 5, 2026, the dates are:

• April 26, 2027: public entities with a total population of 50,000 or more
• April 26, 2028: public entities with a total population under 50,000, and special district governments

If your Moodle site serves students at a US public institution, confirm with counsel how your entity is classified under DOJ guidance. Private institutions receiving federal funding may face related accessibility duties under Section 504/508. This guide shows you what WCAG 2.1 AA requires, what Moodle already provides, where the gaps are, and how to close them.

Outside the US? ADA Title II is a US federal law, but the accessibility principles it enforces -- WCAG 2.1 Level AA -- are widely recognised as the global benchmark for inclusive web design. Even if your country has no equivalent legal mandate, meeting these standards means your Moodle site works better for every student, regardless of ability. Accessibility is a good practice everywhere.

This is technical implementation guidance, not legal advice. Use it to prepare the platform and content workflow, then validate your specific compliance obligations with legal counsel.

What ADA Title II Actually Requires

Before this rule, Title II required "effective communication" for people with disabilities but specified no technical standard. Courts interpreted requirements case by case. The 2024 rule eliminates that ambiguity: WCAG 2.1 AA is the standard.

WCAG 2.1 Level AA contains 50 success criteria organised under four principles -- Perceivable, Operable, Understandable, Robust (POUR). The criteria that matter most for an LMS:

Perceivable:

• 1.1.1 Non-text Content: Every image, icon, and chart needs a text alternative. In Moodle, this means alt text on every image uploaded to course content.
• 1.2.1-1.2.5 Time-based Media: Pre-recorded video needs captions and audio descriptions. Pre-recorded audio needs transcripts. Live video needs captions.
• 1.3.1 Info and Relationships: Heading structure must be logical (H1 -> H2 -> H3). Data tables need headers. Lists must use list markup.
• 1.4.3 Contrast (Minimum): Text must have a contrast ratio of at least 4.5:1 against its background (3:1 for large text).
• 1.4.11 Non-text Contrast: Buttons, form fields, and icons need 3:1 contrast.

Operable:

• 2.1.1 Keyboard: Every function must work via keyboard alone. Quiz navigation, forum posting, assignment submission, and gradebook interaction must all work without a mouse.
• 2.4.1 Bypass Blocks: Users must be able to skip repeated navigation. Moodle's Boost theme satisfies this with skip links.
• 2.4.6 Headings and Labels: Headings and labels must describe purpose. "Click here" and "Read more" fail this criterion.
• 2.4.7 Focus Visible: Keyboard focus must be visible at all times.

Understandable:

• 3.3.1-3.3.2 Error Identification and Labels: Form errors must be described in text. Input fields must have labels.

Robust:

• 4.1.2 Name, Role, Value: All UI components must expose their name, role, and value to assistive technology via ARIA attributes.

What Moodle Gives You Out of the Box

Moodle LMS is built with a "Privacy and Accessibility First" philosophy. As of 2026, the following features are integrated into the core installation, ensuring a baseline for ADA Title II compliance without requiring a single third-party plugin.

1. The Boost Theme

Moodle's default theme, Boost, is engineered to meet the latest WCAG 2.2 Level AA standards.

• Navigation: Includes "Skip to main content" links and logical tab orders for keyboard-only users.
• Visuals: Native support for high-contrast ratios and visible focus indicators (the "outline" that appears when tabbing through links).
• Responsiveness: Fully responsive design that allows content to reflow and scale up to 400% zoom without losing functionality.

2. TinyMCE Accessibility Checker

The default text editor (TinyMCE) includes a powerful, built-in Accessibility Checker. Before publishing any content, instructors can click the "Checker" icon to instantly scan for:

• Images: Missing or non-descriptive alt-text.
• Contrast: Text colors that don't stand out enough against the background.
• Structure: Improper heading levels (e.g., jumping from H1 to H3) and missing table headers or captions.

3. Brickfield Accessibility Starter Toolkit

Moodle includes a "Starter" version of the Brickfield Toolkit in its core code. It automatically audits course content and provides:

• Accessibility Reports: A breakdown of common errors across the entire course.
• Heatmaps: Visual indicators on the course page that highlight which activities need immediate attention.

4. The AI Subsystem (New for 2026)

With the launch of Moodle 4.5 and 5.0, the AI Subsystem is now part of core. While it requires a connection to a provider (like OpenAI or a local model), the functionality is built-in to help with:

• Alt-Text Generation: Suggesting descriptive text for uploaded images.
• Content Simplification: The "Explain" and "Summarize" tools help make complex materials more accessible to learners with cognitive disabilities or non-native speakers.

5. Native Technical Compliance

• Language Declaration: Automatically sets the HTML lang attribute so screen readers use the correct accent and pronunciation.
• Form Labels: Every standard Moodle form is programmatically linked to its label, ensuring screen reader users know exactly what data to enter.
• ARIA Landmarks: Core templates use ARIA roles (e.g., role="main", role="navigation") to help assistive technology users jump between sections of the page quickly.

Where Moodle Deployments Fail Audits

Moodle core is a strong foundation. Accessibility compliance fails because of what happens on top of it.

Gap 1: Instructor-created content (the biggest gap)

Moodle gives instructors the tools to create accessible content -- it does not force them to use those tools. The most common violations:

• Images without alt text: Instructors upload images and leave the alt field blank. Every informational image needs descriptive alt text. Every decorative image needs alt="" so screen readers skip it.
• Videos without captions: Auto-generated captions have a significant error rate and do not satisfy compliance requirements. Captions must be reviewed and corrected.
• Untagged PDFs: Scanned documents are images of text. Screen readers cannot read them. All PDFs must be tagged (structured) for accessibility.
• Colour as the only indicator: Using red for "wrong" and green for "correct" fails WCAG 1.4.1. Students who are colourblind cannot distinguish the feedback.
• Broken heading hierarchy: Instructors use heading sizes for visual effect rather than logical structure, breaking screen reader navigation.

Gap 2: Third-party plugins

Plugins are developed independently and may not follow accessibility guidelines. Before deploying any plugin, verify keyboard navigation works for all functions, form elements have proper labels, and ARIA attributes are present in templates. Test manually with NVDA (Windows) or VoiceOver (macOS) before production deployment.

Gap 3: Custom themes

Custom CSS can introduce: colour combinations that fail contrast requirements, removed skip links, missing ARIA landmarks, and focus indicators overridden with outline: none.

Gap 4: H5P and multimedia content

H5P accessibility varies significantly by content type. Not all types are safe for compliance.

H5P Content Type	Accessibility	Notes
Multiple Choice	Good	Touch and keyboard friendly
True/False	Good	Large tap targets, clean layout
Accordion	Good	Keyboard-operable expand/collapse
Dialog Cards	Good	Keyboard-operable
Summary	Good	Simple list interaction
Course Presentation	Partial	Keyboard navigation works; complex slides may have issues
Fill in the Blanks	Partial	Works but on-screen keyboard can obscure content
Branching Scenario	Partial	Depends on content complexity
Interactive Video	Partial	Controls are keyboard-accessible; quiz overlays need testing
Drag and Drop	Poor	Known keyboard navigation issues -- avoid for compliance
Image Hotspots	Poor	Small targets inaccessible to keyboard and screen reader users
Mark the Words	Poor	Requires precise mouse interaction

SCORM packages: accessibility depends entirely on the authoring tool. Articulate Storyline, Adobe Captivate, and iSpring have varying accessibility output. Each SCORM package needs individual testing.

The 90-Day Accessibility Compliance Plan

If your ADA Title II compliance date is approaching, here is a practical plan to reach compliance. This plan assumes you're starting with a Moodle instance that uses the Boost theme (or a Boost-based child theme) and has not undergone a formal accessibility audit.

Days 1-14: Audit and Baseline

Platform audit:

1. Confirm you are running Boost theme (or audit your current theme against WCAG 2.1 AA)
2. Test 10 representative pages with the WAVE browser extension (wave.webaim.org) -- record error types and counts
3. Test keyboard navigation on: login, dashboard, a course page, a quiz, assignment submission, a forum, the gradebook
4. Test with a screen reader (NVDA or VoiceOver) on the same 10 pages
5. Document findings: page URL, issue description, WCAG criterion violated, severity (critical/major/minor)

Content audit:

1. Install Brickfield Accessibility Toolkit and run a full site scan
2. Generate the summary report -- it shows error counts across your entire instance
3. Identify the courses producing the most errors (the top 20% typically account for 80% of issues)
4. Document the most common error types

Days 15-45: Fix Platform-Level Issues

1. Verify all custom CSS maintains 4.5:1 contrast ratios (use WebAIM Contrast Checker)
2. Confirm skip links are present and functional
3. Verify ARIA landmarks are intact (Accessibility Insights browser extension)
4. Fix any broken keyboard navigation in custom theme elements
5. Verify TinyMCE Accessibility Checker is active in the toolbar: Site Administration -> Plugins -> Text Editors -> TinyMCE editor -> General settings
6. Audit all installed plugins; replace or remove those with critical accessibility failures

Days 46-75: Fix Content-Level Issues

Work in this priority order -- the highest-impact issues first:

1. Missing alt text: Export the Brickfield report filtered to "Image missing alt text." Assign remediation to instructors or teaching assistants.
2. Videos without captions: Review all video content. For YouTube-hosted videos, enable and review auto-captions (they must be corrected, not used as-is). For other videos, use a captioning service. Budget roughly $1-3 per minute of video depending on provider and turnaround time.
3. Untagged PDFs: Replace scanned PDFs with tagged versions. Where source files are available, recreate from Word with heading styles applied. For scanned documents, use Adobe Acrobat's OCR and tagging tools.
4. Broken heading hierarchy: Correct heading levels using the TinyMCE editor to ensure a logical structure (e.g., no jumping from H2 to H4) for screen reader navigation.
5. Colour-only indicators: Replace colour-only feedback with text labels or icons alongside colour.
6. Data tables without headers: In TinyMCE, use the Table properties or Cell properties menu to define 'Header cells' for rows and columns.

Days 76-90: Verify, Document, Train

Verification:

1. Re-run the Brickfield scan and compare error counts to your Day 14 baseline
2. Re-test the 10 representative pages with WAVE
3. Conduct a screen reader test of the full student journey: login -> find course -> view content -> take quiz -> submit assignment -> view grade -> post in forum

Documentation (essential for legal protection):

1. Publish an accessibility statement at a known URL (e.g. yoursite.edu/accessibility) covering: standards you conform to, known limitations, contact method for reporting barriers, and date of last audit
2. Keep audit records -- Brickfield reports, WAVE results, remediation logs -- for at least three years
3. Document your content accessibility policy for instructors

Training:

1. Train all instructors on alt text, heading hierarchy, caption requirements, and accessible document creation, with a specific focus on using the TinyMCE accessibility checker and the Brickfield course heatmap.
2. Create a one-page quick reference card
3. Add accessibility requirements to your course quality review process
4. Schedule quarterly spot checks

Plugin Recommendations

Brickfield Accessibility Toolkit

Brickfield is the most comprehensive accessibility auditing plugin for Moodle. It provides automated scanning across all HTML content, dashboard reports showing error counts by type and by course, and heatmaps identifying the highest-problem courses.

Important: The free (Starter) edition covers essential scanning and reporting. Bulk remediation tools -- which let you fix common issues across multiple pages without editing each one individually -- require the paid (Enterprise) edition. If your content volume is large, the Enterprise edition will save significant staff time and is worth evaluating before you begin remediation.

Install from: Site Administration -> Plugins -> Install Plugins -- search "Brickfield Accessibility Starter Toolkit."

Additional tools

• WAVE browser extension: Free, browser-based page-level scanning. Use for spot checks and verification.
• Accessibility Insights: Free browser extension for ARIA landmark verification and keyboard navigation testing.
• WebAIM Contrast Checker: Free tool for verifying colour contrast ratios during theme customisation.
• Ally: If your institution has an Ally licence, a Moodle integration plugin scans uploaded documents and generates alternative formats automatically.

Common Pitfalls

1. Relying on automated tools alone. Automated checkers catch roughly 30-40% of WCAG violations. They detect missing alt text, contrast failures, and missing form labels. They cannot assess whether alt text is actually descriptive, whether content makes sense when linearised for a screen reader, or whether keyboard focus order is logical. Manual testing is required.
2. Setting empty alt text on informational images. Every image is either informational (conveys meaning) or decorative (purely visual). Decorative images need alt="" so screen readers skip them. Informational images need descriptive alt text. The mistake: setting alt="" on informational images to pass automated checks. This makes the image invisible to screen reader users while appearing compliant in reports.
3. Treating accessibility as a one-time project. Every time an instructor uploads a new PDF, embeds a new video, or adds a new page, they can introduce new violations. Compliance requires ongoing scanning, instructor training, and a process for handling student accessibility complaints.
4. Overlooking timed quizzes. WCAG 2.2.1 (Timing Adjustable) requires that users can turn off, adjust, or extend time limits. Moodle supports quiz time extensions through User Overrides (Quiz -> More -> Overrides -> User Overrides). Configure accommodations before students encounter the time limit.
5. Ignoring the business case. Accessible design benefits all learners, not just those with disabilities. Captions help non-native speakers. Keyboard navigation helps power users. Proper heading structure makes content easier to scan. High-contrast text is easier to read on mobile screens in sunlight. Research published in the American Journal of Distance Education found that students across all groups -- not only those with hearing impairments -- showed improved comprehension and retention when video content included captions.

Start Your Accessibility Compliance on a Solid Foundation with MooDIY

The 90-day plan in this guide assumes your Moodle instance is running correctly -- current version, default Boost theme intact, scheduled tasks firing, and performance stable enough that screen reader users aren't timing out on slow page loads.

If your Moodle is self-hosted on aging infrastructure, running an outdated version, or managed by a provider who hasn't kept up with core updates, accessibility compliance becomes significantly harder before you've fixed a single heading or captioned a single video.

MooDIY's managed Moodle hosting, particularly the Premium and Enterprise plans, gives you a clean, current, well-maintained starting point, so your team can focus on the content remediation and instructor training that actually determines whether you pass an audit.

• Start a free MooDIY trial ->
• View hosting plans ->

Related reading: Data Privacy Compliance for Moodle: GDPR, FERPA, CCPA, Moodle vs Canvas vs Blackboard: Accessibility Comparison, The Best Moodle Themes for 2026

Research References

1. Legal and Regulatory

• ADA Title II Final Rule
• DOJ 2026 Interim Final Rule Extending Title II Web Compliance Dates

2. WCAG Standards

• WCAG 2.1 Specification -- W3C
• WCAG 2 Overview -- W3C WAI
• How to Meet WCAG -- Quick Reference
• WebAIM WCAG 2 Checklist

3. Moodle Accessibility

• Moodle Accessibility Documentation
• Moodle Accessibility Developer Policy
• Moodle Accessibility Toolkit Docs
• Moodle VPAT (WCAG 2.2 AA Conformance)

4. Testing Tools

• WAVE Accessibility Tool
• WebAIM Contrast Checker
• Accessibility Insights (Microsoft)
• Brickfield Enterprise Toolkit

5. Screen Reader Testing Tools

• NVDA Screen Reader
• VoiceOver (Apple)