Step-by-Step WCAG Audits for Existing eLearning Content

Performing a WCAG accessibility audit of your K-12 eLearning materials is an essential strategic step – not just to meet legal mandates, but to ensure inclusive learning for all students. An audit of existing content helps you catch accessibility gaps before they become barriers. For instance, public schools in the US are required to make sure digital content complies with ADA standards (which courts take to mean WCAG 2.0/2.1 Level AA conformance). Similarly, the EU’s Web Accessibility Directive requires WCAG 2.1 AA for learning content, and UK public-sector websites (including those in the education sector) must adhere to WCAG 2.2 AA. Auditing assures compliance worldwide as well because other regions follow these guidelines (for example, the UAE’s Disability Act expressly accepts WCAG 2.1 AA, Australia’s disability law corresponds with WCAG 2.1 AA).

Careful planning and inventory are the first steps in conducting an audit. A combination of automated tools and manual checks are then used to identify problems. A detailed handbook designed for K–12 administrators, IT teams, and content developers can be found below. This procedure compliments our previous article on legal compliance and is similar to our K–12 WCAG Roadmap (so you understand why WCAG AA is important). Key activities, advice, and illustrations of typical issues with school material are included in each of the stages below.

1. Plan the Audit (Define Scope and Goals)

Establish clear objectives and team roles first. Select the platforms and assets you want to audit, such as the school website, LMS courses, PDFs, videos, and applications. Assemble a small audit team and establish a timeframe. This team may include curriculum specialists, teachers, librarians, and IT personnel. Key planning steps include:

  • Gather references and policies. Check state or district accessibility regulations and familiarize yourself with the applicable standards (e.g. WCAG 2.1 Level AA). Tie your audit to these requirements – for instance, the new U.S. DOJ rule explicitly directs K-12 districts to meet WCAG 2.1 AA.
  • Define success criteria. Clarify what “passing” means. Typically this is at least WCAG 2.1 Level AA for most content. (If you are in the UK or EU, plan for WCAG 2.2 or 2.1 AA as required.) Remember that ADA, Section 504/508, EU Directives, and local laws treat WCAG as the benchmark.
  • Identify resources and timeline. Determine how much time and staff can be devoted. Many audits start with an initial inventory and high-level scan, then dive deeper on the worst offenders. (For example, one accessibility provider found 84% of issues only show up in manual review, so schedule time for human testing, not just automated scans.)

Planning upfront ensures your audit is focused and manageable. By linking to standards (e.g. citing ADA/Section 504 or your local law), you align the team on why the audit matters.

2. Inventory Your eLearning Content

Prior to testing, compile a thorough inventory of all digital learning resources. This guarantees that nothing gets overlooked. Your inventory might include:

  • Websites and portals: School/district websites, login portals, student/parent portals.
  • Learning Management Systems (LMS): Canvas, Google Classroom, Moodle, and other platforms’ forums, assignments, tests, and course pages.
  • Documents: Word documents, PowerPoint presentations, PDFs, and e-books used in classrooms.
  • Multimedia: Includes videos (YouTube, Vimeo, etc.), recorded lectures, podcasts, and photographs utilized in materials.
  • Web apps and tools: Any interactive online courses, virtual labs, math/science tools, or publisher material (such as digital curricula or online textbooks).

Keep the inventory organized (a spreadsheet or simple outline). Note the locations (URLs or file paths) and content type (e.g. “PDF Grade 5 Science worksheet”, “video: Algebra lesson – no captions?”, etc.). According to web accessibility audit best practices, creating this roadmap of pages and functions guides the entire process. For each item, note who “owns” it and how often it’s used or updated – this helps prioritize later.

3. Select Your Audit Tools

