An accessible Moodle platform can still contain an inaccessible course. The theme may support keyboard navigation perfectly while a tutor uploads an untagged PDF, uses colour as the only status indicator or embeds an assessment that cannot be completed without a mouse.
That distinction matters. Moodle reports that its LMS, Workplace product and app have achieved WCAG 2.2 Level AA accreditation, but a conformant foundation does not automatically make every theme, plugin, integration or item of course content conformant. Accessibility is a property of the complete learner journey.
This guide turns WCAG 2.2 into a practical Moodle checklist for administrators and course teams. It is not a substitute for an accessibility audit or legal advice. It is a repeatable way to find barriers early, assign responsibility and prevent the same defects returning in the next course build.
Start With the Learner Journey, Not the Compliance Score
The Web Content Accessibility Guidelines 2.2 organise accessibility around four principles: content must be perceivable, operable, understandable and robust. These principles are more useful when treated as learner questions:
- Can I perceive the information in a form that works for me?
- Can I operate every control with my input method?
- Can I understand the structure, instructions and feedback?
- Can my browser or assistive technology interpret the experience reliably?
For a Moodle course, the test boundary starts before enrolment and ends after completion. It includes authentication, the dashboard, course navigation, content, activities, embedded tools, assessment, feedback, certificates and support. Testing only the course homepage misses the places where consequential barriers often appear.
Accessibility also supports sound learning design. Clear structure, descriptive links, predictable navigation and concise instructions reduce unnecessary cognitive load for everyone. They complement the techniques in our guide to designing courses learners actually finish.
The Practical Moodle Accessibility Checklist
Use this checklist during design, before release and after material changes. Test a representative course rather than an empty Moodle installation: real content exposes different problems from a clean template.
1. Give Every Page a Meaningful Structure
Use the page title and Moodle section names to tell learners where they are. Within Pages, Books, Labels and activity descriptions, apply genuine heading styles in a logical order. Do not simulate a heading with bold text, a larger font or a different colour.
Keep section names concise and unique. “Module 3: Applying the policy” is more useful than a row of sections all called “Resources”. Avoid deep, repetitive course layouts that force keyboard and screen-reader users through dozens of links before reaching the current activity.
Check the order in which content is announced, not merely how it appears visually. A two-column layout can look sensible while producing a confusing reading sequence when linearised.
2. Make Text, Instructions and Links Self-Explanatory
Write instructions that identify the action, expected output and completion condition. Avoid relying on position or appearance alone, such as “click the green button on the right”. The learner may be using a narrow mobile viewport, magnification or a screen reader.
Use descriptive link text. “Download the safeguarding checklist (PDF, 420 KB)” gives more information than “click here”. If several links share the same wording but lead to different destinations, screen-reader link lists become difficult to interpret.
Set the correct language for the course and mark passages in another language where the editor permits it. Expand abbreviations on first use and prefer plain English unless specialist vocabulary is itself a learning objective.
3. Provide Useful Alternatives for Visual Information
Give informative images concise alternative text that communicates their purpose in context. A chart needs its conclusion or underlying data, not simply “bar chart”. Mark decorative images as decorative so assistive technology can ignore them. Do not place essential instructions inside an image.
Text and meaningful interface elements should meet WCAG contrast requirements. At Level AA, normal text needs a contrast ratio of at least 4.5:1 and large text at least 3:1, subject to the exceptions in the standard. Never use colour alone to distinguish correct from incorrect, mandatory from optional or complete from incomplete.
Check diagrams at 200% zoom and on a small screen. If labels become illegible, overlap or require two-dimensional scrolling, provide a structured text explanation close to the image.
4. Treat Video, Audio and Documents as Course Content
Provide accurate captions for prerecorded video with meaningful audio. Review automatically generated captions; names, technical terms and medication names are common failure points. Supply a transcript for audio-only material and describe important visual information that is not conveyed by the soundtrack.
Prefer native Moodle Pages and Books for material learners must read and act on. HTML content usually adapts better to zoom, reflow and user preferences than a fixed-layout document. When a downloadable document is necessary, give it headings, a logical reading order, tagged images, meaningful links and an informative filename.
An accessible course page does not compensate for an inaccessible PDF, slide deck or video player. Include these assets in the same release gate as Moodle-native content.
5. Design Activities and Assessments for More Than One Input Method
Make sure instructions remain available while the learner completes the task. Form fields need visible labels, required states must be communicated without colour alone, and error feedback should explain what needs correcting.
Check time limits. Where a limit is genuinely required, tell learners before they begin and use Moodle settings that support permitted extensions or overrides. Do not make speed an accidental learning outcome.
Avoid making drag-and-drop the only way to answer unless an equivalent pointer-free method is available. Question types, H5P content and externally authored packages can introduce their own interaction barriers. Test them with keyboard-only navigation and at substantial zoom before assigning them.
6. Test Keyboard, Focus, Zoom and Reflow
From the sign-in page, put the mouse aside. Use Tab and Shift+Tab to move, Enter or Space to activate controls, arrow keys where expected and Escape to close overlays. Every interactive element should be reachable, focus should remain visible, and focus order should follow the intended task.
Pay particular attention to navigation drawers, pop-up dialogues, embedded players, cookie controls and sticky headers. WCAG 2.2 added criteria addressing focus that is hidden by other content and minimum target size, both relevant to customised themes and dense activity screens.
Then resize text to 200% and test reflow at a 320 CSS-pixel-wide viewport, commonly reached by zooming a 1,280-pixel desktop viewport to 400%. Content should reflow without losing information or functionality. Test the Moodle app separately if it is part of the supported learner journey; an app and a responsive browser page are not interchangeable test environments.
7. Audit Plugins, Packages and Integrations as Part of Moodle
A third-party activity sits inside the learning journey even when another supplier hosts it. Ask for an accessibility conformance report for the exact product and version, then verify the claims with realistic tasks. A document alone is not evidence that your particular configuration is accessible.
For SCORM, H5P and LTI content, include launch, interaction, completion reporting and return navigation in the test. Our SCORM, xAPI and LTI guide explains where responsibility and learner data cross system boundaries.
Before installing a plugin or approving an authoring tool, record who will fix accessibility defects, how updates are tested and what accessible fallback exists. If the answer depends on a future roadmap with no date, treat that as an operational risk.
Build an Accessibility Audit That Produces Action
An automated score is a useful signal, not a declaration of conformance. Automated tools can identify issues such as missing alternatives, duplicate identifiers and some contrast failures. They cannot reliably decide whether alternative text is meaningful, instructions make sense or an assessment is usable.
Establish a Representative Baseline
Choose courses that cover your real patterns: a content-heavy programme, an assessed course, mobile use, a SCORM or LTI integration and any high-stakes compliance journey. Include common roles such as learner, trainer and manager because permissions can change navigation and controls.
Create an inventory of templates, themes, plugins, file types and external tools. Record each issue with the affected URL or activity, role, browser or app, assistive technology, reproduction steps, severity, owner and target date.
Combine Automated and Human Testing
Run an automated scan across representative pages, then complete the core tasks with a keyboard, resized text and the narrow reflow viewport. Add screen-reader testing by someone who understands the technology. Include disabled users in realistic task testing wherever possible; their experience can reveal barriers that technical checks miss.
Test completion, not just access. A learner may open a quiz but be unable to submit it, receive feedback or record completion. Analytics can help identify unusual abandonment around a particular activity, but they do not identify disability or prove the cause. Use that signal to investigate, not to profile learners.
Prioritise by Learner Impact
Fix blockers first: barriers that prevent sign-in, navigation, submission, feedback or completion. Next address defects that make tasks materially harder, followed by improvements that reduce friction. Preserve an accessible alternative while a complex defect is being remediated.
Retest the original task after every fix and check for regression elsewhere. Close an issue only when the learner journey works, not when a code change has been deployed.
Make Accessibility Part of Moodle Governance
The cheapest accessibility defect is the one a course template prevents. Give authors an approved structure, example components and a short pre-release checklist. Train them to use headings, alternatives, link text, captions and accessible document formats; do not leave these decisions to memory.
Define ownership across the whole service. Course authors own content quality. Administrators own configuration and release controls. Developers own theme and custom-code behaviour. Procurement teams own supplier evidence and contract requirements. Service owners accept residual risk and maintain the improvement plan.
Recheck accessibility after Moodle upgrades, theme changes, plugin updates and substantial content revisions. For UK public sector organisations, current GOV.UK guidance points to WCAG 2.2 AA and requires an accessibility statement, subject to the regulations and applicable exemptions. Other organisations still have duties that depend on their jurisdiction and circumstances, so take legal advice where needed.
When choosing or reviewing an LMS, make accessibility evidence part of procurement rather than a late usability test. Our Moodle, Canvas and Blackboard comparison sets out a practical evaluation approach.
Turn the Checklist Into a Release Gate
For each course release, require a named reviewer to confirm structure, alternatives, captions, documents, keyboard operation, zoom, assessment completion and third-party activities. Keep the evidence with the course version. Sample live courses periodically so later edits do not quietly undo the work.
Moodle gives teams a strong accessible foundation, and Moodle’s accessibility programme provides useful conformance information. The decisive factor is what your organisation builds on top of that foundation. Treat accessibility as an operating practice—designed, tested, owned and improved—not a badge added at launch.
If you need an independent review, request a Moodle accessibility consultation. Swift Learn can audit representative learner journeys, prioritise defects and turn the findings into a practical remediation plan for your course and platform teams.