Moodle accessibility checking: when course teams need a scanner
A course team or accessibility lead who must find and fix problems across many courses needs a way to decide where to start. This page covers using the accessibility toolkit in Moodle core to find issues in course content, register and enable it, and turn its reports into remediation work for course authors. The question this section answers is whether your organization needs an automated checker at all, and if so, what it should be expected to do. A scanner earns its place when the volume of content outpaces what people can review by hand. Typical triggers include a large catalog of existing courses, many authors working independently, content carried over from earlier Moodle sites or other systems, and a compliance deadline that requires evidence for each course. Before enabling anything, list the courses in scope, identify who owns each one, and decide whether the first pass covers every course or only the courses with the most learners. Those decisions shape how the reports are used later.
Automated checks are good at finding certain categories of problem consistently across a large set of pages, such as missing structure, some markup issues and content that fails a rule set the toolkit defines. They do not judge whether alternative text describes an image usefully, whether link text makes sense out of context, whether a multi-step activity can be completed with a keyboard, or whether a screen reader user can follow the course. Those judgments need a person. Plan for manual review of a sample of courses and of content types the checker cannot assess, and assign that work to people with accessibility testing experience rather than assuming authors can self-certify. Confirm the exact checks, their coverage and any settings that change them against the documentation for your Moodle version before you commit to a process. Also confirm who can see the reports, because course-level findings may reveal content that is still being drafted. Record which checks are in scope for your reporting so that a later reader can tell what the scan did and did not test. The toolkit output informs remediation, but it does not replace expert accessibility testing or an independent audit. Treat each report as a worklist that prioritizes fixes and gives authors specific locations to correct, then verify the fixes through review. If a regulator, accreditor or customer asks for an assessment of conformance, that assessment comes from qualified testers and, where required, an independent auditor. Ask any implementation partner to state in writing which parts of the work are tool output, which are manual testing and which are outside the engagement.
Which toolkit scope fits which audit goal
This table compares the scope and timing choices an administrator can make when running the accessibility toolkit in Moodle core: a single course, a category, the whole site, and on-demand versus scheduled runs. Read each row for the audit goal it suits, who needs the results and the admin effort it adds. Exact labels vary by installed version, so confirm them on your own site before you plan the rollout.
| Option | Goal it fits | Who needs the results | Admin effort |
|---|---|---|---|
| Single course | Checking one course before launch or after a major rebuild | The course author and the reviewer who signs off the course | Low per run. Confirm the course is in scope and the reviewer has access. |
| Course category | Term-level review of a department's or programme's courses | Category managers and faculty leads who own remediation | Moderate. Report volume grows with course count, so triage needs an owner. |
| Whole site | Site-wide baseline for an accessibility programme or coverage evidence | The accessibility lead and quality or compliance staff, with restricted access | Highest. Plan for large result sets, owner mapping and a remediation queue. |
| On-demand run | Targeted re-check after fixes or before a course opens to learners | The person who started the run and the course author | Low per run. Decide who may start runs to control load and report volume. |
| Scheduled run | Tracking trends across a term or academic year | The accessibility lead, plus authors who need a clear way to see new issues | Higher setup. Name an owner for each run and align the calendar with term dates. |
| Report viewing access | Deciding who can see which results | Administrators, authors and reviewers, each for their own courses | Ongoing role work. Confirm which capability controls report viewing in your version. |
Registering and enabling the toolkit in Moodle
This sequence takes a Moodle site from a confirmed version and staging copy to a working accessibility toolkit, with reviewers granted access and a pilot course whose results update after content changes. Each step closes with a check so the team knows when to move on. Menu paths and capability names can change between releases, so confirm them against the release notes for your site's version before making changes.
Confirm the Moodle version and requirements
The platform team confirms which Moodle version the site runs and compares it with the server requirements in the release notes for the target version. Moodle 5.1 requires 64-bit PHP 8.2 or later and specific database versions, and sites must be on Moodle 4.2.3 or later to upgrade to it. Record the PHP version, database engine and version, web server document root and plugin versions in a short inventory. The step is complete when the inventory matches the release notes, and any gap is raised before the staging copy is built.
Build a staging copy of the site
The platform team clones the production database and moodledata directory into a staging environment that runs the same Moodle version and configuration. Restrict access to staging, disable outgoing email or redirect it, and remove or anonymize learner personal data if testers need a copy. Confirm the environment is reachable only by named staff. The step is complete when a staff login works, a sample course loads, and the Moodle version and plugins match production.
Locate and enable the accessibility toolkit
A Moodle administrator searches site administration for the accessibility toolkit and enables it on staging, then saves the settings page. Menu locations have changed between releases, so confirm the exact path in the release notes for the site's version before searching by hand. Purge caches afterward so new settings and reports load. The step is complete when the toolkit shows as enabled in site administration and its settings page opens without errors.
Grant capabilities to accessibility reviewers
Create a reviewer role, or use an existing one, and assign the capabilities that the toolkit documents for viewing its reports and results. Apply the role at the context where reviewers need access, such as a category or the whole site, and leave course authors out of it unless they need the reports. Use a test account for each role. The step is complete when the reviewer account can open the reports and a test account without the role cannot.
Run a pilot course through the checker
Choose one pilot course that contains typical content: pages, uploaded files, a label with media and at least one activity. Run the accessibility check on that course using the method shown in the documentation for your version. Keep the course small so reviewers can compare each flagged item with its source. The step is complete when results list per item and each flagged item can be traced back to its page, file or activity.
Confirm results display and update
Edit one flagged item in the pilot course, such as alt text on an image or a heading order, then rerun the check. Confirm the item status changes and that unchanged items keep their earlier status. If a result stays stale, purge caches and check again before treating it as a fault. The step is complete when the change appears in the report, and any mismatch is logged with the Moodle version, course ID and steps taken for the next review.
Turning accessibility reports into remediation work for authors
The toolkit's reports only help once someone turns them into work that a named person can finish. Start by sorting results twice: first by course and by the author responsible for that content, then by cause. Content fixes, such as missing alternative text, unclear link wording or heading structures that skip levels, belong to course authors. Site configuration issues, such as theme colour choices, filter settings that change rendered output, or upload defaults that allow untagged PDFs, belong to the administrator or accessibility lead and should be fixed once for every course that inherits them. Mixing these two streams is a common reason a backlog stalls, because authors cannot close items the site controls.
Set a review cadence that matches your academic calendar. A short fortnightly triage for the admin team and a monthly review with department leads is one common pattern, but confirm the rhythm against your own term dates and staffing. Give every item a state that can be reported: open, assigned, fixed, accepted with a recorded reason, or not applicable. Track closure by re-running the check on the edited course and recording the result, so that a fixed item is confirmed by evidence and not only by the author's note.
Duplicate tickets usually appear in two situations: the same problem recurs across many activities in one course, or a course copied from a template carries the same issue into every new term. Group items by issue type and location, and check for an open item before creating a new one. Where a template causes the problem, fix the template and record one site-level item that lists the affected courses. This keeps the author queue short and makes the cause visible to the people who can remove it.
Authors need to see only what they can act on: the course and section, the activity or resource, the failed check explained in plain language, and a short fix in the editor they use. A raw export full of rule codes will be ignored. Confirm in your version which views and exports the toolkit provides, and whether authors can open reports themselves or only receive extracts from you. Whichever route you choose, record who received each extract and when, so the status of every item can be explained later.
Some findings need a person. A checker can confirm that an image has alternative text but cannot judge whether that text conveys what the image contributes, or whether a decorative image has been described when it should not be. Other manual checks include whether link text makes sense out of context, whether the reading order of a PDF follows the meaning of the page, whether captions match the spoken content, and whether a table is used for layout. Assign these to reviewers who know the subject, sample courses each term, and record accepted decisions so the same judgment is not raised again. Do not close these items on the tool's pass result alone.
Permissions, learner data and logs to review before rollout
The toolkit reads course content and reports on it, so access to it is a data decision as well as a configuration task. The cards below cover who can run and view checks, what appears in reports, how staff access is limited, and how logs and retention are reviewed. The institution's privacy and security teams should sign off on each item before rollout.
Who can enable and run checks
Enabling the toolkit and starting accessibility checks are administrative and teaching actions, so each should map to a named Moodle role. Review which roles hold the capabilities for running checks at site, category and course level, and whether course creators, teachers or managers receive them by default. Confirm the capability names in the documentation for your Moodle version, then test each role on a non-production course before any staff account receives access.
Who can view reports
Reports list findings against specific courses, activities and resources, so the people who can open them decide who learns about unresolved issues. Check whether report viewing is granted at site, category or course level, and whether a course author can see findings for courses they are not assigned to. Record the intended audience in writing, such as accessibility leads or course designers, and compare it with the role assignments on the live site.
Course content and user-linked data in reports
Reports draw on course material such as page text, file names, activity titles and links. Depending on the toolkit version, they may also carry user-linked details such as author or modification context. Ask your vendor or a test instance exactly which fields appear on screen and in any export. Learner submissions and profile fields should be confirmed as excluded, or the privacy team should decide whether that exposure is acceptable.
Restricting report access to staff
Staff-only access depends on both role assignments and every route into the reports. Confirm that students and guest users cannot reach report pages, exports or cached files through direct URLs, and that exported spreadsheets are kept in staff-only storage. Test with a student account, a guest session and a logged-out browser. Check that the same restriction applies to any mobile app or web service access enabled on the site.
Logs generated by checks and views
Running checks and opening reports can create entries in Moodle's logs, and those entries record who acted and when. Review which events are written to the standard log store, which of them an external system may collect, and who can read those records. Confirm the event list for your version, then decide whether accessibility activity needs its own review path within your log access policy.
Retention settings for logs and reports
Retention determines how long log records and exported reports remain available, and it should match the institution's records schedule. Check the log retention setting in site administration, the backup retention for courses that contain reports or cached data, and the process for deleting exported files. Ask the privacy team to set each period in writing and to confirm who approves deletion requests.
Questions teams ask before running Moodle accessibility checks
How much effort does a first accessibility scan and remediation cycle take in Moodle?
The effort depends mostly on how much course content exists and how many people must act on the results, so no single figure applies across institutions. Scan time is usually the smallest part. The larger share goes to triage: someone has to read each report, separate genuine barriers from false positives, decide which fixes belong to the course author and which to a central team, and check that each fix works. The main drivers are the number of courses in scope, the content types involved (plain pages, uploaded PDFs, H5P activities, video and embedded third-party content each need different checks), the number of authors, and how many hours your accessibility lead can give to triage. Ask any partner for an estimate built from a sample of your own courses, with the assumptions written out.
Can our internal team run the Brickfield toolkit without outside help?
Often, yes, provided you have someone who administers Moodle and someone who can judge accessibility findings. Enabling and configuring the toolkit is an administrator task inside Moodle, and its reports are meant to be read by course authors. The harder work is interpreting results against your own accessibility standard, writing guidance authors can follow, and deciding how findings are tracked and closed. Teams without in-house accessibility expertise often find triage the hardest part. Confirm in the documentation for your Moodle version how the toolkit is registered and enabled, and test on a copy before changing live courses. An outside partner can take on any of these steps under a written scope.
How long does a pilot of Moodle accessibility checking take to design?
Design time depends on the scope you agree, and no standard duration applies. A useful pilot is defined by a small, representative set of courses, a named group of reviewers, an accessibility standard to measure against, and a written statement of what success looks like. Design work usually covers choosing courses that include the content types you actually use, confirming that the staging environment is close enough to production for the results to be trusted, and agreeing how findings reach authors. The more courses and content types you include, the longer both design and review take. Ask for the pilot plan in writing, with its inputs and checkpoints, before committing to the full project.
What does our institution need to provide for an accessibility checking project?
The project needs access to a staging copy of Moodle that holds representative courses, administrator rights to enable and configure the toolkit there, and named people on each side. In practice that means a staging copy refreshed from production on a schedule you choose, a Moodle administrator to make changes, one or more accessibility reviewers who can decide on findings, and course author contacts who will fix content and confirm changes. Course backups or an inventory of content types help define the scope. Agree in advance how quickly reviewers will respond. Delays in any of these areas usually slow the project more than the technical setup does.
What does a fixed-scope accessibility engagement from DeployOpen cover?
A fixed-scope engagement covers the work set out in a written scope agreed before work starts, with deliverables and timelines attached. For Moodle accessibility checking, that can include enabling and configuring the toolkit on a copy you provide, documenting the setup, running and reviewing scans on agreed courses, turning findings into remediation tasks for authors, and handing over reports and guidance your team can reuse. The scope should also state exclusions, such as remediating every course in your catalog. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications. Quotes follow from the written scope, so the scope is where cost is set.
What breaks when the accessibility toolkit runs on a large Moodle site?
The common failures are operational: long-running jobs competing with other site tasks, scans run against a staging copy that no longer matches production, and reports that nobody owns. Check the scheduled task and cron setup on your server before the first large run, and confirm how scans behave at your database and file storage sizes. Courses with heavy embedded media or many files tend to slow processing. Keep a log of which courses were scanned, when, and on which Moodle version, so results can be compared after upgrades. Test the full path, from scan to author task, on a few courses before scaling up. Confirm these behaviors against the Moodle documentation for your version and your own environment.
How do we keep accessibility checks running after each Moodle upgrade?
Treat the toolkit as part of your upgrade checklist, because each Moodle release can change core behavior the toolkit depends on. Before upgrading, record the current toolkit configuration, run a scan on a staging copy of the target version, and compare the results with your previous baseline. Moodle publishes major releases every six months and point releases in between, so the cadence should shape who owns the work. Assign one person to review release notes for changes affecting reports, courses or plugins. Confirm the toolkit's compatibility with your target release in the Moodle documentation before scheduling the upgrade. Ongoing support, upgrades and continuous testing are available as retainers, which may suit teams without a dedicated owner.
How DeployOpen scopes and delivers Moodle accessibility checking
DeployOpen scopes Moodle accessibility checking with the Brickfield toolkit as a fixed-scope piece of work agreed in writing before anything is installed. We enable and configure the toolkit in your self-hosted Moodle, then turn its findings into remediation work course authors can act on, and document how it runs. Ongoing support is available as a retainer.
How we scope
- The written scope names the Moodle version, hosting environment and course areas the toolkit will check.
- It states which accessibility checks run, who reviews results and which courses are excluded from the first pass.
- Scope also covers the remediation workflow, reporting format and the handover deliverables agreed with your team.
How we build
- We confirm the Moodle version and its toolkit availability on your site before enabling anything in production.
- We register and enable the accessibility toolkit in a staging copy of your course content and review its output.
- We check findings against a sample of courses with your accessibility lead before settings move to the live site.
How we hand over
- Deliverables include the configured settings record, a run procedure and a remediation guide for course authors.
- Remediation tickets are grouped by course owner, with the issue, location in the course and the fix described.
- Your administrators receive a walkthrough of the reports, so they can rerun checks without us.
How we support
- Ongoing support can run as a retainer covering upgrades, updates and repeat accessibility checks on new course content.
- Before each Moodle upgrade, the toolkit is planned for re-testing on a copy of your site.
- Accessibility checks support evidence for compliance reviews, but audit reports and certifications come from independent assessors.
