Audio Needs Captions

Element Code: AC-045

What This Check Actually Flags

This check looks at every <audio> and <video> element on a page and asks a simple question: is there any machine-readable text version of what's being said or shown. If a podcast player is embedded with no transcript block anywhere on the page, that fails. If a video has a <video> tag but no <track kind="captions"> child and no caption file referenced, that fails too. It doesn't matter if the audio or video is hosted on your own server or embedded from YouTube, Vimeo, Spotify, or a podcast host. If there's spoken or meaningful audio content and no text equivalent lives on or near that element, this check flags it.

A lot of sites get tripped up here because they assume "the platform handles it." YouTube auto-generates captions, sure, but auto-captions live inside YouTube's player, not in your page's HTML. Google's crawler indexing your page doesn't get credit for captions sitting in a third-party iframe. Same with Spotify embeds for podcasts: the audio player shows up, the transcript does not, unless you build it yourself.

Why It Matters for Accessibility (Not Optional)

Three WCAG 2.1 success criteria cover this directly, and knowing which one applies to which media type actually matters when you're prioritizing fixes:

• 1.2.1 Audio-only and Video-only (Prerecorded), Level A: for audio-only content (like a podcast episode) a text transcript must be provided. For video-only content (no audio track, like a silent screen recording) either a transcript or an audio track describing the visuals is required.
• 1.2.2 Captions (Prerecorded), Level A: synchronized captions are required for prerecorded video that has an audio track. This is the "closed captions on a video" requirement most people think of first.
• 1.2.3 Audio Description or Media Alternative (Prerecorded), Level A: for prerecorded video, you need either audio description (a narrated track describing visual information that isn't conveyed in the dialogue) or a full text alternative that describes both the audio and the visuals.

These are Level A, the baseline. They are not "nice to have if you're chasing AAA." A page with an embedded podcast and zero transcript is failing Level A conformance, full stop. This is also the exact category of issue that shows up over and over in ADA web accessibility lawsuits and demand letters, because "video/audio with no text alternative" is trivially easy for a plaintiff's auditor to document with a screen reader test and a screenshot.

Why It Matters for SEO

Here's the part that gets missed even by people who genuinely care about accessibility: Google cannot listen to your audio. It cannot watch your video and understand the dialogue. Search engines parse text. A 40-minute podcast episode with brilliant, keyword-rich, expert commentary is functionally invisible to Google unless you put that content into text on the page. A transcript is not busywork, it's the only mechanism that turns spoken content into something that can rank, get pulled into a featured snippet, or get quoted in an AI Overview.

Concretely, transcripts and captions help SEO in a few specific ways:

• Crawlability of spoken content. Every name, statistic, and phrase your host says out loud becomes indexable text, which means it can match long-tail queries you never would have targeted on purpose.
• Featured snippet and answer-box eligibility. Google pulls snippet answers from text on the page. A well-formatted transcript with clear Q&A structure or headers is snippet bait in a way that an embedded audio player never will be.
• Dwell time and engagement signals. Visitors who came for a specific detail can scan the transcript instead of scrubbing through 25 minutes of audio, which keeps them on the page instead of bouncing back to the SERP.
• On-page keyword relevance and topical depth. A transcript adds substantial, genuinely relevant body text to what might otherwise be a thin page consisting of a title and an embed. That's real content depth, not filler.

None of this shows up as a specific line item in Google Search Console. Search Console won't tell you "hey, your podcast page has no transcript." This is a gap you have to go looking for.

How This Gets Detected

Since Search Console stays quiet on this one, you need dedicated tooling. In practice, a combination of these gets full coverage:

• Screaming Frog custom extraction. Set up a custom extraction rule for //audio and //video XPath selectors, then a second rule checking for the presence (or absence) of a <track> child element or a nearby transcript container. Run it site-wide and you get a spreadsheet of every media element and whether it has a caption track.
• axe DevTools. Deque's axe extension flags missing captions and audio alternatives as part of its automated accessibility scan, and it will point at the specific DOM node.
• WAVE (WebAIM). WAVE visually overlays accessibility issues on the rendered page, including missing text alternatives for media, which is useful for a fast manual spot check.
• Lighthouse accessibility audit. Chrome DevTools' Lighthouse panel includes checks under its accessibility category that catch some, though not all, missing-caption scenarios. Treat it as a supplement, not the whole audit.
• Manual review. For anything embedded via third-party iframe (Spotify, YouTube, SoundCloud), automated tools often can't see inside the iframe. You have to manually confirm whether a transcript exists in your own page markup, separate from the player.

Search Console will not flag this directly. Don't wait for it to show up there.

How to Fix It, Step by Step

1. Inventory every audio and video element on the site. Use the Screaming Frog extraction above to get a full list. Don't rely on memory, especially on sites where multiple authors have embedded media over the years.
2. Generate a first-pass transcript with automated tools. Whisper-based tools, YouTube's auto-caption export, Otter.ai, Descript, or similar will get you 85-95% accuracy fast and cheap. This is a legitimate starting point, not a shortcut you should feel guilty about.
3. Human-edit the auto-generated draft. Auto-transcription mangles names, brand terms, and technical jargon reliably. A person needs to pass over it, fix misheard words, add punctuation for readability, and label speakers if there's more than one voice.
4. For video, build a proper caption file and wire it up with the <track> element. Export a WebVTT (.vtt) file with timestamps, then reference it inside your video tag: <video><track kind="captions" src="captions.vtt" srclang="en" label="English"></video>. This gives users a toggleable closed-caption option baked into the native player.
5. For audio-only content (podcasts), place the full transcript directly on the page near the player. Not linked off to a PDF three clicks away, actually on the page as real text, ideally below or beside the embed. Use headers, paragraph breaks, and speaker labels so it's scannable, not one giant wall of text.
6. Add audio description or a descriptive text alternative for video where visuals carry meaning the dialogue doesn't cover. If someone is pointing at a chart or demoing a UI silently, either narrate it or describe it in the accompanying text.
7. Re-audit with axe or WAVE after publishing to confirm the fix actually registers and nothing broke in the process.

What Good Looks Like

A page that passes this check has a video with a working caption toggle sourced from a real <track> file, or a podcast episode with a complete, readable transcript sitting in the page body, formatted with headers and paragraphs rather than dumped as one unbroken block. The transcript reads like actual page content, not an afterthought bolted on to satisfy a checklist. That's the standard to build toward, and it's the same standard that happens to produce the best SEO outcome, so there's no tension between "accessible" and "optimized" here. They're the same fix.