An Accessible LMS for Universities: What to Run Alongside Canvas

Every conversation about accessible learning software in higher education starts in the wrong place: with the campus LMS. Canvas, Brightspace, Blackboard and Moodle are entrenched, integrated with the student information system, and supported by teams who have spent years tuning them. No accessibility deadline is going to dislodge them, and it should not — replacing a functioning LMS is one of the most disruptive projects an institution can undertake. But the obligations created by ADA Title II and Section 504 do not stop at the LMS boundary, and a great deal of what a university teaches never touches it. This guide is about that remainder: where the accessibility exposure actually sits, what a second platform is genuinely for, and how to evaluate one without repeating the LMS selection you already did.

Where the accessibility gap actually sits

Map your teaching estate honestly and a pattern appears. The credit-bearing courses in the LMS are the best-governed learning content the institution produces: there is a course design team, a template, a review process and a support desk. The exposure is concentrated everywhere else.

• Non-credit and continuing education. Professional certificates, executive programmes, summer and pre-college. Frequently on a separate commercial platform, bought by the school rather than central IT, with no accessibility review in the purchase.
• Outreach and public-facing courses. Open programmes, community education, open online course content and alumni offerings. Public by definition, and therefore the most likely to attract a complaint.
• Staff and faculty training. Compliance modules, onboarding, and — with pleasing irony — accessibility training itself. Often a slide deck emailed round, with no completion record.
• Departmental micro-sites. A lab, a centre or an institute running its own course pages because the LMS felt too heavy for six lessons.

These share three properties: they are outside central governance, they are visible to people who are not enrolled students, and nobody can currently produce a completion report for them. That combination is precisely what an enforcement conversation probes.

Why the answer is not “replace the LMS”

It is worth being explicit, because vendors are rarely willing to be. A campus LMS does things a lightweight platform does not: SIS integration, registrar-grade rosters and grade books, term and section management, proctoring integrations, retention analytics, and a decade of institutional workflow encoded in it. None of that is an accessibility problem, and none of it is cheap to reproduce.

Canvas in particular has invested seriously in accessibility and publishes its own conformance reporting; the same is true of the other major systems. When a university has an accessibility problem in the LMS, the cause is usually not the platform — it is the content faculty publish inside it: uncaptioned lecture recordings, untagged PDFs, images without alt text, colour-coded assignments. That is a training and workflow problem, and buying different software does not solve it.

So the honest framing for a second platform is narrow: it is for the programmes the LMS was never meant to serve, where you need a public, branded, accessible storefront and a completion record. If a vendor tells you their product replaces Canvas, you are talking to someone who has not sold into higher education.

What a complementary platform has to do

Judged against that narrow job, the requirements are specific:

• Conform, and prove it. WCAG 2.2 AA with a current ACR covering the learner player and the authoring and administrative interfaces, not just the marketing site.
• Make accessible authoring the default. Automatic captions with review, alt-text prompts, heading structure, contrast checking and a pre-publish accessibility check. The platform should make the accessible version the easy version, because that is the only thing that scales across faculty who are not accessibility specialists.
• Sign in with campus identity. SAML 2.0 with your IdP — Shibboleth, Entra ID, Okta or Google Workspace — with InCommon metadata support and just-in-time provisioning. Ideally SCIM so leavers are de-provisioned automatically.
• Link from the LMS. LTI 1.3 launch with grade passback if a programme genuinely needs to appear inside a course; a plain SSO link is sufficient for most non-credit use.
• Report completion by department. The reason to have a system at all for staff training is to answer “who has completed this, by unit, by the due date?” without a spreadsheet.
• Pass the security review. A completed HECVAT, a DPA with a FERPA clause, and a data export you can actually run yourself.
• Let you leave. Full export of courses, learners, enrolments, progress and certificates, self-service. Ask to run it during the trial rather than taking it on trust.

How to evaluate it in an afternoon

You do not need a six-month selection process for a platform in this role. You need an account and a few hours:

1. Unplug the mouse. Sign up, enrol, open a lesson, play a video, take an assessment, submit. Watch for a visible focus indicator throughout and for anywhere focus gets stuck.
2. Turn on a screen reader. VoiceOver on macOS or NVDA on Windows, both free. Are controls labelled and announced? Are headings real headings?
3. Publish something badly on purpose. Upload an image with no alt text and a video with no captions. Does the platform stop you, warn you, or cheerfully publish it? This single test predicts more about your future conformance than any feature list.
4. Zoom to 400%. Content should reflow into one column with no horizontal scrolling and no clipped controls.
5. Read the ACR’s Partially Supports rows and ask for the remediation dates.
6. Run the data export and open the file.

