What a WCAG-Compliant Podcast Transcript Looks Like (With Template)

Plenty of guides will tell you that podcasts need transcripts. Almost none of them show you what a compliant transcript actually looks like — how speakers are labelled, what non-speech sounds go in, where the file has to live so it counts.

Why transcripts are required — the short version

The requirement comes from WCAG 2.1, success criterion 1.2.1 (Level A): prerecorded audio-only content must have a text alternative that presents equivalent information. For a podcast, that text alternative is, in practice, a transcript.

This matters legally because WCAG 2.1 AA is the technical standard embedded — via EN 301 549 — in the European Accessibility Act, in force since June 2025 for a wide range of consumer-facing services, and the benchmark courts reach for under the UK Equality Act and in US ADA practice. If your podcast is part of an in-scope service, the transcript is not a courtesy; it's the compliance floor. (The full legal picture is in our complete EAA captioning and transcript guide.)

And two audiences benefit long before any regulator looks:

• People who can't hear the episode — the entire point of the criterion — plus everyone reading in contexts where audio doesn't work.
• Machines. Search engines cannot index audio. A published transcript is the difference between an episode that exists on the open web and one that exists only inside podcast apps. Every quotable line becomes searchable, linkable text.

The five requirements

A podcast transcript meets the accessibility bar when it does five things:

1. It conveys the same content as the audio. All of the spoken material — not a summary, not highlights. The listener with the transcript should come away with what the listener with headphones got.

2. It shows clearly who says what. The conversation is rendered as labelled dialogue — speaker name, then their words. An unlabelled wall of text technically contains the content and practically buries it.

3. It includes non-speech information that matters for understanding. [laughter] after a deadpan line, [applause], [phone rings] before someone answers it, the [tense music] that reframes a statement. The test is narrative relevance: include the sounds the audio audience used, skip the ambient rest.

4. It is written and coded as text. Real, machine-readable text — selectable, searchable, screen-reader-friendly. A scanned image of a transcript, or text baked into a graphic, fails this outright no matter how complete the words are.

5. It is findable from the episode. Visually near the player, or reachable through an obvious link or button. A perfect transcript on an orphan page no listener can find does not count as provided.

The template

Here's what those five requirements look like on the page. Copy the shape, not the words:

Episode 42 — Does a Podcast Really Need a Transcript?
Recorded 3 June 2026 · 47 min
Full transcript below.

[Intro music]

MARIA: Welcome back to the show. I'm Maria Lund, and today
we're getting into a question we get constantly: what the
accessibility rules actually mean for podcasters.

JONAS: Thanks for having me. It's a bigger topic than
people think.

MARIA: Let's start with the blunt version. Does a podcast
really need a transcript?

JONAS: [laughs] Legally? If the podcast is part of a covered
service — yes. But honestly, the legal answer is the least
interesting reason to do it.

MARIA: Because of search?

JONAS: Because of search. An episode without a transcript
is invisible to Google. With one, every sentence you
recorded becomes a page someone can land on.

[Ad break]

MARIA: Before the break, you mentioned speaker labels…

Notice what the format is doing: names in a consistent style before each turn, a new paragraph per turn, sound cues in square brackets exactly where they occur, and the episode's structure ([Intro music], [Ad break]) marked so a reader can navigate the way a listener does.

Timestamps are optional. They're not part of the requirement, but adding them at section breaks — or per turn, if your tool generates them anyway — helps readers jump between text and audio, and helps you when someone asks "where did he say that?"

Where to publish it — and the RSS trick

The requirement says findable; experience says there are four good patterns, and one of them is undervalued:

On the episode page, as expandable text. A "Transcript" heading or toggle directly under the player. Best all-round option: it satisfies requirement 5 at a glance, and it's the version search engines index — HTML text on your own page is the whole SEO benefit realised.

A button inside or beside the player. Some hosting platforms support a transcript control in the embed itself. Excellent proximity; just make sure the text also exists as an indexable page, not only inside a widget.

A transcripts archive. A dedicated page collecting downloadable versions — fine as a supplement, and useful for readers who want offline copies (PDF and DOCX are legitimate here, as long as they're real text, not scans). Weak as the only home, because it separates transcript from episode.

The RSS trick — do this regardless of the above: put the transcript link in the episode description in your RSS feed. The description propagates to every app that carries your show — Apple Podcasts, Spotify, and the rest — so the link surfaces next to the episode everywhere it plays, including the platforms where you control nothing else about the page. One line in the feed, distribution to every player at once.

What about just publishing a summary?

Tempting, and worth an honest answer: a summary alone does not meet the bar. WCAG 1.2.1 asks for a text alternative presenting equivalent information — and a paragraph about a 47-minute conversation is not equivalent to the conversation.

Where summaries shine is on top of the transcript: an introduction, a bulleted list of topics, the key takeaways. That combination serves skimmers, helps search engines understand the page, and gives social sharers something quotable — while the full transcript underneath does the compliance work. Summary as the door, transcript as the room.

(Whether the transcript itself should be strictly verbatim or lightly cleaned of filler is a genuine judgement call with a real trade-off — we've laid out both sides in our subtitle quality guide.)

Producing one without losing an afternoon

Manually transcribing an hour of conversation takes most people four to six hours. The workflow in Inwista:

1. Upload the episode — audio or video, any common format.
2. Automatic transcription with speaker identification. Inwista distinguishes who is speaking and separates the conversation into turns; in the editor, you replace "Speaker 1" and "Speaker 2" with names once, and the label applies throughout.
3. Review in the editor — fix the odd name, add any sound cues the audio needs.
4. Export as TXT, DOCX or PDF — or copy the text straight into your episode page as HTML.

The result is the template above, generated instead of typed.

Inwista's free plan lets you run the whole workflow on your own material — upload, transcribe, structure, edit and export. Current limits and plan details are on the pricing page.

Transcribe your next episode free →

Frequently asked questions

Is a transcript legally required for my podcast? If the podcast is part of a service covered by the European Accessibility Act — or you fall under equivalent obligations like the UK Equality Act — a text alternative for prerecorded audio is part of the WCAG 2.1 bar those regimes point to. Outside any legal scope, it remains the single highest-leverage accessibility and SEO step a podcast can take.

Spotify and Apple generate transcripts automatically now. Doesn't that cover me? It helps listeners inside those apps, but it's a shaky compliance position: the transcripts live only in each platform, at quality you don't control, on your website not at all. Your obligation attaches to your service — a transcript you publish is the version that counts, and the only one search engines will ever see.

Do I need timestamps? No — they're not part of the requirement. They're useful for navigation and citation, so if your tool produces them anyway, keeping them at section breaks is a nice touch rather than clutter.

Does a PDF transcript count? Yes, if it's genuine text (selectable, screen-reader-readable) and clearly linked from the episode. A scanned image in a PDF does not. For search visibility, HTML on the episode page beats any download format.

Should the transcript be word-for-word or cleaned up? Both are defensible. Verbatim preserves exactly what listeners heard and is preferred by many deaf and hard-of-hearing readers; light cleaning of fillers reads more comfortably. Whichever you choose, never alter meaning — and be consistent across episodes.

What non-speech sounds do I include? The ones that carry meaning: laughter, applause, a phone ringing that gets answered, music that sets a scene. Skip ambience the audio audience wasn't consciously using. When in doubt, ask what a reader misses without it.

This article is general guidance on accessibility requirements for podcast transcripts, not legal advice. Obligations vary by jurisdiction and by whether your service is in scope of the relevant law — consult qualified counsel on your situation.