Captions and transcripts are two different deliverables. Captions put the spoken words and meaningful sounds on screen in sync with playback; a transcript is a block of text on the page that someone can read from top to bottom without pressing play. WCAG requires captions for prerecorded audio in synchronized media at Level A, while Google's video documentation says nothing about captions or transcripts at all. The case for publishing both therefore rests on access and on a page that makes sense as text, not on a promised ranking lift. This is a working reference for content editors, site owners, SEO specialists and developers who publish video.
Sentences labelled "Practical suggestion" are interpretation or advice; everything else follows what the cited pages state. Audio description, sign language and live captioning are outside this topic.
Two different jobs: captions and transcripts
A request for "subtitles and a transcript" in one breath can end with one file that does neither job well. Separating the two jobs first makes every later decision easier.
What a caption has to carry
The Understanding page for Success Criterion 1.2.2 (Opens in a new tab) describes captions as the information that would otherwise arrive through the audio track. That means dialogue, but also speaker identification and non-speech audio that the viewer needs in order to follow the content, such as a meaningful sound effect. A caption track that transcribes the talking and silently drops a warning tone has left out part of the content.
The page also notes that captions should not block relevant information in the video, and that caption style conventions vary by language. Both points matter in practice: a caption box parked over a chart label defeats its own purpose, and a track copied from another language inherits that language's line-break habits.
What a transcript is
Under SC 1.2.1 (Opens in a new tab), the equivalent for audio-only material is an "alternative for time-based media": a document with correctly sequenced text descriptions of the visual and auditory information. For a podcast, that is the spoken text. For a silent screen recording, it is a description of what happens on screen. The document does not need timestamps, which is exactly why readers use it differently from captions: they skim it, search inside it, copy a quote from it, or read it with a screen reader or a braille display.
The same page lists the benefits in plain terms. Assistive technology can read the text aloud, display it, or convert it to braille, and text makes non-text content searchable and easier to repurpose. That sentence is the only search-adjacent statement in the WCAG material, and it describes findability of content, not ranking.
Open versus closed captions
The WCAG glossary separates closed captions, which a viewer can switch on and off in some players, from open captions, which cannot be turned off, such as text rendered into the picture. Sufficient techniques for 1.2.2 include open captions (G93) and closed captions (G87), and the HTML track element (H95) is one of the ways to deliver closed captions.
Practical suggestion: prefer a separate caption file over burned-in text unless a platform forces your hand. A file can be corrected without re-exporting the video and can exist in several languages side by side. Burned-in text locks the language and the typos into the picture.
| Question | Captions | Transcript |
|---|---|---|
| Where does the viewer meet it? | Inside the player during playback | On the page, as readable text |
| Timed to the audio? | Yes, in sync | No timing required |
| Which criterion? | 1.2.2, prerecorded synchronized media, Level A | 1.2.1, audio-only and video-only, Level A |
| Who benefits first? | Deaf and hard-of-hearing viewers, and anyone watching without sound | Readers who prefer text, use braille or want to search the content |
| Replaces the other? | No | No |
What WCAG asks of recorded media
The 1.2 guideline family covers time-based media. Two criteria concern us here, and both sit at Level A, the basic conformance level.
SC 1.2.2: captions for prerecorded synchronized media
The requirement reads, in effect: captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such. "Prerecorded" simply means not live. The stated purpose is to let people who are deaf or hard of hearing watch synchronized media.
One passage addresses time pressure. Authors can face a choice between delaying content until captions exist and publishing it without captions for a while; the page says better captioning tools and delivery workflows may narrow that gap over time. Read carefully, this acknowledges a real problem without lowering the requirement. The sensible response is to build captioning into the schedule before the publish date, not to treat "captions later" as a standing exception.
SC 1.2.1: audio-only and video-only
An interview recording with no picture is audio-only. A looping animation with no sound is video-only. For the first, the criterion requires an alternative that presents equivalent information, and a transcript is the natural form. For the second, it requires either a text alternative or an audio track that presents equivalent information.
The Understanding page adds that an audio track for video-only content lets people with and without vision impairments review the material together. A common blind spot follows from this: a silent product clip feels like it needs nothing, yet 1.2.1 still expects an equivalent. The criterion does not care that the clip has no dialogue to caption.
When captions are not required
The 1.2.2 page says captions are unnecessary when the media only repeats information already available as text on the page. Its examples are short clips that mirror paragraphs of a legal document and a clip showing how to orient a part, both of which duplicate adjacent text. If your video adds anything beyond the surrounding text, the exception disappears.
Failure F75 names the opposite case: media published without captions although it contains more information than the page text. Failure F74 applies when a synchronized media alternative to text is not labeled as such. Treat the exception as something you verify per clip, with a sentence in your own notes explaining why the page text already carries everything.
Failure modes worth knowing by name
- F8: captions that omit important dialogue or sound effects.
- F75: media with more information than the page text, published without captions.
- F74: a media alternative for text that is not labeled as one.
- F30: filenames or placeholder text passed off as a text alternative.
The WCAG page for 1.2.2 does not prescribe how captions must be produced. It expects the result to hold the dialogue and the meaningful sounds. That is the practical test for every workflow, manual or automated.
What search documentation does and does not say
Advice about video search visibility gets repeated without a source. Staying close to the primary pages avoids promising something nobody has documented.
Google's video page
Google's video best practices (Opens in a new tab) describe watch pages, indexing requirements, thumbnails, video sitemaps and VideoObject structured data. The page does not discuss captions, subtitles or transcripts. So the statement "adding a transcript improves video rankings" has no support in that document. The statement "adding a transcript makes the page more useful to people who cannot or prefer not to watch" does have support in the WCAG material.
What the video page does stress is technical clarity. A watch page is a page whose main purpose is to show one video, and it needs a title and description unique to that video. A blog post reviewing an embedded video, a product page with a 360 video and a category page listing several videos are not watch pages in the document's terms; they can still appear as text results or as image results with a video badge. The indexed watch page must perform well in Search before its video can be considered for indexing, and a video is not automatically indexed because the page is.
Text on the page is page content
A transcript placed on the page becomes part of the page's text. It gives a reader a second way into the same material and keeps the topic of the video visible to anyone who never presses play. That is a content-quality argument, and the helpful-content mindset applies to it: publish the text because it helps a reader, and judge it by whether it does.
Practical suggestion: do not pad a page with a transcript to make it look substantial. A short summary paragraph above a collapsible full transcript keeps the page readable while the complete text stays available. Length alone adds nothing.
Keeping metadata consistent with the transcript
The video documentation asks that structured data be consistent with the actual video content and other metadata, with a unique thumbnail URL, name and description for each video. Apply the same discipline to your text: the transcript, the page title and the VideoObject description should describe the same video. When the video is replaced, the transcript and the structured data are replaced with it. Google also states that it does not guarantee that markup will produce a particular video feature, so the same caution applies to anything you hope a transcript will do in search.
| Claim | What the sources say | How to phrase it |
|---|---|---|
| Captions are required | SC 1.2.2 requires them for prerecorded audio in synchronized media, with a labeled-alternative exception | An accessibility requirement |
| A transcript is required | SC 1.2.1 requires an equivalent alternative for audio-only and video-only content | Depends on the media type |
| Captions or transcripts raise video rankings | No statement in Google's video documentation | Do not claim it |
| Text makes content easier to find | Listed under the benefits of SC 1.2.1 | A findability benefit for readers |
Decision rule: classify the media first (audio plus video, audio only, video only), then apply the matching criterion, then check the on-page-text exception clip by clip. Add a full transcript to an audio-plus-video page as a reader benefit when the video says more than the page text does.
Where the transcript lives on the page
Neither WCAG nor Google dictates the layout, so these are practical suggestions with trade-offs.
A collapsible block under the player
The transcript sits in a headed section that is closed by default. The page stays compact. The trade-off is discoverability: a clear label such as "Show transcript" works better than a vague "More", and the control must work with a keyboard and announce whether it is expanded.
Plain text in the page body
For interviews and podcast episodes, where the speech is the content, put the text straight into the page. There is nothing to click, so nothing to miss. The cost is length, which is why short product clips are better served by the collapsible block.
A separate transcript page
A dedicated transcript page adds a step for the reader and a relationship to manage between two URLs. Google defines a watch page by its main purpose of showing one video, and a transcript URL beside it does not undermine that purpose, but the reader still pays one more click. Practical suggestion: keep this option for very long, chaptered recordings, and leave a short summary and an obvious link on the video page.
Producing captions in more than one language
A single video file can serve several languages, but every language needs its own captions and its own transcript.
One language per page, one track per language
Google's guidance on multilingual sites asks you to use one language for the content and navigation of each page and to avoid side-by-side translations. Applied to video, an English page carries English captions and an English transcript, and a Turkish page carries Turkish ones. Putting both texts in one block muddles the page language. Linking the two language versions of the page to each other is a separate task covered by Google's localized versions documentation.
Because caption conventions differ by language, a translated track should be reviewed by someone fluent in the target language. Timing that works for one language can be too fast for another, and a line that breaks neatly in English can break awkwardly elsewhere.
Automatic drafts and human review
No source cited here measures how accurate automatic caption tools are, so a blanket verdict in either direction would be invented. What the sources do give is the test: failure F8 is captions that omit important dialogue or sound effects. A draft from any tool, human or automatic, passes only if it is complete.
Practical suggestion: treat machine output as a first draft. Keep a glossary of product names, acronyms and numbers, correct against it, mark speaker changes, and write meaningful sounds in brackets, for example a notification chime that tells the viewer a step has finished.
A pre-publication checklist
- Is all of the dialogue present, with no skipped sentences?
- Are speaker changes shown?
- Are meaningful non-speech sounds written down?
- Do the captions avoid covering important on-screen information?
- Are names, product terms and numbers correct?
- Has each language version been reviewed in that language?
- Is the transcript headed, readable and searchable on the page?
- Do audio-only and video-only items have an equivalent alternative?
- Has the on-page-text exception been checked for each clip that relies on it?
- Do the page title, VideoObject data and thumbnail match the current video?
Building the habit into publishing
A checklist helps only when someone owns each line. The goal is to make captions and transcripts a normal step, not a rescue task before launch.
Who does what
- Editor: drafts the script or talking points when the video is planned, so a text source exists from the start.
- Producer: delivers the caption file with the final cut, not afterwards.
- Language reviewer: checks each language version.
- Developer: attaches caption tracks to the player, builds the transcript component and keeps structured data aligned with the page.
- SEO owner: confirms the watch page is indexable and its title and description are unique.
Practical suggestion: a written script makes a better transcript than a transcription of an improvised talk, because speech needs more cleaning than prepared text. For unscripted recordings, book review time after the recording.
Example scenario: a software company's webinar library
Example scenario: A software company records a monthly webinar. Each recording has two speakers, a screen-share section where the presenter narrates clicks, and a short audio-only podcast cut for people who listen on the move. The site is published in English and Turkish.
The team classifies the assets first. The full webinar is audio plus video, so it needs captions under 1.2.2. The podcast cut is audio-only, so it needs a transcript under 1.2.1. A silent twenty-second loop that shows a settings screen is video-only; since a nearby paragraph already lists the same settings, the team writes down why the exception applies and revisits it if the paragraph changes.
Speaker names go into the captions whenever the speaker changes, and the chime that signals the end of a demo is written as a bracketed sound cue. The English page gets an English transcript below the player in a collapsible block, and the Turkish page gets a Turkish one written from the Turkish recording rather than pasted from English, because the Turkish session covered a different customer question. The team does not expect a ranking change. It watches whether support questions about the demo steps decline and whether visitors open the transcript section.
Maintenance after launch
When a video is replaced, captions and transcript must be replaced too, otherwise the page describes a version that no longer exists. Keep a change log per video, and after re-uploading a caption file check that the correct language track is selected by default for the page language.
Transcript headings must also respect the page outline, so a long transcript does not break the structure; see the notes on heading structure for SEO and accessibility. Long transcripts read better with the habits in the readable content formatting guide: short paragraphs, descriptive subheads and lists where the speech lists things.
Technical visibility and other channels
Captions and transcripts do not stand in for the technical side of video visibility. Watch page indexability, stable thumbnails and video sitemaps are covered in the video SEO and YouTube guide, and the two topics complement each other. If your speakers also appear on other sites, the approach in podcasts, webinars and guest appearances for brand and links pairs naturally with a prepared script and a clean transcript, since a guest recording is audio-only or synchronized media in the same sense as your own.
Seven steps to start
- Inventory every prerecorded video and audio file and mark its type: audio plus video, audio only, video only.
- Assign the matching criterion, 1.2.2 or 1.2.1.
- Pull out clips that repeat page text and test the exception honestly.
- Choose how captions will be produced and who reviews them.
- Add a transcript component to the page template, with a heading and a language rule.
- Align VideoObject data with the current page content.
- Write the caption and transcript steps into the permanent publishing checklist.
The last step is the one that gets skipped. Without it every new video becomes a one-off decision.
Three assumptions to drop
First, "captions are for accessibility and transcripts are for SEO". WCAG ties both to access, and Google's video page mentions neither. Second, "automatic captions are good enough" or "never good enough". The sources offer no such measure; the measure is completeness. Third, "we did it once". A new video, a new language or a new player calls for a fresh check.
Standards and Google documentation can change, so check the current W3C and Google pages before you rely on a detail; the criteria discussed here come from the WCAG 2.2 Understanding documents.
Frequently Asked Questions
What is the difference between captions and a transcript?
Captions show dialogue and meaningful sounds as timed text while the video plays. A transcript is plain text on the page that can be read from start to finish, with or without timing. In WCAG, captions fall under SC 1.2.2 and the equivalent text alternative for audio-only or video-only media under SC 1.2.1, and one does not replace the other.
Does publishing a transcript improve video rankings?
Google's video best practices page does not mention captions or transcripts, so a ranking claim has no support there. WCAG notes that text makes non-text content searchable and easier to repurpose. Publish transcripts for readers and access, and treat any search effect as unproven.
Does a silent product video need captions?
With no speech there is nothing to caption, but SC 1.2.1 still applies: video-only content needs either a text alternative or an audio track with equivalent information. If the video only repeats text already on the page, an exception can apply, which you should confirm clip by clip.
Are automatically generated captions enough?
WCAG does not specify how captions are produced. It expects them to carry the dialogue and meaningful sounds, and it lists captions that omit important dialogue or sound effects as failure F8. Practical suggestion: use automatic output as a draft and review it before publishing.
Do I need separate captions and a separate transcript for each language?
In practice, yes. WCAG notes that caption conventions vary by language, and Google's multilingual guidance asks for one language per page without side-by-side translations. Have each language version reviewed by someone fluent in it.
Should captions be burned into the video or supplied as a file?
WCAG accepts both. Open captions cannot be turned off, while closed captions can be toggled in the player. Practical suggestion: a separate file is easier to correct and to offer in several languages, but the choice depends on your player.
Conclusion
Captions and transcripts serve different readers at different moments, and both exist so that content reaches the people it is meant for. WCAG 1.2.2 asks for captions on prerecorded audio in synchronized media, and 1.2.1 asks for an equivalent alternative for audio-only and video-only content, while Google's video documentation stays silent on both. Work in this order: classify the media, apply the matching criterion, check the on-page-text exception per clip, review every language version in its own language, keep the transcript and VideoObject data consistent with the page, and write the steps into your publishing checklist. None of it carries a ranking guarantee, and the cited pages are worth rechecking for current wording.
If you want an editor to prepare video scripts, transcripts and multilingual page copy, Akua Adforce offers content writing; scope and terms are listed on the product page.
Post a comment
Please log in to leave a comment. Login