What makes eLearning accessible?

Who this answer is for

This answer is written for the person who has been handed a course and asked whether it is accessible, and who needs a defensible answer rather than a feeling. That is usually one of four people: an L&D manager writing an accessibility clause into a vendor statement of work; an instructional designer building in Storyline, Rise, Captivate or Lectora who wants to design correctly the first time; a compliance or procurement lead comparing supplier claims; or a developer inheriting a library of legacy modules with no idea which ones are safe to publish.

It is a definition-level answer. It does not assume you have run an audit before, and it does not assume you can read a specification end to end. What it assumes is that you need to know which parts of a course are load-bearing for accessibility, because those are the parts that decide the outcome.

Why the answer changes by context

“Accessible” is not one bar. Four variables move it.

The standard you are held to. This is established fact, not opinion. The Web Content Accessibility Guidelines (WCAG) 2.2 is a W3C Recommendation and is the current reference version. Section 508 of the Rehabilitation Act, as revised by the 2017 ICT refresh, incorporates WCAG 2.0 Level A and AA. The European standard EN 301 549 incorporates WCAG criteria by reference for ICT procurement. In the United States, the Department of Justice’s 2024 final rule under Title II of the Americans with Disabilities Act adopts WCAG 2.1 Level AA for state and local government web content and mobile apps, with compliance dates staggered by entity size. Read whichever instrument actually binds your contract; do not assume they all point at the same version.

What the course is made of. A linear, text-and-narration module has a small and fairly predictable set of failure points. A branching simulation with drag-and-drop, a custom player skin and a timed final assessment has several times more, and they interact with each other. That comparison is a qualitative judgment about relative complexity, not a counted figure. The construct drives the criterion.

Who owns each layer. A course can conform while the platform it launches from does not. The learner does not experience the split. Establish early whether you are being asked about the course package, the LMS, or the whole path from login to certificate.

Whether real assistive technology is in scope. Automated checkers find contrast, missing alt text and some structure problems. They do not find a drag-and-drop that is technically keyboard-operable but incomprehensible when read aloud in sequence. Professional judgment: automated tooling is necessary and never sufficient.

The eLearning Break-Point Map: seven constructs, and the WCAG 2.2 criteria they actually fail

Generic accessibility checklists are organized by WCAG principle. That ordering is correct for auditors and close to useless for course builders, because it does not tell you where to look. This map is organized the other way round: by the eLearning construct on your slide, then the criterion it breaks, then the fix. Criteria are named with their conformance level in brackets.

1. Narration, video and captions

2. Drag-and-drop and pointer-dependent interactions

Where you are building a control yourself rather than using a component the authoring tool ships, the WAI-ARIA Authoring Practices Guide published by the W3C Web Accessibility Initiative documents the expected keyboard behavior and the name, role and state exposure for common interaction patterns. Use its patterns as the reference for the 4.1.2 fixes above and in the player section below, rather than inventing an interaction model and then trying to label it after the fact.

3. Timed knowledge checks and auto-advance

4. Custom players and navigation chrome

5. Color-coded feedback and status

6. PDF job aids and downloads

Professional judgment: for a job aid that must work at a workstation, on a phone and in print, an HTML page with a print stylesheet is usually a more durable answer than a tagged PDF. See the related discussion of what actually has to change when slide decks become digital learning.

7. LMS chrome and the launch path

The launch path is where ownership gets contested. Ask the platform vendor for an Accessibility Conformance Report based on the VPAT template published by ITI, and read the “partially supports” rows rather than the summary.

Step by step: running the review

1. Fix the target. Write down the standard, version and level in one sentence — for example, “WCAG 2.2 Level AA, course package and LMS launch path.” Everything downstream depends on this.
2. Inventory the constructs. Walk the course and tick which of the seven break points appear. This takes minutes and tells you how large the review is.
3. Run automated checks. Contrast, alt text, document structure, PDF tagging. Treat the output as a starting list.
4. Run a keyboard-only pass. Unplug the mouse. Complete the entire course, including every interaction and the final assessment.
5. Run a screen reader pass on the interactive slides only. Full narration of a linear course is rarely the best use of time; the interactions are where meaning is lost.
6. Triage and log. Record each finding as construct, criterion, level, learner impact and fix owner. A finding without a named criterion cannot be argued in a procurement conversation.

Planning heuristic, not measured data: for a 30 to 45 minute module with several interactions, budget roughly half a day for steps 2 to 6 and a further half to two days for remediation, depending on how much of the problem sits in the shared template rather than in individual slides. Template-level defects are cheaper per course and more expensive to discover late, which is why accessibility belongs in the storyboard rather than in a final QA pass. That is also why accessibility work should appear in your development schedule as a named activity rather than as contingency.

A worked example

The following scenario is hypothetical and constructed to illustrate the method. It does not describe any real organization or project.

Imagine a 35-minute lockout/tagout refresher, rebuilt from a slide deck. It has narration on every slide, one drag-and-drop sequencing activity, a five-question check with a 60-second timer, a branded player, green and red feedback, and a downloadable one-page procedure card.