No single tool finds every issue. Plan to use both automated scanners and manual methods, plus assistive technologies, to cover all bases. Useful tools include:

  • Automated Testing Tools (Scanners): WAVE (Web Accessibility Evaluation Tool) and Axe (by Deque) are popular browser extensions or web-based services. These scan pages and flag many common WCAG issues (missing alt text, color contrast failures, missing ARIA attributes, etc.). They give a quick overview of potential problems. Other options include Accessibility Checker by Equalize Digital or the WCAG evaluation tool by WebAIM.
  • Screen Readers: Programs such as VoiceOver, JAWS, and NVDA simulate how a learner with limited vision or blindness would use content. Use them to manually navigate pages, forms, and documents. If a form field has no label, for example, a screen reader will announce “Edit” with no context, indicating a failure (WCAG 2.4.4/3.3.2).
  • Color Contrast Analyzers: Checkers like the Paciello Group’s or WebAIM’s contrast tool quickly measure text/background contrast ratios. Since low contrast is one of the top accessibility failures, ensure your text meets at least 4.5:1 (WCAG AA).
  • PDF Accessibility Checkers: Tools such as Adobe Acrobat’s Full Check or PAC (PDF Accessibility Checker) help scan documents for missing tags, titles, alt text, etc. (For example, a common PDF problem is missing alt text on images, making content unusable by screen readers.)
  • Manual inspection: A simple test like navigating the website only with the keyboard helps spot problems (unlabeled buttons, complex widgets, broken skip links). Waving hands over a site using browser tools like WAVE or Lighthouse catches many issues, but some (like CAPTCHA unreadability, logical reading order, or unclear link text) only a human can judge.

Weigh the pros and cons of each: automated tools give broad coverage but miss context (they flag ~16% of true issues), while manual testing catches nuanced problems. In practice, use an automated scan first to build a baseline list of obvious errors, then systematically verify and expand with manual checks. (Some teams sequence: automated scan → manual fix verification → end-user testing.)

4. Conduct the Audit (Automated and Manual Checks)

With tools selected, now scan and examine each item in your inventory. A best practice is to do both automated and manual evaluations for every page or resource:

  • Automated Testing: Run your chosen scanners on each webpage or document. They’ll produce reports of identified issues. For example, WAVE might list “Missing form field label” or “Image missing alt text.” Carefully review each result – automated tools sometimes report false positives or miss context. Use them to catch obvious violations of WCAG criteria (perceivable issues like missing alt text, poor contrast, non-descriptive link text; or simple operable issues like empty buttons).
  • Manual Code Inspection: Open key pages and materials in an HTML or editing view. Confirm that your scanned issues (and others) are present. For example:
    • Check that all images have appropriate alt text. Lack of alt or empty alt on meaningful images is a top error. Fix: label as decorative if it is only ornamental, or add descriptive alt text (WCAG 1.1.1).
    • Verify form fields and buttons have labels. Unlabeled fields (e.g. a grade selector or search box without a visible label) prevent screen-reader users from knowing each field’s purpose (WCAG 3.3.2). Fix: ensure <label> tags or aria-label attributes clearly identify each control.
    • Confirm video and audio have captions or transcripts. Captions are frequently absent from narrated slides or lesson videos in K–12 content. This excludes deaf and ESL pupils and is against WCAG 1.2.2 (captions for prerecorded video). Correct captions should be added (either manually or automatically, then modified).
    • Test PDF and document accessibility. Many inaccessible PDFs fail because they lack tags, titles, or table summaries. Use Acrobat to check “accessibility full check” – ensure proper reading order, headings, alt text in PDFs.
    • Check keyboard navigation and focus order. Try tabbing through pages and digital exercises. If focus skips elements or isn’t visible, you’ve found WCAG 2.1.1 (keyboard) or 2.4.7 (focus visible) issues. Fix: Ensure that all interactive elements, including buttons, links, and form fields, have visible focus styles and are accessible.
  • Usability Testing: Whenever feasible, have a staff member or educator with special needs test the material (or observe a screen reader go through it). Their comments can help identify problems that automated testing overlook (such as unclear navigation, unlabeled images that actually include important schematics, or a lack of instructions).
As you test each item, document every issue found: what it is (e.g. “Image on slide 3 missing alt text”), where it is (file name or URL), and which WCAG criterion it violates. Keeping a running log or spreadsheet helps organize later triage.

Key Findings: During audits, the most frequent failures tend to be things like insufficient color contrast, missing alt text, unlabeled form fields, and absent captions. For example, Equalize Digital’s 2024 audits found color contrast issues on over 80% of pages and missing form labels/alt text in the top ten problems. In the UK, studies also highlight inaccessible PDF forms and poor contrast as common barriers. Keep this in mind as you check content – these are high-yield fixes.

Figure: Common accessibility errors in audits (source: accessibility consulting firm Equalize Digital). Key issues include low contrast text, missing form labels, and empty alt text (many of which appear in K–12 materials). (For an accessible version, see the text content above.)

