A transcript is a text version of a recording. Writing a useful one means deciding who it is for, then capturing what a listener hears and, if needed, what a viewer sees.

Choose a basic or descriptive transcript

W3C describes a basic transcript as a text version of the speech and the non-speech audio needed to understand the content. It helps people who are Deaf or hard of hearing, and anyone who prefers to read.

A descriptive transcript adds visual information. W3C says it is needed to give audio and video content to people who are both Deaf and blind. If your video shows something the speaker never says, such as a chart, on-screen text or an action, you need the descriptive kind.

Start from captions if you have them

W3C notes that captions and transcripts include the same text, so one can be used to develop the other, and that most caption-editing tools can export a plain text transcript. Captions are shown inside the player in sync with the audio; a transcript is a separate text document.

An export is a first draft, not a finished transcript. Read it against the recording and add what captions leave out, such as speaker names and visual description. If a tool or an AI service produced the text, check it against the audio as you would check any machine output.

What to include

Leave out sounds that add nothing. A door closing matters if the next line is “Who’s there?”; it does not matter otherwise.

  • Speaker identification: say who is speaking, especially when there is more than one voice. W3C suggests bold names or hanging indents to make this easy to skim.
  • Non-speech audio that matters: sound effects, music cues or ambient noise that a listener needs to follow the content.
  • Visual information: on-screen text and significant visual context, for a descriptive transcript.
  • Logical structure: W3C advises putting the information in paragraphs, lists and sections rather than one block.
  • Timestamps only when useful: W3C treats them as optional and warns against clutter.

A fictional example

Imagine a 30-second fictional video called “Three file names”. A short descriptive transcript might read:

Visual: A folder window shows three files, update-final, update-final-new and update-actually-final. Narrator: “Which one is current? Nobody can tell.” Visual: The cursor hovers over each file in turn. Sound: A soft chime. Visual: One file is renamed to 2026-10-12_update_v3. Narrator: “Put the date and version in the name.”

The scenario is invented for illustration. Without the visual lines, a reader who cannot see the screen would never learn what “nobody can tell” refers to.

Put it where people will find it

W3C recommends placing the transcript right under the media on the same page when possible, so readers do not have to hunt for it. Give it a heading, and say in the page text that it exists.

If a transcript is long, use headings and short paragraphs so it can be scanned. A table with audio and visual columns is another option W3C mentions for descriptive transcripts.

Check it before publishing

This checklist is our suggested routine based on W3C’s guidance. It is not a conformance test, and a transcript does not replace captions, which are shown in the player in sync with the audio.

  • Does every speaker line say who is talking?
  • Could someone who cannot hear the recording follow it from the text alone?
  • Could someone who cannot see it understand the visuals the speaker does not mention?
  • Did you read it against the recording, not just run a tool?
  • Is it on the same page as the media, under a clear heading?

Sources & context

Sources checked on 11 October 2026. Worked examples are fictional; the suggested checklists are editorial advice.

Use this next

Keep exploring

Use the free tools