Audio element has no caption track

What is this issue?

An <audio> element plays prerecorded content that conveys real information through speech (an interview, a podcast episode, a voice-recorded announcement) with no accompanying text transcript published anywhere near it. Unlike video, audio has no visual track at all, so there’s no “caption” to time against pictures; the only accessible equivalent is a standalone transcript covering everything spoken.

This applies to prerecorded audio specifically. Live audio streams fall under a separate, related WCAG requirement with different practical constraints, since a transcript can’t be prepared in advance for content that hasn’t happened yet.

Why does this matter?

Deaf and hard-of-hearing users get nothing from an audio player by itself: no partial signal, no visual fallback, just a control that plays sound they can’t perceive. Without a transcript, whatever information the audio conveys simply doesn’t exist for them, the same way an untranslated foreign-language page doesn’t exist for someone who can’t read it.

A company publishing weekly leadership updates as an audio-only recording, with no transcript, effectively excludes every deaf or hard-of-hearing employee from information their hearing colleagues receive routinely. This isn’t a degraded experience; it’s a complete absence of the content for one specific group of employees, delivered through a channel that structurally cannot include them without a text alternative.

Who is affected?

• Deaf and hard-of-hearing users: get no information at all from an audio-only element with no transcript. There is no partial or degraded audio experience possible for someone who cannot hear the recording; the content is either fully available through text or not available at all.
• Cognitive disabilities: users who process written information more reliably than spoken audio, including people with certain attention or auditory-processing differences, benefit from a transcript as a more reliable way to absorb the same content, independent of hearing ability.

What users experience

Owen is deaf and relies entirely on text to access spoken content. He visits a nonprofit’s site to hear about a new program, published only as an embedded audio player with no transcript link anywhere nearby. He can see the player’s controls and duration, but has no way to know what’s actually said in the recording: not a summary, not a partial description, nothing. He leaves the page having received zero information from content every hearing visitor gets in full.

How do I fix it?

Publish a full text transcript of the audio’s spoken content, either as a visible block near the player or behind a clearly labelled toggle like a <details> element. This works because a transcript is a complete, independently readable text equivalent; it doesn’t need to sync to anything, unlike video captions, so a plain block of accurate text fully satisfies the requirement on its own.

Link the transcript directly next to the audio player rather than burying it elsewhere on the page or site, so a deaf or hard-of-hearing visitor doesn’t have to search for it separately from the player itself.

Code Examples

<audio controls src="/podcast/episode-12.mp3"></audio>

<audio controls src="/podcast/episode-12.mp3"></audio>
<details>
  <summary>Read the full transcript</summary>
  <p>
    Host: Welcome back to the show. Today we're talking with...
  </p>
  <!-- full transcript text continues -->
</details>

The <details> element keeps the transcript out of the way for listeners who don’t need it, while making it one click away and fully readable by a screen reader, a braille display, or plain visual reading for anyone who does: the same content, delivered through a channel that works regardless of hearing ability.

Common Mistakes

Mistake: “A brief written summary of the topic covers the requirement.” WCAG 1.2.1 calls for a transcript equivalent to the actual spoken content, not a summary of its general subject. A one-sentence description of what an interview is “about” leaves out everything the interview actually said: the specific answers, numbers, and details a hearing listener receives in full.

Mistake: “Auto-generated captions or transcripts from the hosting platform are automatically good enough.” Automated speech-to-text is a reasonable starting point but routinely mis-transcribes names, technical terms, and homophones. Publish a reviewed, corrected transcript rather than raw automated output, particularly for content where accuracy matters, like instructions or factual claims.

Mistake: “This only matters for long-form content like full podcast episodes.” WCAG 1.2.1 applies to prerecorded audio regardless of length. A thirty-second audio announcement with no transcript is exactly as inaccessible to a deaf listener as a thirty-minute recording; the fix is smaller, but the requirement is identical.

How RedFlag Detects This

Automated: axe-core rule, runs on every scan. RedFlag calls axe-core’s audio-caption rule as part of every scan, restricted to the WCAG 2.0/2.1/2.2 A and AA rule set. The rule inspects every <audio> element and checks for an associated <track> element or other detectable text-alternative signal in the surrounding markup.

False negative: axe-core can confirm the absence of a detectable track or transcript link reliably, but it can’t verify that a transcript linked elsewhere on the page (behind a button, in a separate tab, or on a linked page) is actually complete and accurate. A page that links to a broken or partial transcript file can still pass if axe-core detects some qualifying markup. False positive: an <audio> element used purely for ambient background sound with no informative speech content can be flagged even though no transcript is genuinely needed, since axe-core can’t distinguish informative speech from non-informative sound. Manual step: confirm any transcript found actually corresponds to the audio’s real content, is accurate, and is easy to locate from the player itself.

Manual Testing

1. Open the page in a browser and locate every <audio> element with spoken or informative content.
2. Look for a transcript link, toggle, or visible text block near each player.
3. Open the transcript and confirm it matches the actual audio content in full, not a summary or partial excerpt.
4. If no transcript exists, or the linked transcript is inaccurate, incomplete, or hard to find from the player, the check fails.

Related WCAG Success Criteria

1.2.1 Audio-only and Video-only (Prerecorded): Prerecorded audio-only content must have a text alternative that presents equivalent information. A missing transcript on an informative <audio> element is a direct failure of this criterion.

Related Issues

Video is missing captions covers the sibling requirement for prerecorded video with audio, where timed captions rather than a standalone transcript are the expected fix.

Page auto-plays audio or video with sound shares the same media element type and affected-user overlap; both rules concern how audio content is delivered responsibly to listeners.

Image is missing alt text shares the same underlying WCAG principle from a different angle: non-text and non-visual content both need an equivalent way to reach users who can’t perceive the original format.

References

• W3C Understanding 1.2.1: Audio-only and Video-only (Prerecorded)
• MDN: audio element
• WebAIM: Captions, Transcripts, and Audio Descriptions