Why Your LMS Accessibility Checker Is Not Enough

Most LMSes ship accessibility tooling. Canvas has its built-in Accessibility Checker. Brightspace offers Accessibility+. Anthology Ally layers onto Blackboard, Canvas, Brightspace, and Moodle. If your institution already runs one of these, you might reasonably wonder whether you need anything else.

The short answer: yes, you likely do. These tools vary widely in capability — from in-editor checkers focused on authored content, to platform layers like Ally and Accessibility+ that scan uploaded files and generate alternative formats. Understanding what each catches and what each misses is critical for any institution working toward genuine WCAG 2.1 AA compliance.

What In-Editor Checkers Do Well

The accessibility checker built into the LMS editor — Canvas's Accessibility Checker, Brightspace's in-editor tooling, Blackboard's checker — is designed for content created inside the LMS: HTML pages, discussion posts, announcements, assignment descriptions. For this content, they typically catch:

• Missing alt text on images
• Empty heading tags
• Broken heading hierarchy (jumping from H1 to H3)
• Low color contrast in text
• Missing table headers
• Links with generic text like "click here"

These are real issues, and catching them at the point of creation is valuable. When a faculty member creates a Canvas page and sees an accessibility warning immediately, that is a teachable moment.

What In-Editor Checkers Miss

The limitation is scope. In-editor checkers only analyze content created inside the LMS editor itself. They do not see:

Uploaded Documents

The majority of course content in most universities is not created in the LMS. It is created in Word, PowerPoint, Excel, or LaTeX and then uploaded as files. A PDF with no heading structure, no alt text, and no reading order will upload to Canvas without any warning. The LMS checker never sees inside that file.

PDF Structure

PDF accessibility is a specialized problem. A PDF needs tagged structure (headings, paragraphs, lists, tables), a defined reading order, alternative text for images, and proper language metadata. None of the major LMS platforms perform this level of analysis on uploaded PDFs.

Video and Audio

While some LMS platforms integrate with captioning services, the built-in checker typically does not verify caption quality, accuracy, or synchronization. Auto-generated captions are notorious for errors in technical and discipline-specific vocabulary — exactly the kind of content universities produce.

Scanned Documents

A scanned PDF is essentially an image of text. Without OCR processing, it contains zero accessible content. LMS checkers do not perform OCR or flag scanned documents as inaccessible.

Complex Data Tables

Excel spreadsheets with merged cells, multi-level headers, and color-coded data present accessibility challenges that go far beyond what any LMS checker evaluates.

Platform Layers: Ally and Accessibility+

This is where accessibility platform layers extend coverage significantly. Anthology Ally runs across Blackboard, Canvas, Brightspace, and Moodle. D2L's Accessibility+ launched for Brightspace last year. These tools scan uploaded files, score them for accessibility, generate alternative formats (audio, ePub, tagged PDF), and in the case of Accessibility+, automate a share of common fixes.

If your institution has Ally or Accessibility+ in place, you are well beyond what an in-editor checker alone provides. These are serious tools and they solve real problems.

But there is still a gap. Even with a platform layer running, higher-ed accessibility teams routinely encounter content that needs more than scoring and alternative-format generation:

• Deep source-file remediation. Generating an audio or tagged alternative is different from remediating the original PDF so it meets PDF/UA-1 in its own right — which many procurement contracts, VPATs, and compliance audits now require.
• Complex data tables. Excel spreadsheets with merged cells, multi-level headers, and colour-coded data remain largely manual.
• LaTeX and specialised formats. STEM content often sits outside the scope of general-purpose accessibility tooling.
• Scanned documents without OCR. A scanned PDF is an image of text — zero accessible content. Some tools flag this; few remediate it.
• Institution-wide audit trails. Tracking remediation status across thousands of files for compliance reporting to legal and procurement typically sits outside course-level scoring tools.

The Coverage Gap

Research from WebAIM and similar industry analyses consistently shows that automated tools catch approximately 30 to 40 percent of WCAG violations. The rest requires human judgement, assistive-technology testing, or specialised remediation.

That baseline applies to every automated tool — in-editor checkers, platform layers, and Aelira alike. No single tool catches everything, and no vendor, including us, should claim otherwise.

What changes with a layered approach is the shape of the coverage. An in-editor checker sees authored content. A platform layer like Ally or Accessibility+ extends to uploaded files and alternative formats. Layering further — deeper source-file remediation, complex tables, LaTeX, scanned documents, audit workflows — makes each preceding layer more effective.

A Layered Approach

The most effective accessibility strategy uses multiple tools at different levels:

1. In-editor checker for content authored in the LMS (keep using it — it is still useful)
2. Platform layer (Ally, Accessibility+) for scoring and alternative formats across uploaded files
3. Document remediation for PDF/UA-1 source-file fixes, complex tables, LaTeX, and scanned documents
4. Video captioning with human review for accuracy
5. Web scanner for the university website and web applications
6. Manual review for complex content that automated tools cannot fully evaluate

Each layer catches issues the others miss. No single tool — including Aelira — catches everything. A layered approach gets you dramatically closer to compliance than relying on any single tier.

What to Look For

When evaluating tools to complement what your LMS or platform layer already provides, consider:

• Does it scan the file formats your faculty actually use?
• Can it integrate with your LMS so faculty do not need to leave their workflow?
• Does it remediate the source file, not just score or generate alternatives?
• Can it handle the volume of documents your institution produces?
• Does it provide institution-wide audit trails for compliance reporting?

The goal is not to replace your existing accessibility tooling — it is to fill the gaps each layer was not designed to cover.