How ADA Title II accessibility applies to an open source LMS
If you run a public school, college or state agency, the April 26, 2027 deadline applies to entities serving 50,000 or more people, and April 26, 2028 applies to smaller entities and special districts. Under the ADA Title II web rule, state and local government web content and mobile apps must meet WCAG 2.1 Level A and AA. For an LMS, the short answer is that the platform itself, its theme, its plugins and the course content it delivers all fall within that rule. Each of those layers needs a named owner before the deadline, because a gap in any one of them can leave the whole learning environment out of conformance. The rule also reaches content provided through contracts or licenses, so a hosted or supported platform does not move the obligation away from you. Confirm your population category with your counsel or state authority, since it determines which date applies to you.
Start with an inventory and an audit. For a self-hosted Moodle, Canvas or Open edX site, list the core version, every installed theme and plugin, custom code, and the authentication and LTI tools that learners reach from inside the course. Moodle's own support windows matter here: Moodle 5.3 is the next long-term support release, with security fixes until October 1, 2029, while Moodle 4.5 security support ends October 4, 2027. Plan your upgrade path so that accessibility fixes in core and in your theme land on a supported release. Canvas is AGPL-3.0 and Open edX is AGPL-3.0, and Open edX supports only its latest release, so confirm the upgrade cadence before you commit to either. Your audit should test login, navigation, quizzes and gradebook screens against WCAG 2.1 AA and against the nine criteria WCAG 2.2 added, such as 2.4.11 Focus Not Obscured and 2.5.8 Target Size (Minimum).
Instructor-made content is where ownership is most often unclear. Assign remediation of documents, videos, captions and quizzes to course owners, with a central accessibility lead who sets the standard and reviews a sample each term. Decide early whether your evidence file will include a remediation log per course. DeployOpen can prepare the systems, controls and evidence for an assessment, including audit scripts, test records and a remediation tracker, but it does not issue audit reports, attestations or certifications. Those come from independent assessors or certification bodies that you choose. Ask any implementation partner to state in the written scope what it will test, what it will fix, what it will hand back to your staff, and which evidence it will deliver.
Mapping WCAG 2.1 AA obligations to LMS configuration
This table maps each WCAG 2.1 Level A and AA area that an ADA Title II audit will test against the LMS layer, the configuration step that addresses it, and the evidence to keep. Read each row as a question to answer for your own Moodle, Canvas or Open edX instance, since theme, plugin and course-template choices decide most of the result. The main takeaway is that much of the work sits in the theme, login flow and course templates, not in the core platform alone.
| Requirement area | Configuration step | Evidence to keep and where it usually fails |
|---|---|---|
| Navigation and keyboard access | Choose a theme with tested skip links, logical heading order and visible focus; disable custom menus that trap focus; test every course page with keyboard only. | Keyboard test scripts and audit results per theme version. Fails often in custom theme components and third-party course blocks. |
| Text alternatives for course media | Set course templates to require alt text for images, captions for video and transcripts for audio; restrict embedded media to tools that expose text alternatives. | Template checklist and sample course audit. Fails when instructors upload scanned PDFs or embed external video without captions. |
| Color and contrast in the theme | Set brand colors in the theme settings against a contrast check, and test links, buttons and focus rings in each supported browser. | Contrast test report for the theme. Fails when instructors add colored text or when a plugin ships its own palette. |
| Form and login labels | Configure the login page and self-registration forms with visible labels and error messages; confirm the chosen authentication plugin (for example, SAML 2 or LDAP) passes its own form to the same standard. | Screen reader test of login, password reset and enrollment forms. Fails at identity provider screens outside the LMS. |
| Reports and certificates | Build completion reports and certificate templates as accessible tables and documents; test the generated PDF for tagged structure and reading order. | Sample exported reports and certificates with test results. Fails when generated PDFs lack tags or when tables lack header rows. |
| Plugin and theme audits | Keep an inventory of every plugin and theme, its license and its accessibility statement; retest after each Moodle minor release or LTS upgrade. | Inventory with dated test results. Fails when unmaintained plugins are installed and no owner is named. |
| Document root setup | From Moodle 5.1, point the web server document root to the /public directory rather than the main Moodle folder, so configuration and test environments match production. | Server configuration record. Misconfigured roots can expose directory listings or errors that a tester will flag. |
Which open source LMS fits which accessibility starting point
Moodle is licensed under GPL-3.0 and is maintained by Moodle HQ, and it can be self-hosted or run as managed hosting through MoodleCloud or Moodle Partners. Its accessibility starting point depends heavily on the theme and the third-party plugins in use, because the core is only one part of what learners see. Moodle 5.3 is designated the next long-term support release, with bug fixes until October 4, 2027 and security fixes until October 1, 2029, which gives a planning window that matches many public budget cycles. Moodle 5.3 also removes the Classic theme from core, so any institution still depending on it must plan a theme migration and re-test.
- Theme audit scope: Test the chosen theme and every custom theme override against WCAG 2.1 AA, including focus order, color contrast, and form labels in course and admin pages.
- Plugin inventory: List every activity, block, filter and authentication plugin in use, since each one can introduce its own inaccessible markup.
- Classic theme removal: Confirm which sites rely on the Classic theme and budget a re-test of course pages after the move to Moodle 5.3.
- Upgrade path: Moodle 5.3 requires PHP 8.3 or later and sites must run Moodle 4.4 or later to upgrade, so older sites need a staged upgrade with accessibility regression tests at each step.
- Instructor content: Core Moodle does not make instructor-uploaded files accessible, so content remediation must be planned separately.
Confirm current WCAG conformance claims with Moodle and with your own tests, not with marketing statements.
Canvas LMS by Instructure is licensed under AGPL-3.0, so an institution that self-hosts it takes on the license obligations for any modifications it distributes or exposes over a network. Its user interface and theme layer determine most of what learners and instructors encounter, so the audit should start with the theme your institution applies rather than assuming the upstream interface meets the standard. Because the platform is a single codebase with its own release process, the accessibility work is largely about local customizations, LTI tools and content that instructors publish inside it.
- AGPL obligations: Involve legal counsel early if you modify Canvas, since AGPL-3.0 extends source obligations to users who interact with the software over a network.
- Custom theme audit: Test each institutional theme override for keyboard access, contrast and screen reader output across course navigation, grading and quiz pages.
- LTI tool review: Each external tool launched from Canvas must be checked for accessible output, because the tool owns its own interface.
- Instructor content: Documents, slides and embedded media created by instructors need their own remediation workflow, since the platform does not guarantee them.
- Upgrade regression: Retest your custom accessibility fixes after each upstream release so that they are not silently lost.
Ask Instructure and your own testers which WCAG conformance statements apply to the version you run, and verify them against your environment.
Open edX is licensed under AGPL-3.0, and Verawood is the current named release. The next releases are planned for December 2026 (Willow) and June 2027 (Xylon), and only the latest release is supported. That support model means an institution running Verawood must plan to move to each new release on the published schedule, or accept that its accessibility fixes and security patches will not be covered by upstream support. Open edX is course-centric, so the audit focuses on the learning frontend, course templates and the XBlocks that instructors add to courses.
- Latest-release policy: Plan an upgrade cycle that moves to Willow and then Xylon when they ship, and retest accessibility after each move.
- XBlock inventory: Check every XBlock used in courses for keyboard operation, labels and contrast, because XBlocks are the most common source of inaccessible interactive content.
- Learning frontend audit: Test the course player, navigation and discussion pages with assistive technology and keyboard only.
- Course authoring: Set standards for instructors using the studio editor, including alternative text and captions for media.
- AGPL review: As with Canvas, AGPL-3.0 applies to modifications exposed over a network, so record any changes made to the frontend.
Confirm the WCAG conformance status of the release you deploy with the Open edX community and through your own testing before you make any claim.
Platforms that fit Title II accessibility work
Title II obligations reach the LMS itself, its theme and plugins, and the content learners open inside it. The cards below cover the platforms and plugin types a site audit has to inventory, and what each one means for conformance work before the April 26, 2027 and April 26, 2028 dates.
Moodle core and theme
Moodle is licensed under GPL-3.0 and maintained by Moodle HQ, so the core accessibility fixes arrive through its release cycle. Your audit should record the exact Moodle version, then check whether your theme is a standard or customized build, because theme markup often drives focus order, contrast and heading structure. From Moodle 5.1, the web server document root must point to the public directory, which also affects how you test. Confirm that your theme is supported on the version you run.
Canvas LMS by Instructure
Canvas LMS is licensed under AGPL-3.0, so the source is available to inspect and modify under that license's terms. If you self-host it, the accessibility posture of the code is a shared responsibility between the vendor, your hosting partner and your own customizations. Ask the vendor for its current conformance documentation and the scope it covers, and confirm whether that documentation applies to your self-hosted version rather than only the hosted service.
Open edX platform
The Open edX platform is licensed under AGPL-3.0 and only its latest named release receives support, so every accessibility fix you depend on must be carried through regular upgrades. Plan the upgrade path before the compliance date, because a site that falls behind the supported release can end up with unpatched accessibility defects. Confirm which course authoring tools your instructors use and whether their output keeps semantic structure in the exported content.
Login flows and core authentication
Moodle core ships authentication plugins for manual accounts, LDAP, LTI, OAuth 2 and Shibboleth, among others. Login is where WCAG 2.2 criterion 3.3.8 Accessible Authentication matters most, since it limits cognitive tests such as memorized passwords or puzzles unless alternatives exist. Test each login path, including single sign-on redirects, password reset and error messages, with assistive technology. Confirm that your identity provider does not force a step that fails the criterion.
SAML2 single sign-on plugin
The SAML2 single sign-on plugin is a third-party Moodle plugin that adds federated login, which many universities and agencies use for their identity providers. It is not core code, so its markup, redirects and error pages fall outside the core accessibility fixes and need their own review. Test the plugin's login screens and any message shown after a failed sign-in. Confirm the plugin version is supported on your Moodle release before you add it to the audit scope.
Plugin types for the site audit
A conformance audit must cover every plugin type that renders learner-facing output, not just the theme. In Moodle, these include activity modules, blocks, filters, question types, reports and authentication plugins, each with its own markup. Build an inventory that lists each installed plugin, its version, its source and whether it renders content for learners. Mark plugins that are unmaintained or that you have modified, since those carry the highest remediation effort.
Who owns remediation of instructor-made content
This sequence assigns each layer of an accessible LMS to a named owner, so the institution can show that the platform, its plugins and the course materials published on it each meet WCAG 2.1 Level AA before the applicable compliance date. It ends with a register that a reviewer can follow from rule to individual course.
Assign the legal duty to the agency or institution
The public entity remains responsible for web content and mobile apps it provides, and the ADA Title II rule applies to content provided through contracts or licenses. Leadership names an accessibility owner, sets the target standard as WCAG 2.1 Level AA, and records which compliance date applies to the entity based on the population it serves. Done when a signed accountability memo states that a vendor contract, open-source license or support agreement does not transfer the duty, and the accessibility owner has a documented scope covering the LMS, its theme and every plugin.
Inventory the LMS, theme and plugin surface
The accessibility owner and the LMS administrator list every surface learners and instructors touch: the Moodle or Canvas or Open edX core pages, the active theme, each installed plugin, authentication screens, and any embedded third-party tool or LTI launch. Each item is tagged with an owner and a version. Done when the inventory is complete enough that an auditor could pick any page or plugin and trace it to a person responsible for testing it.
Audit platform, theme and plugin conformance
The LMS administrator or the implementation partner runs automated scans and manual testing with assistive technology against core pages, the theme and high-use plugins, mapping findings to WCAG 2.1 criteria and noting where WCAG 2.2 additions such as 2.4.11 Focus Not Obscured apply as good practice. Done when each defect has a severity, a reproduction path and an assigned fix owner in the issue tracker.
Fix platform and theme defects in the core stack
The LMS administrator fixes theme and configuration defects directly, such as contrast, heading structure and focus order, and records each change in version control. Defects inside a third-party plugin go to its maintainer through the upstream issue process, and where a fix cannot wait, the implementation partner patches a local copy or replaces the plugin under a documented change. Done when retesting shows the fix in place and the change log names the owner who approved it.
Set authoring rules and course templates
The LMS administrator and the accessibility owner publish course templates with proper heading levels, alt text prompts, captioned media requirements, accessible table markup and document formats that screen readers handle. Instructors and content owners must use these templates for new material. Done when the templates are installed in the LMS, instructors have acknowledged the authoring standard, and the template version appears in each course record.
Assign remediation of instructor-made content
Each instructor or content owner remediates the course materials they publish, including documents, slides, video captions, and quiz layouts, and certifies completion in the course. Materials supplied by a vendor, publisher or outside tool are routed to the contract owner, who must obtain conforming versions or a written accessibility statement before the content goes live. Done when every published course has an owner, a remediation status, and a record of any vendor content still awaiting a conforming version.
Retest, record and maintain the register
The accessibility owner reviews a sample of published courses and retests platform and plugin fixes after each upgrade, since Moodle, Canvas and Open edX ship new releases on their own schedules. Findings, owners, fix dates and retest results go into one accessibility register that also tracks which plugin versions are supported. Done when the register can answer which person fixed a given defect, when it was verified, and which course is still open, and when a new platform or plugin version is installed, the affected items are retested before go-live.
Evidence auditors and DOJ reviewers ask for
This table lists the evidence items a state or local entity should be able to produce for an LMS under the ADA Title II web rule, the component that generates each item, and where it usually falls short. Read it as a checklist to agree with your implementation partner before the April 26, 2027 or April 26, 2028 compliance date applies to your entity.
| Evidence item | Produced by | What reviewers expect to see | Where it usually fails |
|---|---|---|---|
| WCAG 2.1 AA test results for theme and core pages | Theme and core LMS pages, tested with automated and manual methods | Dated results per page template covering login, dashboard, course page, gradebook and quiz, with failures logged against WCAG 2.1 Level A and AA criteria | Testing covers only the home page or runs once at launch and is never repeated after upgrades |
| Plugin inventory with versions and conformance status | Plugin register maintained by the platform team, checked against each installed plugin | Every installed plugin, its version, its source, whether it is in use, and a conformance status or known gap for each | Plugins installed for a pilot remain active, or accessibility status is unknown for third-party and AI plugins |
| Remediation backlog for course content with owners and dates | Course audit reports and the content issue tracker, tied to course templates | Each inaccessible course or resource listed with the responsible instructor or department, a target date and a status | Instructor-made content is outside the tracker, so no owner or date is recorded for it |
| Course template accessibility checks | Course templates and content authoring standards used by instructors | Templates with headings, alt text prompts, captioning steps and table markup built in, plus a record of the check against each template version | Templates are copied and edited locally, so new courses drift from the checked version |
| Moodle upgrade record against security support windows | Upgrade log and the LMS maintenance calendar | Installed Moodle version, upgrade dates and the security support end date for each release, such as 5.1 security support until 19 April 2027 and 5.3 until 1 October 2029 | The site runs a release past its security support window, or upgrades are undocumented |
| LMS reports showing accessibility-related usage and issues | LMS reporting and logs, including course completion and support ticket reports | Reports that show which courses were accessed with assistive technology issues, and how reported barriers were routed and closed | Reports exist, but no one reviews them or links them to the remediation backlog |
| Accessibility statement and feedback channel | Public accessibility page and a monitored contact route, configured on the LMS login and footer | A published statement with conformance status, known limitations, a contact method and a record of how requests were answered | The statement is out of date, lacks a named contact, or does not reflect the current LMS version |
| Contract terms covering contracted content and tools | Procurement files and vendor or partner agreements | Clauses requiring vendors and partners to deliver conforming themes, plugins and content, with rights to test and receive remediation | Contracts are silent on accessibility, so the entity carries the duty without the means to meet it |
What tooling alone does not satisfy
Moving Moodle, Canvas or Open edX to a compliant state is only part of the Title II work. The gaps below sit in course content, third-party tools, future WCAG releases and the agreements that govern who fixes what, and no platform setting closes them on its own.
Automated checks miss most criteria
Automated accessibility checkers can flag problems such as missing alternative text, low color contrast and missing form labels, but many WCAG success criteria need a person to judge meaning, reading order, focus behavior and whether a link makes sense out of context. Treat a clean scan as a starting point. Ask any partner which criteria were tested manually, with which assistive technologies, and who signed off on the results.
Instructor-made content needs review
Course pages, uploaded PDFs, slide decks, quizzes and embedded documents are authored by faculty and staff, not by the platform team. Each one must meet the same WCAG 2.1 AA standard as the platform, so a governance step is needed before publication, not after a complaint. Decide who reviews new content, how remediation requests are tracked and which legacy courses are retired rather than repaired.
LTI and video tools sit outside
External LTI tools, embedded video players, interactive simulations and proctoring widgets render inside your course but are built and hosted by other vendors. Their captions, keyboard support and focus handling are not controlled by your Moodle, Canvas or Open edX configuration. Inventory every tool launched from the LMS, collect each vendor's accessibility statement and test the tools a learner must use to finish a course.
WCAG 2.2 criteria need re-testing
The current WCAG 2.2 Recommendation, dated 12 December 2024, adds nine success criteria to WCAG 2.1, including 2.4.11 Focus Not Obscured (Minimum), 2.5.8 Target Size (Minimum) and 3.3.8 Accessible Authentication (Minimum). The Title II rule references WCAG 2.1 AA, so 2.2 is not the legal floor, but a theme or plugin that passes 2.1 can still fail these checks. Plan a regression pass after each platform upgrade and theme change.
Policy and procurement are not configuration
An accessibility statement, a remediation policy, staff training and vendor contract clauses determine whether the institution can show a compliant process. Procurement terms should require vendors to state their WCAG conformance, provide a current accessibility report and fix defects within an agreed window. None of these items can be set in a platform admin screen, so assign an owner for each and record who approved them.
Evidence comes from your own testing
DeployOpen plans and runs accessibility testing of the platform, theme, plugins and course templates, and documents the results and remediation for your records. DeployOpen does not issue audit reports, attestations or certifications. An independent auditor or your own compliance function makes that judgment, so ask any partner what evidence it will deliver and which party signs the conclusions.
What do agencies and schools ask before hiring an accessibility partner?
What drives the cost of an ADA Title II accessibility engagement for an LMS?
The cost follows the audit scope: how many courses, pages and media files are in scope, how many themes and plugins run on the site, how much legacy course content needs remediation, and whether the theme needs custom work. Ask for a written scope that lists each of these as a separate line, because a quote that does not split them cannot be compared across bidders. Audit, remediation and retesting are different pieces of work, so ask whether each is priced separately and whether retesting after fixes is included. No fact in this page sets a price or effort figure, so treat any number a bidder gives as a proposal to check against the scope, not as a benchmark.
How long does LMS accessibility remediation take?
Duration depends on the volume of content, the number of plugins and themes that need changes, and how many fixes depend on upstream vendors or on instructors. The compliance dates are fixed: under the ADA Title II rule, entities serving 50,000 or more people must meet WCAG 2.1 Level A and AA from 26 April 2027, and smaller entities and special districts from 26 April 2028, according to 28 CFR 35.200. Work backward from your date, and ask any partner to show a plan with milestones, the sequence of fixes and the review steps. Do not accept a duration that has no stated scope behind it.
Can our own staff do the accessibility remediation in-house?
Often partly, yes. Staff who administer Moodle can usually handle theme settings, plugin configuration and course templates, while fixes that touch templates or custom code need developers who understand the WCAG 2.1 success criteria and can test with assistive technology. Instructor-made content is harder to hand back, because each course owner must fix headings, alternative text, captions and document structure. Before deciding, list which items you can assign to named owners, which need a developer, and which need an outside auditor to confirm the result. The W3C WCAG 2.2 documentation is a useful reference for internal reviewers.
What do instructors and IT staff need to contribute to remediation?
Instructors must correct the content they author, including headings, alternative text for images, captions for video, descriptive link text and accessible tables and documents. IT staff must provide access to the site, test accounts, the current theme and plugin list, and the server configuration, and they must schedule changes around term calendars. Ask the partner to name who approves each change, how instructors receive guidance and examples, and how they are told which courses are complete. Without a clear owner for each course, legacy content tends to stay unfixed after the platform work is finished.
Can a self-hosted Moodle site meet the April 2027 or April 2028 dates?
A self-hosted Moodle can meet the dates if the site, its theme, plugins and course content are brought to WCAG 2.1 Level AA and the evidence is kept, and nothing in the platform choice prevents that. The timing depends on the version path. Moodle 5.3 is the current long-term support release, released on 5 October 2026, with security support until 1 October 2029, and Moodle 5.1 requires PHP 8.2 or later and specific database versions for upgrade. Plan the platform upgrade and the accessibility work together, because a theme change on an old version can be wasted by a later upgrade. Confirm the exact support and upgrade path with Moodle release notes and your partner before setting milestones.
Will an accessibility partner issue an audit report or certificate for our LMS?
DeployOpen does not issue audit reports, attestations or certifications. It can prepare the systems, controls and evidence that an assessment will review, such as test records, remediation logs and content inventories, while independent auditors and certification bodies perform the formal assessment. Ask any partner to state in writing which deliverables are testing reports and which are assessment outputs. Where your agency needs a formal conformance statement, confirm with your legal or compliance office who issues it and what they will accept as evidence.
What should a written accessibility scope include for an LMS?
A written scope should name the platform version, the theme, every plugin and integration in use, the course inventory with counts by type, the content formats such as video and PDF, and the standard being tested, which is WCAG 2.1 Level AA for the ADA Title II rule. It should also state what is excluded, for example third-party tools that the school does not control, and who owns the retest. Ask the partner to list the deliverables, the acceptance steps and the change process if the inventory grows during the work. A clear scope is the strongest protection against cost surprises.
How DeployOpen scopes and delivers accessibility work on an LMS
The sequence turns an accessibility obligation into a written scope, a dated audit of the platform and a sample of course content, fixes that are verified, and an evidence package that your own auditors and counsel can review.
Confirm which entity and deadline apply
Before any technical work, DeployOpen reviews with your legal, procurement and accessibility leads which ADA Title II compliance date applies to your entity, based on the population you serve, and which LMS, themes, plugins and content libraries fall inside the rule's reach, including services provided through contracts or licenses. The output is a short written scope statement listing in-scope systems, the WCAG 2.1 Level A and AA target and the responsible owner for each category of content. Confirm the applicable date directly with counsel and the rule text, not with this page.
Audit the core, theme and plugins
DeployOpen's engineers test the running Moodle, Canvas or Open edX instance against WCAG 2.1 AA, covering keyboard navigation, focus order, form labels, color contrast, headings, and the authentication and course navigation flows. They also review the theme and every installed plugin, and record the exact version of each, since a core upgrade can change results. The output is a defect register that separates platform fixes, theme fixes, plugin fixes and content issues, with each item tied to a WCAG success criterion and an owner.
Sample and test representative course content
Because instructor-made content is usually the largest accessibility gap, DeployOpen agrees with you on a sample of courses that covers each content type in use, such as documents, slide decks, video, embedded tools and SCORM packages. Each sampled item is tested with assistive technology and automated tools, and results are logged by course and by content owner. The output is a content findings report that shows which failures recur, so you can decide whether to fix at the source template, the theme or the authoring guidance.
Agree fixes and remediation ownership
DeployOpen and your team review the registers together and assign each fix to a named party: DeployOpen for theme, plugin and configuration changes, your faculty or staff for instructor-made content, and your vendors for third-party tools. Fixes are sequenced by risk and by the compliance date, and anything that depends on an upgrade is scheduled against the platform's release and support windows. The output is a signed remediation plan in the written scope, so ownership of each defect is explicit before work begins.
Implement and retest the changes
DeployOpen makes the agreed changes in a staging copy of the platform, documents each change in a change log, and retests the same pages, plugins and sampled courses against the original defect register. Changes that touch shared templates are checked across all courses that use them. The output is a retest report that marks each defect as resolved, partly resolved or open, with the evidence for each status, so no fix is accepted on the basis of a developer's assertion alone.
Hand over the evidence package
DeployOpen compiles the audit method, the scope statement, the defect and retest registers, the change log, the accessibility statement inputs and the remediation owner list into a handover package that your staff can keep. DeployOpen prepares systems and evidence for assessments, but it does not issue audit reports, attestations or certifications, so your internal audit, legal counsel or an independent assessor decides what the evidence demonstrates. The output is a dated package you own and can present to them.
Maintain through support retainers
Accessibility status changes with every core upgrade, new plugin, theme edit and new course, so DeployOpen can offer ongoing support under a retainer that covers regression checks after upgrades, plugin reviews before installation and periodic sampling of new content. The retainer scope is written and priced separately from the initial engagement. The output is a recurring review cadence and a revised register each cycle, which keeps the evidence current for each future assessment.
