From Audit to Action: A Practical Approach to Accessibility in Learning Content

What an Accessibility Audit of Learning Content  Looks Like (And What to Do With the Results)

When people hear “accessibility audit,” they often picture a checklist, a score, or a long report that gets filed away and forgotten. But, that’s not how I approach it. And honestly, that approach doesn’t change anything.

An accessibility audit of learning content should not be a one-time fix or a compliance exercise. It should be a learning process. The goal is not just to identify issues, but to understand why they happen, how they affect learners, and what needs to change in design and development workflows so the same problems don’t keep showing up. This post walks through what that process actually looks like.

Step 1: Define the Scope (Before Anyone Touches the Content)

Before reviewing anything, we define:

• What type of learning content is in scope?
• Do you want to include the Learning Management Systems (LMS) and authoring tools?
• Which standards we’re auditing against (typically WCAG 2.1 or 2.2 at Level AA)
• And whether the goal is compliance, remediation planning, training, or all three.

This step also forces an important conversation that often gets skipped: what success actually looks like after the audit is over.

If the only goal is to fix what’s currently broken, the same issues will show up again in the next course, the next module, or the next redesign. A clear scope helps surface whether the organization is aiming to:

• Reduce risk in the short term
• Build internal understanding of accessibility requirements
• Change how learning content is designed, reviewed, and approved going forward
• Support learners who rely on assistive technology in a consistent, predictable way

Accessibility issues don’t exist in a vacuum. They are almost always the result of design decisions, tool limitations, time pressure, or unclear expectations. When those factors aren’t acknowledged up front, an audit becomes unfocused, the findings feel overwhelming, and the results are harder to act on in any meaningful way. Clarity at the start makes it possible to move from isolated fixes toward more intentional, inclusive learning practices that hold up over time.

Step 2: Manual Review, Not Automated Scanning Alone

Automated tools have a place. They are not the audit. An accessibility audit of learning content requires manual testing, including:

• Keyboard navigation
• Screen reader testing (typically NVDA, VoiceOver, and/or JAWS)
• Visual review for color contrast, structure, and layout
• Interaction testing for things like focus order, modals, accordions, drag-and-drop, and embedded media

Many of the most serious barriers come from interaction failures rather than contrast errors. Learners with disabilities experience being stuck, confused, or unable to proceed. That’s what the audit needs to surface.

Step 3: Identify Patterns, Not Just Individual Errors

We don’t just document individual issues. We look for patterns.

Patterns are what tell you whether you’re dealing with a one-off mistake or a systemic problem. Some of the most common patterns we see include:

• The same interaction type failing keyboard access across multiple modules, often because a specific block, template, or interaction is being reused without testing.
• Instructors relying on visual cues alone (color, position, icons, “click the box on the right”) without text alternatives that work for screen reader or keyboard users.
• Authoring tool features being used in ways that create barriers, even though the tool itself is technically capable of accessible output.
• Headings being styled visually instead of structured semantically, making long pages harder to navigate with assistive technology.
• Images added to support learning but missing context or purpose, resulting in either no alternative text or overly vague descriptions.
• Embedded media that works visually but lacks captions, transcripts, or clear player controls.
  
• GIFs on loop and other moving content that is missing stop, pause, or hide features.

When patterns are identified, the audit shifts from “what needs to be fixed” to “what needs to change in how content is created.” That’s the difference between remediating content and improving the learning experience over time.

Step 4: Document Impact, Not Just WCAG Criteria

Yes, every issue is mapped to WCAG success criteria. That’s required.

But the audit report doesn’t stop there. Each finding explains:

• What the barrier is
• Who it affects (screen reader users, keyboard users, low vision users, cognitive load)
• How it shows up in the learning experience
• Why it matters in the context of learning, not just compliance

This is the difference between a report people read and one they use going forward.

Step 5: Work as a Team, Not a Solo Reviewer

Accessibility audits should not be done in isolation.Depending on the project, the team may include:

• A lead auditor (can be internal or external).
• A screen reader tester
• A document or PDF specialist
• Learning Management System Administrator
• Instructional designers or developers who know the platform
• Stakeholders who understand how the content is used

When teams are involved in the audit process, the results stop feeling abstract and start influencing real decisions.

Step 6: Deliver the Report, Then Talk About It

The audit report is not the end. It’s the starting point. A solid report includes:

• Prioritized findings
• Clear explanations
• Practical recommendations
• Enough detail to support remediation and training

But what matters most is what happens next. We review the findings together. We talk through:

• What can be fixed quickly
• What requires rethinking design choices
• What needs training rather than remediation
• What should change in authoring guidelines, templates, or review processes

This conversation is where the real value shows up.

Step 7: Turn Findings Into Training and Workflow Changes

If an audit only results in fixes, you’ve missed the opportunity.

Recurring issues should lead to:

• Updated design standards
• Better templates
• Clear authoring guidance
• Targeted training for designers, faculty, or content creators
• Testing steps built into the design process, not added at the end

The goal is to make accessible design the default, not the exception.That’s how organizations stop paying for the same problems over and over again.

Why This Matters

Accessibility audits aren’t about pointing out mistakes. They’re about building capacity.

When teams understand:

• Where barriers come from
• How learners experience them
• How design decisions create or prevent issues

They stop relying on audits as a safety net and start designing with accessibility in mind from the beginning. That’s the shift that actually moves the needle. And that’s the kind of audit process worth doing.