A podcast is audio. For a listener who is deaf or hard of hearing, an episode without text is a closed door. For many other people, a transcript is simply easier: they read on a train, search for a name, or skim before deciding to listen. Accessibility and convenience point to the same thing, a text version of the episode that sits next to it.

This article explains what the main accessibility standard says about audio, what a good transcript contains, and how to publish one without turning it into a second job.

This is practical guidance, not legal advice. If a law or a contract applies to you, ask someone qualified.

What WCAG says about audio

The Web Content Accessibility Guidelines (WCAG) are the standard most accessibility rules and audits refer to. Success Criterion 1.2.1, Audio-only and Video-only (Prerecorded), is a Level A requirement, the most basic level. For prerecorded audio-only content, such as a podcast episode, it asks for an alternative for time-based media that presents the same information.

The W3C’s own explanation names the transcript as the main example of that alternative: a text document that gives, in the right order, what is said and any significant sounds, such as laughter or applause. So when a podcast page offers a full transcript, it answers 1.2.1 for that episode.

Two practical points follow:

  • The requirement is about the page that carries the audio. If your episode lives on a website, put the transcript on that page or link to it clearly.
  • A summary or show notes is not a transcript. They help readers, but they do not carry the full content of the episode.

What a good accessible transcript contains

  • Everything that is said, in order, not a rewritten version.
  • Speaker labels, so a reader knows who is talking. “Host:” and “Guest:” is enough; names are better.
  • Meaningful non-speech sounds in brackets, such as [laughter] or [music fades]. Skip sounds that add nothing.
  • Timestamps, at least at paragraph or topic starts, so readers can move between text and audio.
  • Clear structure: short paragraphs and headings for chapters, not one block of text.
  • Correct names and numbers. A wrong name in a transcript is also a wrong name in front of a screen reader.

Where to publish it

  1. On the episode page, under the player, in a section with a heading such as “Transcript”. Search engines can read it, and so can screen readers.
  2. As a link to a separate page if the transcript is very long, but keep the link next to the player and name it plainly (“Read the transcript”).
  3. In the player or app, when your hosting platform supports transcripts. Do this in addition to the web page, not instead of it.

Use real HTML text. A transcript in an image or a scanned PDF cannot be read by assistive technology.

A short checklist for each episode

  • The transcript covers the whole episode.
  • Speakers are labelled and names are spelled the way the speakers spell them.
  • Sounds that carry meaning are described.
  • The transcript is on the episode page, or linked from it next to the player.
  • The text is real HTML with headings, not an image.
  • A person has read it once, with the audio, for names and numbers.

How to do it without a second job

Writing a transcript by hand takes several times the length of the audio. With a tool, the work becomes a review. Podcast To Transcript creates a speaker-labelled, timestamped transcript for an episode from Apple Podcasts, Spotify, YouTube (with captions) or any page with audio. Read it once against the audio, fix the names, and paste it onto the episode page. Clicking a line moves the player to that moment, which makes the review much faster.

Check the accuracy of what you publish. How accurate are AI podcast transcripts? has a 10-minute test you can run. If you also write show notes, use the show notes template. For more on creating the text version of a show, see the guide to transcribing a podcast and the page for podcast creators.

Summary

  • WCAG 1.2.1 (Level A) asks for a text alternative to prerecorded audio, and a transcript is the standard answer.
  • A summary is not a transcript: publish the full text.
  • Label speakers, describe meaningful sounds, and use real HTML on the episode page.
  • Review the text once against the audio.

Frequently asked questions

Is a podcast transcript legally required?

It depends on who you are and where you publish. Public bodies, universities and many companies must meet accessibility rules that refer to WCAG, and a transcript is the usual way to meet the audio requirement. Check the rules that apply to you, and treat this article as a practical guide, not legal advice.

Can I use an auto-generated transcript?

You can, as long as it is accurate enough to be useful. Auto-generated text that nobody reviewed often fails the people who rely on it. Review it once against the audio, fix names and numbers, and label the speakers.

Do I need captions as well?

Captions matter for video. For audio-only episodes, WCAG asks for a text alternative, and a transcript meets it. If you publish a video version, add captions as well.

Where should the transcript go on the page?

Put it in real HTML on the episode page, below the player, with headings and a clear link to it. Avoid a PDF or an image of text, because screen readers and search engines read HTML far better.

Do transcripts help SEO?

Yes. A transcript gives search engines the words of the episode, so the page can rank for topics you discuss but never put in the title. That is a side effect, and the main reason remains access. To build this into your routine, read our show notes template and the page for podcast creators.