Name the communication job before the format
A video brief often starts with a channel, duration and aspect ratio. An accessible production brief also asks what information a person must get from the piece, what arrives through sound or image, and what alternatives the published experience needs. That changes choices upstream: a title card can be read aloud, an important visual can be described in the script, and a transcript can be planned as a deliverable rather than reconstructed later. This is an analytical exercise, not a report of a client production.
W3C’s media guidance recommends planning accessibility from the start and includes requirements from WCAG. Its planning material separates prerecorded media from live media, and distinguishes audio-only, video-only and synchronized video with audio. Those categories matter because requirements differ. For example, WCAG 2.2 Success Criterion 1.2.2 requires captions for prerecorded audio in synchronized media at Level A; 1.2.5 requires audio description for prerecorded video at Level AA. [1] A campaign team should identify the relevant format and applicable standard with the organization responsible for the site; this article is a production workflow, not a legal determination.
Storyboard information, not just shots
For each planned scene, write down the message a viewer needs to understand and where that information appears. Dialogue may explain a product benefit, while a close-up, chart, name label or demonstration may carry another part of the argument. If the visual adds meaning that the narration does not say, consider whether the script can integrate a concise description in a natural pause. W3C’s guidance notes that integrated description is easier to include before filming and identifies charts, on-screen titles and other meaningful visual details as possible description needs. [2]
Imagine a fictional 30-second product demonstration: a hand presses a control, a small status light changes, and a title card names the feature. A storyboard note can say that the light changes from amber to green and the card displays the feature name. The writer can then decide which details belong in spoken narration, which need an audio-description track or descriptive transcript, and which can be made available as adjacent text. The example is a planning exercise, not evidence about a real product or audience.
Treat captions and transcripts as separate checks
Captions are not just a transcript pasted over the image. W3C defines them as a synchronized text alternative for speech and non-speech audio needed to understand the media; they can include speaker identification and meaningful sounds. [3] This makes a caption review an editorial task as well as a timing task. Check names, technical terms, punctuation, speaker changes and sounds that change the meaning. Then preview the captions against the image: placement should not cover a button, an important label or a face whose expression carries meaning.
A transcript serves a different reading situation. W3C recommends captions and a separate transcript, and describes a descriptive transcript as including visual information as well as audio. Caption text can provide a starting point, but a transcript needs its own review for visual details, scene changes, links and readable structure. Translated subtitles also have a different job from captions: translation helps someone read another language, while captions convey relevant audio information for people who cannot hear it. Do not count one file as proof that every access need is covered.
Put access into the production handoff
A useful handoff names the owner and acceptance check for each asset: the final master, caption file, transcript, any needed described version, thumbnail, embed and destination page. Include the delivery format and the review stage in the schedule. Ask the editor to leave room for description, capture clean dialogue, identify speakers, and note significant sounds while the footage is fresh. Ask the web producer to confirm that the chosen player exposes controls and captions, works with the keyboard, and keeps the transcript close to the video and its next action. W3C’s workflow assigns work across writers, producers and web developers, which is a reminder that no single export setting completes the job. [2]
A final review can follow the audience journey: start playback, enable captions, pause and resume, navigate by keyboard, locate the transcript, then read the page without playing the video. Verify that the call to action still makes sense if the video is unavailable. These checks do not substitute for a conformance audit, assistive-technology testing or feedback from people with disabilities. They catch production and publishing gaps while the team can still correct them.
Make the creative idea stronger through the constraints
Access requirements can improve the brief’s clarity. When the benefit must be understandable in words as well as pictures, the team has to decide what the benefit actually is. When a chart needs description, its labels and takeaway need to be legible. When a transcript accompanies a video, the page has another useful route into the same information. These are design opportunities, not a promise that accessibility automatically improves campaign performance.
The practical lesson is to assign access work at concept, script, edit and publishing stages. Make a small deliverables matrix, test the actual player and page, and record unresolved issues before release. A video is a production system: script, image, sound, captions, text and interface work together. Planning them as one experience is more reliable than asking the last person in the chain to repair what the brief never considered.
Sources & useful references
- W3C: Web Content Accessibility Guidelines (WCAG) 2.2, Time-based Media criteria
- W3C WAI: Planning Audio and Video Media
- W3C WAI: Captions/Subtitles
Results are attributed to the original publisher. Proposed tests and creative recommendations are our analysis.