SDH vs Closed Captions: What to Deliver

"Closed captions" names a switch. "SDH" names what is in the file. Teams collapse the two, then ship one speech-only transcript to a broadcast ingest, a website <track>, and a muted TikTok cut, and wonder which destination bounced.

SDH (subtitles for the deaf and hard of hearing) is a content standard: dialogue plus speaker identification plus non-speech audio that a d/Deaf or hard-of-hearing viewer needs. Closed captions, in WCAG's own definition, are captions that can be turned on and off. Open captions cannot. Neither word tells you whether the text includes [laughter]. That is the SDH question, and it is the one auto-caption jobs skip.

Two axes: content and carriage

Content is what the words cover. Carriage is how those words travel with the picture.

Content

	Dialogue-only (sometimes called "subtitles")	SDH
Speech	Yes	Yes
Who is speaking	Rarely	Yes, when it is not obvious from the picture
Non-speech (music, laughter, a door, a siren)	No	Yes, when it is needed to understand the media
Who it is for	Hearing viewers who do not know the language	d/Deaf and hard-of-hearing viewers, and anyone who cannot hear this mix

WCAG's definition of captions is the SDH column, not the dialogue-only column. Captions "convey not only the content of spoken dialogue, but also equivalents for non-dialogue audio information needed to understand the program content, including sound effects, music, laughter, speaker identification and location." A file that is only the words is a subtitle track. Calling it captions does not make it one.

Carriage

	Closed	Open (including burned-in)
Viewer can turn it off	Yes	No
Survives a player with no caption engine	Only if that player implements the format	Yes; it is pixels
Restyle, language swap, search index	Yes, if the format holds text	No; re-render the picture
Typical home	Broadcast, YouTube, HTML5 <track>	TikTok, Reels, Shorts, any re-upload

You can ship SDH as closed captions (a WebVTT with speakers and [music] that the player toggles). You can ship SDH as open captions (the same words burned in). You can ship closed captions that are not SDH (a speech-only .srt on YouTube). The last one is the usual accident.

US broadcast quality rules do not let you hide in that accident. 47 CFR 79.1 requires television closed captioning to be accurate, synchronous, complete, and placed so it does not block important visual content. Completeness, in that section, includes speaker identification and non-speech information. Offline (pre-recorded) captioning is supposed to be a complete textual representation of the audio. A dialogue-only file is not that.

608/708 for US broadcast, WebVTT for the web

Carriage on television is not a sidecar you attach in a CMS.

• CEA-608 (also called EIA-608, Line 21) is the analog caption channel. Digital plants still carry a 608 compatibility service because a lot of downstream gear still expects it.
• CEA-708 / CTA-708 is the digital TV caption standard: more channels, more styling, still inside the video essence or the MPEG user data, not a loose text file.
• Ingest specs for US networks and MVPD plants ask for 608 and 708 together more often than they ask for a .vtt.

You do not "save as 708" from a social caption preset. A caption house or a broadcast encoder maps a timed-text master into 608/708. If the timed-text master was dialogue-only, the 608/708 output will be dialogue-only, and it will fail the completeness bar in 79.1 even if the packets are valid.

The web is the other stack:

• WebVTT is the format HTML5 <track> reads. The WebVTT spec covers captions, subtitles, and other timed text. Use kind="captions" for SDH, kind="subtitles" for translation-style dialogue tracks, with srclang and a human label ("English SDH", "Spanish").
• SRT will move words and times. It will not reliably move italics, positioning, or voice tags. Fine as an interchange scratch file. Poor as the only web deliverable if you need SDH styling.
• TTML / IMSC shows up in some streaming and IMF plants. If a spec names it, deliver it; do not substitute VTT and hope.

YouTube, Vimeo, and most site players want a text track they can toggle. They do not want 608 packets. A landing-page <video> that never gets a <track> is a player problem, not a 708 problem.

Versely's caption tools sit on the open-caption side of this split: styled, auto-transcribed captions burned into the frames, which is the right object for a muted feed. They are not a 608 encoder and they are not a WebVTT exporter. For a sidecar, take a plain transcript (speech-to-text, not a finished SDH file), edit in speakers and non-speech, and author the VTT the embed will load. The burned-in versus sidecar rule still holds: decide per destination, then pick content and carriage.

A delivery matrix so you stop shipping one file

One source script. Several packages. The source is an SDH timed-text master (speakers, non-speech, times). Everything else is a render of that master.

Destination	Content	Carriage	What you hand over	What you do not hand over
US linear / MVPD	SDH (FCC completeness)	608 + 708	Broadcast caption file or encoded essence per the ingest spec	A .srt from an auto-captioner
Site embed, HTML5	SDH	Closed WebVTT, kind="captions"	.vtt plus a player that loads it	608 packets; a VTT the component never references
YouTube / Vimeo long-form	SDH	Closed sidecar the host accepts (often VTT or SRT you then enrich)	Uploaded caption track, language set, not disabled	Burn-in as the only captions (kills off-switch and translation)
TikTok / Reels / Shorts	Speech as design, SDH if you can still read it	Open (burn-in)	Styled burn-in, contrast-safe	A closed track nobody in the feed will enable
Paid social that re-encodes	Same as short-form	Open	Burn-in	A sidecar the ad platform strips
Localization	Translated SDH, not a re-transcript of a dub	Closed VTT per language; burn-in per language if the dest is a feed	One VTT per language from the master	The English VTT renamed

Authoring order that does not fight itself:

1. Finish picture and mix. Captioning a temp VO wastes the job.
2. Get speech text. In Versely, that is automatic subtitles for a burn-in preview, and a plain transcript for the sidecar master. Auto-caption presets style the open-caption pass; they do not insert speaker IDs.
3. Edit the text into SDH: speakers, [laughter], music, off-screen italics. That pass is the master.
4. Package from the master: VTT for web, 608/708 via a broadcast path, burn-in for feeds.
5. Never reverse the order (do not OCR burn-in to make 708).

If a client says "just send the captions," ask which row of the table they are ingesting. If they say "the SRT is fine for NBC and the website," it is not. The caption generator is the speech-to-burn-in tool. Speech-to-text is the tool that gives you editable words. Neither is a 708 encoder. Name the missing vendor rather than pretending one export covers the matrix.

FAQ

Is SDH the same as closed captions?

No. SDH is what the text contains. Closed captions are how the text is presented (toggleable). An SDH track can be closed or open. A closed track can be SDH or dialogue-only. WCAG and FCC completeness both expect the SDH column whenever the word "captions" is doing accessibility work.

Can I use one WebVTT for broadcast by converting it to 608?

You can map a complete SDH timed-text master into 608/708. You cannot treat a web VTT as broadcast-ready because it opened in a browser. Character sets, positioning grids, pop-on vs roll-up, and the dual 608+708 payload are plant problems. Budget a caption house or an encoder that names 608/708 in its spec.

We already burn captions in for social. Do we still need SDH sidecars?

For the feed, burn-in is the presentation that actually shows up. For YouTube long-form, a site embed, or a TV ingest, you still need a closed, complete track. The burn-in job does not produce that track. Keep the SDH master and package twice.

Does kind="subtitles" on a WebVTT pass WCAG 1.2.2?

Not if that track is the only one and it is dialogue-only. 1.2.2 asks for captions. In HTML, that is kind="captions" with speech and non-speech. A kind="subtitles" track is the right label for a translation. Mislabeling a speech-only file as captions is how audits fail after the file "was uploaded."