When did your LMS last have a real accessibility review?

The public website is the usual starting point for accessibility work: it is visible, easy to scope and easy to point to. But students do not spend most of their digital time on the homepage. They are inside the LMS — opening files, watching lectures, submitting assignments, taking quizzes and checking announcements. That is where a barrier interrupts learning, not just browsing.

The platform is only part of the picture

Open edX, Canvas and Moodle each publish their own accessibility work, and the core platform is rarely the whole problem. Most barriers come from what is loaded into it: course pages built by many different instructors, uploaded documents, embedded video, third-party LTI tools and custom themes. A platform can meet WCAG 2.2 AA on its own and still deliver courses that do not.

What an LMS accessibility review should cover

• Core student tasks — log in, find a course, open materials, submit an assignment, take a quiz — completed keyboard-only and with a screen reader.
• A sample of real courses, not just a demo course built to look clean.
• Uploaded documents and slide decks, checked for tags, reading order and text alternatives.
• Video and audio, checked for accurate captions and transcripts.
• Every LTI tool and embedded third-party integration students are required to use.
• Theme and configuration changes, including color contrast and focus visibility.

Make it repeatable

A one-off review goes stale the next term, when new courses, tools and uploads arrive. Build accessibility checks into course-build templates, give instructors a short pre-launch checklist, and re-test core student tasks after every platform upgrade or new integration.

Next step

If you're not sure when your LMS last had a real accessibility review, that is the answer. Tell us which platform you run and we'll help you scope a review around the tasks students actually do.