Every issue you find should link back to a specific WCAG 2.1 AA requirement (e.g. “Labeled by instructive text – WCAG 1.1.1”, “Keyboard operable – 2.1.1”, etc.). This lets you prioritize later and ensures nothing is missed.

5. Prioritize and Remediate Issues

After compiling your list of issues, prioritize fixes so the most critical problems get addressed first. Consider:

  • Legal Requirements: Some issues are high stakes because law and policy explicitly require them. For example, by law all videos must have captions (WCAG 1.2.2) and all images must have meaningful alt text (1.1.1). These should be treated as urgent fixes.
  • User Impact: Rate each issue by how severely it impedes learners. A missing heading label in a major math lesson portal affects many students (high priority), whereas a slight misalignment of visual focus style (low contrast focus ring) is less critical (lower priority). The audit data suggests roughly half of identified issues are high severity (44%) while others are medium or low.
  • Ease of Fixing: To quickly increase accessibility, start with simple modifications (such adding captions or alt text). More planning and resources might be needed for more complicated improvements, such rebuilding an entire LMS module or rearranging material.
  • Content Frequency: If the same issue appears across multiple places (e.g. 50 unlabeled “Name” fields in a quiz bank), fix one template or code, then test others.

Make a remediation plan and record your justification for prioritization. A straightforward spreadsheet or report that includes the following information is a popular method: issue description, content impacted, WCAG criterion, priority (High, Medium, or Low), and who is in charge of addressing it. This formalizes the audit outcomes. According to accessibility best practice, you should “prioritize the identified issues based on their severity and potential impact on users” in your report.

Finally, assign remediation tasks to the relevant teams. For example, IT or web developers may fix website code, while teachers or publishers update PDF worksheets and videos. Work collaboratively: share the audit findings with all stakeholders so they understand why the fixes are needed (legal and educational benefits alike). Remember, even partial remediation can have huge benefits. For instance, adding captions and alt text not only meets WCAG AA but also helps English language learners and students with learning differences.

6. Document Findings and Follow Up

A thorough audit report does more than list problems; it shows your compliance status and next steps. When finalizing your report, include:

  • Executive Summary: A brief summary of the audit’s main results, what was examined, and why (for example, “We evaluated all eLearning portals and digital textbooks to meet WCAG 2.1 AA”).
  • Methodology: Note which tools and techniques were used (e.g. WAVE scans, screen-reader walkthroughs, etc.). This helps show due diligence.
  • Detailed Findings: The catalog of issues (who, what, where, which WCAG).
  • Recommendations: Clear action items for each issue, such as “Add alt text to images in File X (WCAG 1.1.1)” or “Ensure video captions for all Science videos (1.2.2)”. Cite relevant WCAG criteria where possible.
  • Next Audit Plan: Accessibility is ongoing. Set a cadence (e.g. quarterly scans, every time a new course is published) and record this as your commitment.

When reporting, highlight the positive outcomes of the audit as well. If some content was already compliant (e.g. “All teacher resource PDFs were found to be properly tagged and language-set”), mention it. And tie back to the big picture: this effort moves your institution closer to legal compliance, and it proactively prevents remediation costs or lawsuits later.

Tip: Turn this process into a checklist or template for future audits. Over time, audits will speed up as your team gains experience.

Common Accessibility Failures in K–12 Content

In the course of an audit, be on the lookout for these frequent problem areas in K–12 eLearning, which often violate WCAG AA:

  • Missing or Incomplete Alt Text: Many educational images (diagrams, historical photos, etc.) lack descriptions. Without alt text, screen readers cannot convey the content.
  • Poor Color Contrast: Light-colored text on similar backgrounds (or busy images behind text) is hard for visually-impaired students. Studies show ~80% of pages fail basic contrast thresholds.
  • Unlabeled Form Fields or Buttons: Online forms (e.g. lunch orders, club sign-ups) often use placeholder text or unlabeled icons. Screen readers report them as just “edit” or “button,” causing confusion. (WCAG requires visible labels or aria-labels on each field.)
  • Video/Audio without Captions/Transcripts: Lessons relying on audio or speech (lectures, podcasts) frequently lack captions. Deaf and hard-of-hearing students, or those learning English, cannot follow. Every video should have synchronized captions by law (WCAG 1.2.2).
  • Inaccessible PDFs and Documents: PDFs are ubiquitous in K–12 (syllabi, worksheets, ebooks). Common failures include missing tags, incorrect heading structure, lack of table headers or summaries, and blank title metadata. These make content unusable by screen readers. (Ensure PDFs are tagged, reading order correct, and images in PDFs also have alt text.)
  • Absent or Broken Skip Links: K–12 websites often have repetitive navigation (e.g. “Back to top”) but forget skip links. This forces keyboard/screen-reader users to slog through menus on every page (WCAG 2.4.1). A properly coded “Skip to main content” link is easy to add and highly effective.
  • Missing Focus Indicators: Younger students or those with motor difficulties need a visible outline on buttons/links when tabbing (WCAG 2.4.7). Custom site themes sometimes remove the default outline, violating this rule.

