WCAG 1.2.3: Audio Description or Media Alternative Explained

Marcus
wcagaudio descriptionvideo accessibilitymedia alternativeswcag 1 2 3

Marcus · AI Research Engine

Analytical lens: Operational Capacity

Digital accessibility, WCAG, web development

AI-assisted · Source-linked · Editorially reviewed · Methodology

Trust note

This article was drafted with AI assistance, reviewed against accessibility.chat editorial standards, and should be treated as research and education rather than legal advice. We prioritize primary sources and correct material errors.

A diverse group of professionals working together in a contemporary office setting, fostering teamwork and creativity.
Photo by Yan Krukau on Pexels

Most video accessibility conversations jump straight to captions. WCAG 1.2.3 addresses the other half of the equation — what blind and low-vision users need when the visual track carries meaning the audio doesn't. A product demo that shows a cursor moving through a UI without narrating what's happening. A training video where an instructor gestures at a whiteboard and says "this part here." A corporate overview where on-screen text lists key statistics while the voiceover says something else entirely. These are the gaps WCAG 1.2.3 (opens in new window) was written to close.

The Requirement

WCAG Success Criterion 1.2.3 (opens in new window) sits at Level A — the baseline conformance level — under Principle 1 (Perceivable), Guideline 1.2 (Time-based Media). That Level A designation matters: this isn't an enhancement or a best practice. It's a floor.

The criterion gives teams two paths to compliance, and you only need one:

Path 1 — Audio Description: An additional audio track that narrates visual information during natural pauses in the main dialogue. Scene changes, on-screen text, character actions, expressions, anything meaningful that isn't already conveyed by the primary audio.

Path 2 — Media Alternative (Text): A full text document that functions like a screenplay or book — describing all visual content, all non-speech sounds, and providing complete dialogue transcripts, in the same sequence as the video itself. Unlike audio description, this format isn't constrained by dialogue pauses. It can be more complete.

The choice between them is a genuine architectural decision, not just a formatting preference. Audio description keeps users in sync with the video experience. A media alternative offers more comprehensive coverage but removes the user from the synchronized viewing context.

ApproachConstrained by Pauses?SynchronizationCompleteness PotentialSufficient Technique Examples
Audio DescriptionYesHighModerateG78 (opens in new window), G173 (opens in new window), G8 (opens in new window)
Media Alternative (Text)NoLowerHighG69 (opens in new window), G58 (opens in new window), H53 (opens in new window)

Note that WCAG 1.2.5 (Level AA) requires audio description specifically — the media alternative option drops out at that level. If your organization is targeting AA conformance, which is the standard required under 28 CFR Part 35 (opens in new window) for Title II entities and the baseline for most Section 508 (opens in new window) obligations, you'll need to plan for audio description regardless of how you satisfy 1.2.3.

Why This Matters

Blind users and users with low vision don't experience video the way sighted users do. When visual information isn't described, they're working from a partial signal. They hear the dialogue and any ambient sound, but the visual layer — which in most professionally produced video carries substantial informational weight — is simply absent.

This exclusion isn't marginal. Consider a few concrete scenarios:

  • Software tutorials where the narrator says "click here" while the cursor moves across the screen — no description of what was clicked, where, or what changed.
  • Medical or safety videos where visual demonstrations carry critical instructional content that the narration assumes viewers can see.
  • E-learning courses where graphs, charts, and on-screen text appear without being read aloud — and where the course is gated behind a completion requirement.
  • Corporate communications where leadership presentations include slides that are never described verbally.

In each case, a blind user receives a degraded or unusable version of the content. When that content is tied to employment, education, healthcare, or civic participation, the exclusion has real consequences — not just inconvenience.

There's also a cognitive accessibility dimension. Users with certain cognitive or learning disabilities benefit from media alternatives that let them read through content at their own pace, reference specific sections, or process information without the time pressure of synchronized video.

How to Meet It

The sufficient techniques (opens in new window) for 1.2.3 break into two groups:

Media Alternative Techniques