Applying the map produces a predictable finding set. The narration duplicates on-screen text on most slides but describes an animation on three of them, so captions are needed throughout (1.2.2) and those three slides need their visual content written into the script (1.2.3). The sequencing activity is drag-only, so it needs a select-then-place alternative (2.5.7) and a keyboard route (2.1.1). The 60-second timer is not essential to the validity of a refresher check, so it comes out (2.2.1). The player’s custom icons need names (4.1.2) and a restored focus ring (2.4.7). Feedback gains a word and an icon alongside the color (1.4.1). The procedure card is republished as a tagged document with a real heading structure (1.3.1).

Sort that set by where the work actually lands and the shape of the job becomes clear. The player labels, the focus ring, the feedback styling and the captions workflow are template and publish-settings changes: fix them once and every course built from the same shell inherits the fix. Three items need individual slide rework — the three animation slides, the sequencing interaction and the timed check. One item, the procedure card, is neither of those: it is a separate asset that has to be rebuilt in its own tool and re-attached. That three-way split between template, slide and separate asset, rather than any particular count, is the point of reviewing by construct — it tells you which findings scale across a library and which do not. The quantities in this scenario are illustrative, because the scenario is constructed.

Common mistakes

• Treating the automated score as the verdict. A course can pass every automated check and still be unusable by keyboard.
• Adding alt text to everything. Verbose descriptions of decorative shapes make courses worse, not better.
• Auto-captions shipped unedited. Professional judgment: domain vocabulary — safety, clinical and regulatory terms — is where automatic captioning is least reliable, and it is also where a mis-transcription changes the instruction.
• Assuming an authoring tool’s accessibility claim covers your build. Tools provide capable components; you can still misuse them.
• Reviewing the course but never the launch path. Learners fail at login before they reach your conforming module.
• Claiming the “essential” exception for timers because the sponsor likes timers. The exception exists for cases where timing is intrinsic to what is being measured.
• Leaving PDFs out of scope. Attached job aids are part of the learning product.
• Running the review after sign-off. Late findings usually sit in the template, where the cost of change is highest.

Decision table: how to triage what you find

Note what these classes deliberately do not do: they do not track conformance level. A Level A caption failure on a narrated slide is usually Major, because a learner can still reach the end of the course, while a Level AA drag-only interaction is a Blocker, because a keyboard user cannot. Severity here is defined by task completability and loss of meaning, not by the letter after the criterion number. Run your findings log through the four tests in order and the release decision falls out of it. The classes and their thresholds are an original construct offered as professional judgment; they are not drawn from any standard or published methodology.

If you need this run independently, an accessible learning review covers the same ground — keyboard and navigation, focus and interaction, contrast and visual treatment, text, headings, labels and links, captions and transcripts, images and alternative text, and responsive behavior — and returns remediation priorities. It supports improvement and alignment with an agreed standard; it is not a legal certification. Related discovery work — establishing which learners, devices and assistive technologies are actually in scope — belongs with the questions you put to subject-matter experts and stakeholders before building. Further material sits on the learning accessibility topic hub.

Sources and review note

Editorial owner: IETERNUS Learning Systems. Last reviewed: 8 August 2026.

Established fact. The success criteria named above, their numbers and their conformance levels are defined in WCAG 2.2, a W3C Recommendation; 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 2.4.11 Focus Not Obscured (Minimum), 3.2.6 Consistent Help, 3.3.7 Redundant Entry and 3.3.8 Accessible Authentication (Minimum) are additions introduced in version 2.2. The regulatory positions described — Section 508 of the Rehabilitation Act as revised in 2017, EN 301 549, and the 2024 ADA Title II final rule — are matters of public record; verify the version and compliance dates that apply to your organization against the source instruments.

Professional judgment. The grouping of criteria by eLearning construct, the four triage classes and their thresholds, the sequencing of the six review steps, the decision to run a full keyboard pass but a screen reader pass on interactive slides only, the effort ranges, the relative-complexity comparison between linear and branching modules, the claim that sponsors tend to read the “essential” timing exception too broadly, the advice about how vendor conformance reports are typically written, and the recommendation to prefer HTML job aids over PDFs are all practitioner judgment offered as planning heuristics. They are not measurements and not part of any standard. The assignment of a specific failure mode to a specific success criterion is also interpretive: a formal audit can reach a different determination on the same implementation.

Assumption to test in your own context. This article assumes desktop and tablet delivery through an LMS with a conventional authoring tool. Mobile-first delivery, VR, and simulation environments introduce criteria and constraints not covered here.

Sources cited by name: Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation; WAI-ARIA Authoring Practices Guide, W3C Web Accessibility Initiative; Section 508 of the Rehabilitation Act (ICT Refresh, U.S. Access Board); EN 301 549, European accessibility requirements for ICT products and services; ADA Title II web and mobile accessibility final rule, U.S. Department of Justice, 2024; PDF/UA, ISO 14289; Voluntary Product Accessibility Template (VPAT), ITI.

Learning topic: Learning Accessibility