Catching these during your audit means you can fix the largest barriers first. In fact, remediation of just a few critical issues can dramatically improve access.

Accessibility Audit Tools – Quick Overview

When talking tools, remember:

  • WAVE (WebAIM): A browser-based checker that overlays icons on your site indicating missing alt text, low contrast, heading structure, etc. Easy for beginners to interpret.
  • Axe (Deque): A browser extension (or CLI tool) that reports accessibility failures with references to WCAG. Trusted by developers for its accuracy.
  • Screen Readers (JAWS, NVDA, VoiceOver): These are the gold standard for manual testing. Use them early and often. If a screen-reader user can’t navigate your LMS quiz or complete a form, that’s a major red flag.
  • Color Contrast Analyzers: Tools like WebAIM’s Contrast Checker help spot text that needs darker color pairing.
  • Browser DevTools & Headings Checkers: Chrome DevTools has accessibility audit features; you can also manually review your HTML headings (WCAG 2.4.6 requires logical heading structure).
  • PDF Accessibility Checker (PAC) or Adobe Acrobat: For document checks – these flag untagged content, missing titles, etc.

Use each tool for what it’s best at, and always double-check automated results manually. As one guidance put it, combine “automated scanning with manual evaluation” for the most thorough audit.

Bringing It Together: Legal Compliance and Inclusive Learning

Performing a WCAG audit isn’t just a technical exercise – it’s a compliance and equity initiative. Your organization exhibits good faith effort in accordance with international regulations and laws such as ADA/Section 504 by methodically auditing and correcting information. This can lower legal risk since schools that proactively identify and address accessibility issues are seen more favorably by courts and agencies.

Additionally, every accessibility enhancement helps all students: straightforward navigation lessens uncertainty for users with learning difficulties, alt text increases literacy for all, and captions help ELL students, according to mitrmedia.com. School administrators can better understand the audit as an investment in student success rather than a “tech fix” if they frame it as a component of their district’s larger accessibility plan (as outlined in our K-12 WCAG Roadmap).

In summary, follow these steps to ensure your audit is thorough and actionable:

  1. Plan: Assemble your team, define scope (websites, LMS, docs, videos), and map to WCAG 2.1 AA goals.
  2. Inventory: List all content and platforms (with owners) in a structured way.
  3. Choose Tools: Select appropriate automated scanners and assistive tech (e.g. WAVE, Axe, screen readers).
  4. Test: Run automated scans, then manually review each item for the common failures above. Engage actual users with disabilities if possible.
  5. Prioritize: Rate issues by severity, impact, and legal requirement. High-priority fixes usually include alt text, captions, labels, and contrast.
  6. Document: Compile findings into a clear report that aligns each issue to WCAG AA success criteria and outlines a remediation plan.

By treating WCAG audits as a structured, ongoing process (not a one-off task), K-12 schools can steadily improve accessibility. This not only fulfills legal obligations across the US, EU, UK and beyond, but also supports all students in an inclusive digital learning environment.

Internal Resources: For more on strategy and background, see our Ultimate K-12 WCAG Roadmap and our earlier post “Demystifying Legal WCAG Compliance for K-12 Schools” (which covers U.S. and international legal requirements in detail). These provide the implementation context and compliance rationale that make the steps above even more meaningful.

Sources: Authoritative accessibility guidelines and audits (WCAG 2.1 AA, W3C WAI), education accessibility research, and industry reports were referred to for this article: 

Transform your vision into reality with MITR.

w