Audio Description Techniques

  • G78 (opens in new window): Provide a second, user-selectable audio track with audio description.
  • G173 (opens in new window): Provide a version of the video with audio description on a separate page.
  • G8 (opens in new window): Provide a movie with extended audio description — pausing the video where necessary to accommodate longer descriptions.
  • SM1, SM2, SM6, SM7: SMIL-based techniques for delivering selectable audio description tracks (relevant for teams using SMIL-capable players).
  • G203 (opens in new window): For videos where the audio track already fully describes the visual content, this technique confirms no additional description is needed.

G203 deserves attention. Many teams don't realize that if a video's existing narration already describes everything visually significant — "I'm now clicking the Save button in the top right corner, and you can see the confirmation dialog appears" — no additional audio description is required. The question is whether the audio track, on its own, conveys all meaningful visual information.

Common Failure Patterns

  • Providing a standard transcript (dialogue only) and calling it a media alternative — it isn't, unless it also describes visual content and non-speech sounds.
  • Embedding video without any link to an alternative, assuming users will find it elsewhere.
  • Producing audio description that only covers some visual elements, not all meaningful ones.
  • Assuming auto-generated captions satisfy this criterion — they address a different requirement (1.2.2) and don't describe visual content at all.

Applying This

From an operational standpoint, 1.2.3 is one of the more resource-intensive Level A requirements to implement at scale. Audio description requires either production-time planning or post-production work. Media alternatives require authoring time. Neither can be fully automated.

Automated tools can flag the absence of an audio description track or a linked alternative, but they cannot evaluate whether the description is accurate, complete, or meaningful. A video with a placeholder audio description file will pass automated checks. A human reviewer — ideally a blind user — is required to assess quality.

Practical Integration Points for Development Teams

Design phase: Establish a video accessibility checklist before production begins. Identify which videos contain meaningful visual content not covered by narration. Plan for audio description or media alternative as part of the production brief, not as a retrofit.

Development phase: Build your video player infrastructure to support a second audio track or a linked media alternative from the start. Retrofitting player architecture later is significantly more expensive. H96 (opens in new window) (advisory) covers using the <track> element for audio description — worth understanding even if not strictly required.

QA phase: Manual review is non-negotiable here. Your QA checklist should include: Does the video have meaningful visual content? Is there an audio description or media alternative? Does the alternative cover all meaningful visual information, non-speech sounds, and dialogue? Is it linked accessibly from the video?

Content management: If your organization publishes video at volume — marketing, training, HR communications — the operational challenge compounds. Consider whether your compliance framework can support a triage model: classify videos by visual information density and prioritize accordingly. A talking-head interview with no on-screen graphics may satisfy 1.2.3 through G203 alone. A product demo almost certainly won't.

For teams building or procuring a video player, verify that the player can expose a second audio track as a selectable option. Many off-the-shelf players don't support this without configuration or custom development.

The Organizational Reality

Through an operational lens, 1.2.3 exposes a structural gap that's common across organizations: video is produced by communications, marketing, or L&D teams who operate outside the accessibility workflow, then handed to development for embedding without any accessibility review built into the handoff. The result is that developers inherit a compliance problem they didn't create and can't fully solve — they can build the player infrastructure, but they can't retroactively add audio description to a video that was never scripted for it.

Closing this gap requires strategic alignment between content production and accessibility requirements before the camera rolls, not after the video ships. That's an organizational process question as much as a technical one. Teams that treat 1.2.3 as a one-time remediation item rather than a production workflow requirement tend to find themselves cycling through the same violations on every new video release.

The strategic case for building audio description and media alternative workflows into video production — rather than retrofitting them — is straightforward: production-time costs are a fraction of post-production remediation costs. Organizations that establish the workflow once can scale it across their entire video library. Leadership buy-in is easier when the ask is "change how we script videos" rather than "go back and fix everything we've already published."

About the Marcus lens

An operational lens on digital accessibility. Frames findings around what implementation and maintenance actually require — WCAG conformance, engineering effort, and day-to-day web development practice.

Marcus is an AI analyst lens, not a human staff member. It helps frame this article through a consistent accessibility perspective.

Specialization: Digital accessibility, WCAG, web development

View all articles using this lens →

Transparency Disclosure

This article was drafted with AI assistance and reviewed against our editorial methodology. We disclose that process so readers can judge the work clearly.