Captions and audio description: source to screen

Can your viewer still select captions and audio description after the channel switches to backup? A healthy picture and audio meter cannot answer that question. Accessibility depends on assets, timing, conversion and player behaviour surviving every handoff.

For broadcast engineers, the useful starting point is a traceable test programme. Give it identifiable dialogue, sound cues, caption positions and described action. Follow those features from the approved master to a television, browser and mobile player. A track appearing in a manifest is only one checkpoint.

Map captions and audio description through the chain

Captions carry dialogue plus relevant sounds and speaker information for deaf and hard-of-hearing viewers. Translation subtitles may carry dialogue alone. Audio description adds spoken information about visual action. W3C’s accessible-media guidance explains these distinct services. Preserve their purpose in your metadata and player labels.

Record the programme and edit identifiers, language, caption format, service number, timebase and described-audio arrangement. Include the expected output at each destination. Our multilingual channel checklist covers release ownership; the engineering task here is to prove that each transformation preserves the intended service.

Source and playoutApproved edit, caption service and described-audio tracks

Encode and packageConvert text, preserve timing and signal track purpose

Delivery and playbackFetch, select, render and listen on target devices

Caption text and audio can travel separately from pictures. This simplified chain shows where to verify them; an actual service may include an ad stitcher and several distribution partners.

Check what caption conversion preserves

An incoming broadcast feed may carry CEA-608 or CEA-708 captions. Streaming outputs may retain embedded captions or use separate WebVTT or IMSC text tracks. The W3C IMSC 1.3 specification defines a constrained TTML text profile for subtitles and captions. Use the profile accepted by your destination; newer specifications do not establish older-device support.

Build a conversion matrix for the actual encoder and packager. Test service selection, accented characters, speaker cues, line breaks, placement and overlapping cues. A converter can produce valid syntax while changing presentation. Compare the rendered output with the approved reference, including captions positioned away from lower-third graphics.

Check timing after edits and frame-rate changes. In a hypothetical example, a replacement master removes 12 seconds before the second act while its sidecar captions still reference the earlier edit. Both files may pass independent validation. Their pairing fails from that cut onward.

For segmented WebVTT in HLS, check the relationship between cue time and the media timeline. RFC 8216 defines the timestamp mapping and segment requirements. Exercise discontinuities and timestamp wraparound where relevant, rather than assuming that matching durations proves synchronisation.

Make described audio playable

Establish whether the delivery contains a complete programme mix with description or a separate narration component that needs receiver-side mixing. EBU’s HbbTV accessibility report distinguishes these approaches. A narration-only track selected as ordinary alternative audio can leave the viewer without programme sound.

For a complete described mix, test dialogue intelligibility, narration balance, loudness, channel layout and synchronisation against the picture. For supplementary narration, verify that the intended receiving system supports the required association and mixing. Document supported devices and any fallback explicitly.

Apple’s HLS authoring specification specifies signalling for accessibility audio and subtitles on its devices. Use those requirements for that delivery path, then test each other target platform against its own requirements. A language label alone cannot identify the purpose of a track.

Inspect what the manifest tells the player

In HLS, inspect the relevant rendition groups and attributes such as LANGUAGE, NAME, DEFAULT, AUTOSELECT and CHARACTERISTICS. Confirm that variants reference the correct groups and every referenced resource is available. Distinguish forced subtitles from the full accessibility service.

In DASH, review the MPD’s language, role and accessibility descriptors alongside the subtitle format and audio adaptation sets. DASH-IF’s text interoperability guidance distinguishes caption and subtitle signalling. Treat HLS and DASH as separate acceptance targets; a correct HLS playlist provides no evidence about the DASH presentation.

Then use the player controls. Check understandable labels, manual selection, system accessibility preferences and whether the selection survives quality changes, seeking and returning from an advertisement. Include at least one real television platform. Desktop playback alone leaves a large compatibility gap.

Test the junctions that a clean clip misses

Run the test programme through a live insert, an ad break and primary-to-backup switching. Server-side ad insertion changes the media sequence the viewer receives. Check that captions from the programme do not linger over an advertisement and that returning content resumes on the right timeline.

Agree how accessibility is handled during advertisements and promotions. A programme with excellent captions can still lead into inaccessible advertising. Record the expected behaviour when an asset lacks captions or a described mix, and make unresolved gaps visible to the service owner.

1. 1
   Select and establish a baseline

   Enable captions and description. Compare timing, text and sound with the approved master.

2. 2
   Cross an ad break

   Check outgoing cues, advertisement accessibility and the returning programme's timing.

3. 3
   Switch delivery paths

   Trigger the agreed backup test and verify track identity, continuity and selection.

4. 4
   Save viewer evidence

   Record device, app version, manifest, selected tracks and the observed failure or pass.

This is an illustrative test sequence. Agree acceptable timing and presentation tolerances with the receiving platform and accessibility reviewers.

Keep evidence after launch

Automate checks for missing resources, unexpected track changes and timing anomalies. Pair those checks with scheduled viewing and listening, including feedback from people who rely on these services. A parser cannot establish whether a description communicates the important action clearly.

Captions and audio description need the same change control as pictures and sound. Repeat affected tests when an encoder profile, packager, ad workflow or player changes. Discuss your delivery requirements with the Evrideo team and agree the accessibility acceptance tests before taking a channel to air.