Is Your E-Learning Tool Accessible? Here’s How to Find Out

Beyond the VPAT: How to Truly Evaluate Accessibility in E-Learning Tools

When we think about accessible e-Learning, we often focus on our content, such as alt text, keyboard access, transcript availability. But what about the platforms and tools we use to deliver that content? How do we know if those are accessible?

The answer: it takes more than hope and a VPAT.

Start with the VPAT (but don’t stop there)

A VPAT (Voluntary Product Accessibility Template) is a document vendors provide to report on how their product meets accessibility standards like WCAG 2.1 AA. It’s a helpful starting point. It gives you insight into what the vendor claims their product can do.

But here’s the thing: a VPAT isn’t a guarantee. It’s self-reported. Some are thorough and honest. Others... not so much.

So, if you're serious about accessibility (and you should be), you need to do your own testing.

Not sure where to begin? The W3C’s Evaluating Web Accessibility Overview is a fantastic starting point. It outlines how to conduct structured checks, from quick preliminary reviews to full conformance evaluations. It’s also vendor-neutral and standards-based. 

Test the Way Real Users Navigate

To truly understand if your e-Learning tool is accessible, put yourself in the shoes of your learners who use assistive technologies. That means:

• Testing with a screen reader (NVDA and VoiceOver are good options)
• Navigating via keyboard only (no mouse!)
• Using high contrast and zoom settings
• Trying different screen sizes and orientations

And then, take a look under the hood. This is where WCAG helps you pinpoint the actual issues.

A Real-Life Audit Example: Storyline + WCAG 2.2 Success Criterion 1.3.1

Here’s a nugget from a recent audit I did on an Articulate Storyline course. We were checking for WCAG 2.2 Success Criterion 1.3.1: Info and Relationships.

What the guideline says: Make sure information, structure, and relationships conveyed visually are also available to assistive tech (like screen readers).

In Storyline, we found three navigation components that weren’t labeled properly for screen readers:

• Primary Navigation: It was unnamed. That means a screen reader user might not even know it exists.
• Slide Navigation: It was labeled “Slide Navigation,” which sounds fine, but in practice it confused users who didn’t know if that meant slide controls or the actual content of the slide.
• Menu Tab Panel: It had a generic name like “outline-container.” Totally unhelpful.

Severity Level: Critical. Why? Because users couldn’t understand or access key parts of the interface using a screen reader. That’s a huge barrier.

The Fix

We recommended renaming components with clear, descriptive labels:

• Primary Navigation → “Primary”
• Slide Navigation → “Slide Controls”
• Menu Tab Panel → “Outline Menu”

These changes might seem small, but they make a world of difference for someone using a screen reader.

The Takeaway

Accessibility isn’t just about your content, it’s also about your tools. 

Don’t assume a VPAT is the end of the story. Do your own testing, ask tough questions, and advocate for your users. If you’re using an e-Learning authoring tool, test it the same way your learners will experience it. Accessibility isn’t optional.

Need Help Making Your E-Learning Accessible?

Accessibility doesn’t have to be overwhelming, and you don’t have to figure it out alone.

If you're unsure whether your tools or courses meet WCAG 2.2 standards, reach out today. I offer accessibility audits, hands-on training, and a practical accessibility course to help you build content that works for everyone.

Contact me to get started or join the course here.