Our LMS accessibility comparison framework turns this into a scoreable rubric if you need to defend the choice in writing, and the buyer’s checklist standardises the vendor conversation.

The integration questions your IT team will ask

Central IT will not be interested in your feature comparison. They will want to know how the thing signs people in, where the data sits and how it is removed. There are five questions, and a vendor who cannot answer them crisply will consume a term of your time.

• Identity. Which SSO protocols, and which identity providers in production today? For a campus this means SAML 2.0 with Shibboleth and InCommon federation metadata, or Entra ID and Okta where the institution has moved to a commercial IdP. Ask specifically about just-in-time provisioning: whether an account is created on first successful sign-in, or whether somebody has to load a spreadsheet first.
• De-provisioning. What happens when a member of staff leaves. SCIM 2.0 is the answer you want, because it removes access automatically from the directory rather than relying on somebody remembering. Without it, your leaver process acquires a manual step that will be skipped.
• Domain and certificates. Whether the service can run on an institutional hostname, what DNS record that requires, and who issues and renews the certificate. A branded subdomain is usually available immediately; a custom domain typically needs one CNAME.
• Email. Which address course notifications are sent from, and whether it can be an institutional sender once SPF and DKIM records are added. This looks trivial until enrolment emails start landing in spam filters during week one.
• Export and deletion. Whether an administrator can export everything — courses, learners, enrolments, progress, certificates — without raising a support ticket, and how a personal-data deletion request is fulfilled. Run the export during the trial. A vendor whose export is a support request has told you something about the renewal negotiation.

None of these is exotic, and all of them are quick when the platform supports them properly: an IdP administrator can usually complete the SSO connection in about two hours. The reason to ask early is that the answers determine whether a pilot takes three weeks or three months, and they are far cheaper to establish before a purchase than after.

Start with one programme, not a platform strategy

The institutions that make progress here do not begin with an enterprise selection. They begin with one department, one programme and a date — typically faculty accessibility training for a single school, because it is small, it is measurable, and it addresses the obligation that is hardest to satisfy any other way.

That gives you a real completion report, a real accessibility review by your own Disability Services colleagues, and evidence for the second conversation. It also surfaces the integration questions — SSO, domain, email sender — at a scale where fixing them is a two-hour job rather than a project. If it does not work, you have lost a term rather than a procurement cycle.

Eduspera is an accessibility-first learning platform built to sit alongside a campus LMS rather than replace it: WCAG 2.2 AA as a product requirement, a published Accessibility Conformance Report, public HECVAT answers, SAML single sign-on with InCommon metadata, SCIM provisioning and LTI 1.3 with grade passback. Institutions can start from the 12-week pilot kit, which sets out the plan, the metrics and the technical checklist your identity and data teams will work through.

Frequently asked questions

Should we replace Canvas with an accessible LMS?

Almost certainly not. The campus LMS handles SIS integration, registrar workflows and term management that a lightweight platform does not, and the major systems publish credible accessibility conformance reporting. Where universities have an accessibility problem inside the LMS, the cause is usually the content faculty publish rather than the platform. A second platform earns its place in the programmes the LMS was never built for.

Do we need LTI 1.3 for this?

Only if a programme has to appear inside an existing course with grades flowing back. For non-credit, outreach and staff training — the common cases — campus single sign-on plus a link is simpler and avoids an integration project. Ask whether LTI 1.3 is available so you are not blocked later, but do not make it a prerequisite for a pilot.

What accessibility evidence should we require from a vendor?

A current Accessibility Conformance Report (VPAT), dated within twelve months, naming the WCAG version and level, with the scope covering learner, authoring and administrative interfaces, and with known gaps disclosed and dated. In higher education, add a completed HECVAT and a DPA containing a FERPA clause.

Who usually pays for a platform like this?

Rarely central IT, at least at first. The budget tends to sit with the unit that owns the obligation or the revenue: the digital accessibility office for faculty training, continuing education for non-credit programmes, or a school running its own professional certificates. Starting there avoids an enterprise procurement for a pilot.

How do we avoid ending up with two systems to maintain?

Scope it deliberately: credit-bearing teaching stays in the LMS, and the second platform covers the programmes outside it. Connect them with campus SSO so there is one identity, and require full data export so consolidation later remains possible. The maintenance cost is real but small when the boundary is clear.