Resources

WCAG Fix It Guide: 1.2.3 Audio Description or Media Alternative (Prerecorded)

 

Table of Contents


Free Audit

What Is WCAG 1.2.3?

You have a video on your site. It has a voiceover or dialogue — but a lot of what matters is visual. Someone assembling a product. A speaker using gestures to make a point. A graph that changes on screen while someone narrates something unrelated.

WCAG 1.2.3 says that for any prerecorded video with an audio track, blind users need a way to access the visual information they cannot see. You can do this two ways: add audio description to the video, or provide a full text transcript that also describes the visual content.

This is a Level A requirement — the baseline. Level AA tightens this further under 1.2.5, which requires audio description specifically. But at Level A, you have a choice.

FieldDetails
WCAG Criterion1.2.3
Conformance LevelLevel A
PrinciplePerceivable
WCAG Version2.1
Official Referencehttps://www.w3.org/WAI/WCAG21/Understanding/1-2-3

The Concept in Plain Terms

Audio description is an extra narration track added to a video. It plays during natural pauses in the dialogue and describes what is happening visually — who is on screen, what they are doing, what appears on screen, what changes.

The media alternative is a written document that covers everything: what was said, and what was shown. Not a summary — a complete equivalent. Someone reading it should finish with the same understanding as someone who watched and listened to the full video.

Both approaches are valid under 1.2.3. Most organisations find the media alternative easier to produce, especially if they already have a script or transcript for the video.

Who Does This Actually Affect?

Primarily blind and low-vision users who rely on screen readers or audio output. But also:

  • Anyone who cannot watch the video — they can still access the full content through a text alternative
  • Search engines — a full media alternative makes video content indexable
  • People who prefer reading to watching
  • People using assistive technology that handles text better than video

Video content is increasingly central to how organisations communicate. If a significant portion of what you are communicating lives in the visuals, text-only users miss it entirely without this provision.

Common Failures

Relying on captions alone

Captions transcribe the spoken audio. They do not describe what is happening visually. A user reading captions still has no idea what is on screen if it is not narrated. Captions satisfy 1.2.2 but do not satisfy 1.2.3.

Providing a transcript that only covers the dialogue

A transcript that captures what was said but not what was shown is not a media alternative. If someone presents a graph on screen and the narration says ‘as you can see here’, the transcript needs to describe what that graph shows.

Audio description exists but is a separate hard-to-find link

If you do provide audio description or a media alternative, it needs to be findable. A link that is buried or mislabelled does not meet the intent of this criterion.

How to Fix It

Option 1: Add audio description

  1. Identify all moments in the video where visual information is not covered by the existing audio
  2. Write description scripts for those moments — aim to fit them in natural pauses in the dialogue
  3. Record the descriptions and mix them with the existing audio track
  4. Offer the audio-described version clearly alongside the original

Option 2: Write a full media alternative

  1. Start with a complete transcript of everything spoken in the video
  2. Add descriptions of all visual content that is not described in the audio — what is on screen, what happens, in sequence
  3. Label it clearly as a media alternative and link to it close to the video

For most teams, option 2 is more practical. If you already have a production script, this is mostly an editing task.

Remember: At Level AA you will also need to satisfy 1.2.5, which requires audio description specifically. If you are targeting AA compliance — which most legal frameworks require — plan for audio description from the start rather than working backwards from a text alternative.

Edge Cases Worth Knowing

  • Dialogue already covers the visuals: If the narration describes everything that appears on screen, no additional audio description is technically required. But be honest — if someone narrates ‘click the blue button’ and the screen shows which button that is, a blind user still cannot follow.
  • All the information is in the audio: If the video is essentially a talking head with no meaningful visual information, 1.2.3 may be satisfied by captions plus the fact that nothing visually significant happens. Assess this honestly.
  • Extended audio description: If the natural pauses in the video are not long enough for adequate description, you may need to pause the video to allow description. This is covered under 1.2.7 at Level AAA.

How to Test for 1.2.3

  1. Identify all prerecorded videos on the page that have an audio track
  2. Watch the video with the screen muted — what information is only communicated visually?
  3. Check whether audio description or a media alternative is provided
  4. If a media alternative: read it and assess whether it covers all visual information, not just the dialogue
  5. If audio description: check that the descriptions are accurate and placed where they do not obscure meaningful dialogue

Why This Matters Beyond a Checkbox

This criterion sits at the heart of what video accessibility is about. Video is one of the richest formats on the web — but also one of the most exclusionary if it’s only built for people who can see and hear it simultaneously.

A good media alternative is also just good documentation. It gives your content a second life in searchable, translatable, skimmable text. Teams that do this well do not just tick a box — they make their content genuinely more useful.

Quick Fix Checklist

  • All prerecorded video with audio has audio description OR a media alternative
  • Media alternatives cover both what was said and what was shown — they are full equivalents
  • Audio descriptions are accurate, timed appropriately, and do not overlap important dialogue
  • Alternatives are clearly labelled and linked near the video
  • You have a plan for meeting 1.2.5 (Level AA audio description) if targeting full AA compliance

Frequently Asked Questions

Is 1.2.3 the same as 1.2.5?

No. 1.2.3 is Level A and gives you a choice: audio description or a full media alternative. 1.2.5 is Level AA and requires audio description specifically — no text alternative option. Most regulatory frameworks require Level AA, so you will typically need to meet 1.2.5 as well.

What counts as ‘significant’ visual information?

Anything that communicates meaning a blind user would need to understand the content. If the visual exists only for aesthetic reasons and adds nothing to the information being conveyed, it may not need describing. Everything else does.

Does this apply to videos embedded from YouTube or Vimeo?

Yes. The criterion applies to the content, not who hosts it. If you embed a video on your site, you are responsible for providing the alternative — even if the video is hosted elsewhere.

Can AI-generated audio descriptions be used?

AI tools can help draft descriptions, but they need human review for accuracy. An incorrect audio description is worse than none — it actively misleads. Treat AI output as a starting draft, not a finished product.

Related Content

WCAG Fix It Guide: 1.2.1 Audio-only and Video-only (Prerecorded)

What Is WCAG 1.2.1? If your website has a podcast clip, a voicemail recording, or a silent video showing a process, this criterion is talking to you. WCAG 1.2.1 says that if you have audio-only or video-only prerecorded content, you need to provide an alternative. Not a vague summary — an actual equivalent that gives

Read more: WCAG Fix It Guide: 1.2.1 Audio-only and Video-only (Prerecorded)

WCAG Fix It: 4.1.2 Name, Role, Value

If your website has buttons, forms, menus, dropdowns, or interactive components, WCAG 4.1.2 applies to you. In this WCAG Fix It guide, we’re breaking down one of the most technical-sounding, yet critically important accessibility requirements: ensuring that interactive elements have a proper, programmatically defined name, role, and value. It sounds developer-heavy burut at its core,

Read more: WCAG Fix It: 4.1.2 Name, Role, Value

WCAG Fix It: 3.2.2 On Input

In this WCAG Fix It guide, we’re looking at a common usability issue: unexpected changes that occur when a user enters information into a field. When users interact with form controls, they expect the page to remain stable, but sometimes websites trigger automatic actions such as submitting a form, redirecting to a new page, or

Read more: WCAG Fix It: 3.2.2 On Input