Audio, podcast and sermon accessibility: transcripts and players for small websites
How to make podcasts, sermons, audio tours and other audio on a small business or church website accessible: transcripts, checking automatic transcripts, no autoplay, keyboard-friendly players, embedded player titles, and clear episode lists.
Plenty of small organisations put audio on their websites: a church posting weekly sermons, a coach or consultant with a podcast, a museum audio tour, a realtor's voice-over walkthrough, a band or music teacher sharing samples, or a nonprofit's radio interview. Audio is great for many people, but Deaf and hard of hearing visitors can't use it without text, and a player that can't be used by keyboard or screen reader shuts out others. This guide covers what to check, whichever website builder or podcast host you use.
1. Give every recording a transcript
For recorded audio-only content, such as a podcast episode or sermon, give a text transcript that includes what was said and who said it, plus important sounds like "[audience laughs]" or "[music]" (WCAG 1.2.1). Put it on the same page as the player, or link to it right next to the player with a clear name, such as "Read the transcript of episode 12". If the episode is a video, it needs captions too; see video captions for small business websites.
<h2>Episode 12: Planning your first garden</h2>
<audio controls src="/audio/ep12.mp3"></audio>
<p><a href="#transcript-12">Read the transcript</a> ·
<a href="/audio/ep12.mp3" download>Download MP3 (24 MB)</a></p>
<details id="transcript-12">
<summary>Transcript: Episode 12</summary>
<p><strong>Maria:</strong> Welcome back. Today we're talking about...</p>
</details>
2. Check automatic transcripts before you post them
Many podcast hosts, editing apps and AI tools now make transcripts or captions in a few taps. That's a good start and saves time, but they often get names, places, numbers and Bible or technical references wrong, and they may not say who is speaking. Read it through once, fix the errors and add speaker names before you publish. A transcript full of mistakes doesn't give people the same information as the audio.
3. Don't autoplay sound
Audio that starts by itself makes it hard for screen reader users to hear their screen reader, and it startles everyone else. Let people press Play. If any sound plays automatically for more than 3 seconds, give an easy way to pause or stop it, or turn its volume down separately (WCAG 1.4.2). Background music on a home page is a common example; see animation and background video.
4. A player that works by keyboard and screen reader
- Play, pause, the progress bar, volume, speed and download must all be reachable and usable with the Tab key, Enter and Space, and arrow keys for sliders (WCAG 2.1.1), with a visible focus outline (WCAG 2.4.7).
- Each button needs a name that a screen reader reads out, such as "Play episode 12", and Play should change to "Pause" when it's playing (WCAG 4.1.2).
- Icon buttons and the progress bar need enough contrast against the background (WCAG 1.4.11), and buttons should be big enough to tap on a phone (WCAG 2.5.8).
- The browser's built-in
<audio controls>player is usually a safer choice than a custom player made of unlabeled icons.
5. Embedded players from podcast hosts
Many sites embed an episode player from a podcast host or a music service in an iframe. Give the iframe a title, such as title="Podcast player: Episode 12", so screen reader users know what it is (WCAG 4.1.2). You usually can't change the player's code, so test it on your own page with a keyboard. If it traps focus or its buttons can't be reached (WCAG 2.1.2), add a plain download link and the transcript on your page, ask the host's support team, and consider another player. See social media and feed embeds.
6. Make episode and sermon lists easy to scan
Use a real heading for each episode or sermon with the title and date in text, and say how long it is, such as "38 minutes" (WCAG 1.3.1). Avoid "Listen here" links that all sound the same; say "Listen to Episode 12: Planning your first garden" (see link text and buttons). Cover art needs short alt text or an empty alt="" if the title is already next to it (WCAG 1.1.1). If the sermon notes or show notes are a PDF, see accessible PDFs.
7. Live audio and livestreams
If you stream a service or a live show, the recording you post afterwards still needs a transcript or captions. For live video, live captions are part of WCAG level AA (WCAG 1.2.4); many streaming tools offer automatic live captions, which are better than none.
Common mistakes
- No transcript at all, or a "transcript coming soon" note that never gets filled in.
- Automatic transcripts posted unchecked, with names and numbers wrong.
- Background music or a welcome message that plays on page load.
- A custom player with icon-only buttons that a screen reader reads as "button, button, button".
- An embedded player iframe with no title, or one that keyboard focus gets stuck in.
- Every episode link reading "Listen now".
A 5-minute check you can do today
- Open your latest episode or sermon page. Is there a transcript, or a clear link to one, next to the player?
- Read the first paragraph of the transcript while listening. Are the names and key words right?
- Reload the page. Does any sound start by itself?
- Use only the Tab key, Enter and Space to play, pause and download. Can you see where focus is the whole time?
- Turn on VoiceOver or TalkBack and listen to the player's buttons; see the 10-minute screen reader test.
What a scan can and can't check here
Automated scans find only part of the barriers on the pages they visit. Our scan can flag some unnamed buttons, iframes with no title, missing alt text and many contrast problems. It can't listen to audio, tell whether a transcript exists or is accurate, check autoplay, use the player with a keyboard, or tell whether your site meets any law. Our Fix-Pack checks up to 10 pages, which can include your podcast or sermon page, and gives copy-paste fixes for your platform.
Building sites with podcasts or sermon libraries for clients? The agency 5-pack gives you five white-label reports ($499, use within 12 months).
This is general technical guidance, not legal advice, and it doesn't certify compliance with the ADA or any law, or protect against claims. Altwise isn't affiliated with any podcast host, website builder or transcription tool.
Want the fixes written for you?
Start with a free homepage snapshot. The $149 Fix-Pack scans up to 10 pages and gives copy-paste fixes for your platform within 48 hours, with a 14-day refund promise. See a sample report first.
This is general technical guidance, not legal advice, and it does not certify compliance with the ADA or any law.
Related guides
- Charts, graphs and infographics accessibility: impact reports, results and data on small websites
- Announcement bars, holiday hours and closure notices: accessible banners for small business websites
- QR codes and QR code menus: making the pages they open accessible
- Email newsletter and SMS signup forms: accessible signup boxes and pop-ups
This guide is general technical information, not legal advice. Following it does not certify ADA or any legal compliance. Automated checks find only part of accessibility barriers.
Check your own site, then decide
- Free homepage snapshot. Your top 3 issues in about a minute. No signup, no card.
- $149 Fix-Pack, if you want the full list. Up to 10 pages scanned, issues ranked by impact, copy-paste fixes for your platform, delivered within 48 hours, plus one re-scan after you apply them.
Get my free snapshot Order the Fix-Pack – $149
14-day refund promise. See a sample report first. A technical report, not legal advice; automated checks find only part of accessibility barriers.