Search topics
Podcasts and silent videos with no transcript
A podcast clip gives its advice only out loud, and a silent how-to video shows its steps only in pictures, with no text beside either.
<audio controls src="care-tips.mp3"> The problem
People who can't hear miss everything a podcast says, and people who can't see miss everything a silent video shows.
A cookware shop's page for a cast-iron skillet has two pieces of media under the product photos. The first is a 19-second clip from the shop's podcast: the host, Alex, asks Maya, who makes the pans, how to look after one, and she says never to put it in the dishwasher, to dry it on the hob straight away and to rub in half a teaspoon of oil while it is warm. The second is a short video with no sound and no words: oil is rubbed into the pan and wiped off again, the pan goes into an oven upside down at 230°C while a timer runs down from 60 minutes, and it comes out black and glossy. Neither has any text beside it. The page's own care section says only "See the clip and the video below".
Success criterion 1.2.1 covers prerecorded media that is only sound or only picture. Audio-only content, such as a podcast clip, needs a text alternative that gives the same information: every word said, who says it, and the sounds that matter. Video-only content, such as a silent how-to, needs either a text alternative that describes what it shows, in order, or an audio track that says it. Here the clip has no transcript and the video has no description or narration, so both fail. The one exception is media that only repeats text already on the page and is labelled as doing so, such as a "Listen to this article" button.
Anyone on a train without headphones meets the same silence, and anyone looking for the oven temperature finds it faster in text than by watching the video again.
4 of 10 groups affected
- No vision (affected)
- Low vision (not affected)
- Colour vision (not affected)
- No hearing (affected)
- Hard of hearing (affected)
- No speech (not affected)
- Motor (not affected)
- Reach, strength (not affected)
- Cognitive (affected)
- Seizures (not affected)
- Without hearing The care tips exist only as speech, so the warning about the dishwasher never reaches them. Deafblind visitors reading in braille need both the transcript and the video's description, since neither the sound nor the picture reaches them.
- Without vision The seasoning steps are only pictures. A screen reader announces a video and its controls, and nothing about the oil, the oven, the 230°C or the hour it takes.
- Limited hearing A quiet voice or a quick reply is hard to catch. A transcript lets them check what they half heard, such as how much oil to use, without replaying the clip.
- Limited language, cognitive and learning abilities Reading at their own pace, and going back to one step, is easier than replaying audio or scrubbing through a video, especially in a second language.
axe has no active rule for 1.2.1. Its old audio-caption rule is deprecated and switched off, and it looked for a captions track on <audio>, which is not what the criterion asks for. No tool can tell whether a video with no sound shows information or only decorates, or whether a transcript matches the recording. AI can draft both: speech recognition gives a first transcript, and a vision model can describe a video. But a draft such as "a pan is put in an oven" sounds right and leaves out that it goes in upside down, at what temperature and for how long, which is the part people need. Someone who knows the subject has to read the draft against the media.
Try it
Turn the sound and picture off, then play the clip or the video. What do you learn?
The switch stands in for a visitor who can’t hear the clip or can’t see the video: the players still play, and tell you nothing. Broken 1 is the podcast clip, Broken 2 the silent seasoning video. Apply a fix to get the transcript and the description under the players, or a link to a page of their own.
Broken Can you fix this?
Care tips, from our podcast
The fix
Give every audio clip a transcript and every silent video a description, on the page under the player or on a page linked right beside it.
- 1Write out every word said, name each speaker and put the sounds that matter in square brackets.
- 2Describe every step a silent video shows, with any words or numbers on screen.
- 3Put the text right under the player, or a link to it right beside the player.
An audio clip with no transcript
<h2>Care tips, from our podcast</h2><audio controls preload="metadata" src="care-tips.mp3"></audio>The text on the page, under the player
<h2>Care tips, from our podcast</h2><audio controls preload="metadata" src="care-tips.mp3"></audio><h3>Transcript</h3><p><b>Alex:</b> Maya, what’s the one thing people get wrong with a new pan?</p><p><b>Maya:</b> The dishwasher. Never put it in the dishwasher. It strips the seasoning, and the pan will rust.</p><p><b>Alex:</b> So how do you wash it?</p><p><b>Maya:</b> By hand, in hot water. Then dry it on the hob straight away, and while it’s warm, rub in half a teaspoon of oil.</p> <h2>Seasoning, step by step</h2><video controls preload="metadata" src="seasoning.webm" poster="seasoning.webp"></video><h3>What the video shows</h3><p>The video has no sound.</p><ol> <li>A few drops of oil go onto the pan, and a cloth rubs them in.</li> <li>A paper towel wipes the oil off again, until the pan looks almost dry.</li> <li>The pan goes into the oven upside down, above a tray, at 230°C for 60 minutes.</li> <li>The oven is switched off and the pan cools inside it. It comes out black and glossy.</li></ol>Why this fix: Keep the text alternative beside what it stands for
The advice exists only in the recording. A visitor who can't hear it gets a play button and a 19-second progress bar, and never learns that the dishwasher will ruin the pan.
The transcript gives every word in order, with each speaker named, and the description gives every step the video shows, with the temperature and the time that are only on screen. Both are ordinary text straight after their player, so a screen reader reaches them next, braille displays and translation read them, and find in page turns up "dishwasher" or "230".
Both pass 1.2.1 when the text is complete. Put the text on the page under the player: it does the same job with nothing to give up, because everyone who finds the player finds the text, and it is edited in the same place as the media, so it can't drift away from it or be lost behind a broken link. W3C's media guidance says the same: for media on your own site, the transcript is best on the same page. Use a page of its own when the player is on a page you can't add text to, such as a template shared by many products, and keep the link right beside the player.
A long transcript can sit in a <details> element under the player, with a <summary> that says "Transcript", so the page stays short and the text is one Enter away. It is still on the page, and Chrome and Edge open a closed <details> when find in page matches text inside it. Break a long transcript into paragraphs at each change of speaker, add headings for its sections, and add timestamps only where people will want to jump to a point in the recording.
Write a transcript the way the recording sounds, not the way it was planned. Name each speaker the first time and at each change, put sounds that carry meaning in square brackets ("[Pan sizzles]", "[Laughter]"), and correct the script or the speech-recognition draft against the final audio. Keep it in HTML: a PDF or a scanned page adds a download and often loses the speakers and paragraphs.
Where the media plays changes where the text goes.
- Your own
<audio>or<video>: put the text under it, as above. - An embedded podcast player, from Spotify, Apple Podcasts or SoundCloud: put your own transcript under the embed. Some platforms make transcripts by speech recognition, but they need checking like automatic captions, and they may not show in the player embedded on your page.
- A custom audio player with its own buttons: the transcript goes under the player as a whole, not inside its controls.
A silent video can also meet 1.2.1 with a narrated version: a sound track that says what each step shows. It helps blind visitors, and listeners who prefer it, but deafblind visitors reading braille get nothing from it, and it is another recording to remake whenever the video changes. A text description serves everyone the narration does, and them too, so start there and add narration as an extra.
A video with no information to give, such as a background loop of beans roasting, needs no description: it is decoration. If it plays by itself for more than five seconds, it still needs a way to pause it, which is covered in tickers, carousels and animations that can't be paused. A video with speech is not covered here: it needs captions, which are covered in videos without captions, or with unchecked automatic ones.
Fixing this with an AI coding assistant? Get this guide as Markdown
Verify the fix
3 checks, no mouse.
Test with: Sound off, Screen off, Screen reader
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat whenever the recording, the video or the text is replaced.
Limits
This is a starting pattern, not a guarantee for every application. It covers prerecorded media that is only sound or only picture. A video with both needs captions for what is said (1.2.2), covered in videos without captions, or with unchecked automatic ones, and audio description for what is only shown (1.2.3 and 1.2.5), covered in videos without audio description of what they show. A full text alternative for it is the AAA criterion 1.2.8. Live audio, such as a radio stream, is the AAA criterion 1.2.9. Sound that starts by itself is covered in autoplaying sound with no way to stop it. Test the complete journey with the people who will listen and watch, and with the players and platforms the media really plays in.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
Keep this fixed as your code changes.
Turn guides like this into rules your coding agents and CI follow, then have the result retested with a keyboard and screen readers.