Briefing accessible project videos: a buyer's requirements worksheet

1. Identify the requirement and who can confirm it

Start with the people who will watch or use the content and the places it will appear. Your organisation or client may have a specified accessibility standard or procurement requirement. Obtain the actual wording rather than asking a production team to infer it.

• Audience and known access needs:
• Film, short versions and languages proposed:
• Website, intranet, social channel or presentation destination:
• Organisation or client requirement, including its version:
• Person authorised to interpret that requirement:
• Person responsible for reviewing accessibility:
• Questions requiring specialist advice:

The W3C planning guidance distinguishes different media types and accessibility features. Use it to structure the conversation, then confirm the requirements applicable to your content. A checklist for a recorded film should not be reused unchanged for a live event.

2. Specify what captions must communicate

Captions provide a synchronised text version of speech and meaningful non-speech audio. They are more than a decorative line summarising an interview. W3C also warns that automatic captions need to be checked for accuracy. Read its caption guidance.

Prepare a spelling list for project names, people, organisations and technical terms. Identify who can resolve a word that is unclear in the recording. Discuss how relevant sounds and speaker changes should be represented.

Record:

• Versions requiring captions:
• Required language or languages:
• Caption delivery and destination requirements:
• Whether viewers need captions that can be switched on and off:
• Person checking spelling, meaning and timing:
• Person checking caption placement against graphics:

Ask whether a separate caption file is needed and which format the publishing system accepts. Captions embedded permanently in the picture and a switchable caption track behave differently. Confirm the intended arrangement rather than assuming one export will suit every destination.

3. Find meaning that exists only in the pictures

A project film may communicate important information through a plan, a before-and-after comparison, a speaker's name or a view of the completed space. Someone who cannot see those details needs another way to understand the relevant meaning.

W3C's description guidance explains approaches including description integrated into the main audio and separately described versions. Discuss the appropriate approach before filming or locking the edit.

Make a visual-information list:

• Essential information shown on screen:
• Is that information already clear in the spoken content?
• Proposed way to communicate any missing meaning:
• Script, interview prompt or edit decision needed:
• Person checking accuracy:
• Required output or version to confirm:

For a fictional example, an interviewee says “we changed this area” while a drawing highlights a relocated entrance. The drawing carries the explanation. A preparation note could ask the speaker to explain which entrance moved and why, without relying on the viewer seeing the highlight. The production team can then assess what further description is needed. This is an invented example, not a completed accessibility assessment.

4. Decide what text alternative is needed

A basic transcript records speech and relevant audio information. A descriptive transcript also includes important visual information. These are different outputs from a timed caption track, as W3C's transcript guidance explains.

Ask which text alternative your audience and requirements call for, where it will be available and who maintains it. A draft interview transcript may contain unused material and should not be mistaken for a transcript of the approved edit.

• Transcript type required:
• Approved edit version it will match:
• Person preparing and checking the text:
• Where viewers will find it:
• Publisher and update owner:
• How later edit changes will be reflected:

Do not treat the presence of a transcript as proof that all other accessibility requirements have been met.

5. Include the destination and its owner

The production files and the viewing experience need separate attention. A website publisher may control the player, caption upload and surrounding page, while the production team controls the agreed film outputs.

W3C's media-player guidance identifies considerations including keyboard operation, visible keyboard focus, clear control labels and support for accessibility features. Give the publisher responsibility for checking the actual player and embed, rather than accepting a file-folder check as evidence that the published experience works.

Record the destination, publisher, required tracks or text, player checks and person resolving issues. If someone outside your organisation manages the page, establish the handover requirements before agreeing delivery.

6. Put acceptance checks into the scope

Make one entry for each requested feature or output:

• Requirement and reason:
• Exact film or version affected:
• Supplier or internal owner:
• File, text or publishing work required:
• Reviewer and proposed check:
• Stage when the check must happen:
• Status: agreed, unresolved or outside current scope:

Allow the review plan to cover the final edit and the actual destination. Check specialist names and meaning, important visual information, consistency between versions and whether the agreed features are available where viewers will use them. Ask the accessibility reviewer what further assessment is needed; these planning checks are not a substitute for a full evaluation.

When publication is ready, use the publishing handover checklist to record approved files, destinations and responsible people.