Podcast Accessibility: Why Your Show Needs Transcripts (and How to Add Them Without a Budget)

If you publish a podcast, a recorded interview, or any audio content on your website, there is a group of potential listeners who get absolutely nothing from it: people who are deaf or hard of hearing. Not a degraded experience, not a slightly worse one — nothing. An episode page with a play button and no transcript is, for millions of people, an empty page.

This is one of the oldest and clearest rules in web accessibility, and it is also one of the most widely ignored. Industry analyses have repeatedly found that only a minority of podcasts offer transcripts, even though the fix is cheaper today than it has ever been. If you have been putting it off, this article is for you. No jargon, no developer tools — just what the rules actually require, what it costs in 2026, and a workflow you can start this week.

Who this actually affects

Around 5% of the world’s population — over 430 million people, per the World Health Organization — have disabling hearing loss, and that number rises steeply with age. In the United States, roughly one in eight people over twelve has measurable hearing loss in both ears. If your audience skews over 50, the share of your visitors who struggle with audio-only content is far higher than most creators assume.

And transcripts are not only for deaf and hard-of-hearing people. They help:

  • People in sound-hostile environments — open offices, public transport, a house with a sleeping baby — who forgot their headphones.
  • Non-native speakers, who often read a language more comfortably than they parse it at conversational speed, especially with crosstalk and idioms.
  • People with attention or processing differences, who want to read at their own pace, re-read a confusing sentence, or skim.
  • Anyone trying to find that one thing you said. Nobody scrubs through 45 minutes of audio to find a product name. Everybody hits Ctrl+F on a transcript.

That last point has a commercial twin: search engines cannot listen to your show either. A published transcript is often the single biggest SEO improvement an episode page can get, because it turns 45 minutes of invisible audio into thousands of words of indexable text. Accessibility and discoverability are the same work here.

What the rules actually say

The Web Content Accessibility Guidelines (WCAG) — the standard referenced by the Americans with Disabilities Act enforcement actions in the US and by the European Accessibility Act in the EU — deal with audio-only content in Success Criterion 1.2.1, and it is refreshingly blunt: prerecorded audio-only content needs a text alternative that presents equivalent information. For a podcast, that means a transcript. Not a summary, not show notes with three bullet points — a text version that gives a reader everything a listener gets.

A few related rules matter once you look at the whole episode page:

  • If your podcast is also a video (a filmed interview on YouTube, for example), captions are required as well (Success Criterion 1.2.2). Captions and transcripts serve different needs: captions are synchronized with the video, while a transcript can be read independently at any pace. A video podcast ideally has both.
  • Your audio player must be usable by keyboard (Success Criterion 2.1.1). Play, pause, and volume need to work for someone who cannot use a mouse. If you use an embedded player from a major host, this is mostly handled — but test it: click into the page, press Tab until the play button is highlighted, and press Enter.
  • Nothing should autoplay (Success Criterion 1.4.2). Audio that starts by itself and plays for more than three seconds interferes with screen reader users, who navigate by listening. Your episode should wait to be asked.

One nuance worth knowing: WCAG 1.2.1 applies to the audio as published on your website. But regardless of where the legal line sits for a podcast distributed only through apps, the practical answer is the same — the transcript belongs on the episode page on your site, where everyone (including search engines) can find it.

”Transcripts are expensive” was true — five years ago

The honest historical reason podcasts skipped transcripts was cost: human transcription runs roughly $1 to $2 per audio minute, which turns a weekly one-hour show into a few thousand dollars a year. For a hobby podcast, that was a real barrier.

That barrier is gone. AI speech-to-text has become astonishingly good and effectively free at podcast scale:

  • Your podcast host may already do it. Most major hosting platforms now generate transcripts automatically or with one click. Check your dashboard before you buy anything — the feature may be sitting there switched off.
  • Apple Podcasts auto-generates transcripts for shows in its catalog, and Spotify offers them for many episodes. This is great for listeners in those apps, but it does not cover your website — and the auto-generated version contains recognition errors you never get to fix. Treat platform transcripts as a floor, not the finished job.
  • Standalone tools are cheap. Whisper-based transcription services, editor-style tools, and the transcription built into video editors will turn an hour of clear speech into usable text in minutes, typically for a few dollars or less.

The remaining real cost is cleanup, and it is smaller than people fear: 15 to 30 minutes per episode to fix names, technical terms, and speaker attribution. If you produce a weekly show, that is a manageable routine — and far less effort than the episode took to record.

What a good transcript looks like

Machine output is a draft, not a deliverable. A transcript that “presents equivalent information,” as WCAG puts it, needs a few things the AI will not do reliably on its own:

Speaker labels. In any conversation, the reader must know who is talking. SARAH: and GUEST: on each turn is enough. Unlabeled walls of text make interviews unreadable.

Meaningful sounds and context. If something non-verbal carries meaning — [laughter], [phone rings], [plays clip from the ad] — note it. A reader should not be confused by a reply to something they could not perceive.

Corrected names and terms. Speech recognition mangles proper nouns, product names, and industry jargon with total confidence. These are exactly the words your readers most need to be right, and exactly the words people search for.

Readable formatting. Break the text into paragraphs at natural topic shifts. Add a small number of subheadings for major segments if the episode is long. A 9,000-word single paragraph technically exists; nobody can use it.

On the page, not behind a wall. Publish the transcript as text on the episode page itself, or on a clearly linked page — not as a PDF download, not gated behind an email signup, and not inside a widget that requires a dozen clicks to expand a sentence at a time. If the page design gets long, a simple expandable section labeled “Read the full transcript” is fine, as long as it works with a keyboard.

A workflow you can start this week

Here is the whole process for a typical episode, assuming you already have a hosting platform:

  1. Generate. When you upload the episode, run your host’s transcription, or drop the file into a transcription tool. Cost: minutes of waiting.
  2. Clean up. Read through once at speed. Fix names, fix your product’s spelling, add speaker labels, break into paragraphs. Budget 20 minutes for a one-hour episode; it gets faster every week.
  3. Publish on the episode page. Paste the transcript below your show notes as normal text with a “Transcript” heading. If your page template supports it, use a collapsible section — but text on the page beats a link to a file.
  4. Check the player. Once, not every episode: confirm your embedded player can be operated with the Tab and Enter keys and that nothing autoplays.
  5. Backfill strategically. Do not let 200 old episodes stop you from starting. Transcribe every new episode from now on, then backfill your most-visited old episodes first — your analytics will tell you which ten pages get 80% of the traffic.

That is the entire system. No developer, no plugin project, no budget line that needs approval.

The part where this pays you back

It is worth saying plainly: transcripts are one of the rare accessibility tasks with a direct, measurable, selfish payoff. Every episode becomes a long-form page of exactly the language your audience uses, in their own words and your own voice. Creators who publish transcripts routinely find old episodes ranking for questions they answered offhand in minute 37 — searches no show-notes summary would ever have caught. The same text can be sliced into newsletter segments, quote graphics, and article drafts.

You are not doing extra work for a small audience. You are finishing the publishing job for the whole audience — including the search engine that decides whether anyone new ever finds the show.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.