Accessibility & Standards

Transcript

Definition

Two kinds are worth naming. A basic transcript contains everything said, with speaker labels and notes on meaningful sound. A descriptive transcript adds the visual content — what the slide says, what the demonstration does, what a chart shows — so that someone who cannot see the video still gets the whole thing. WCAG asks for a transcript for prerecorded audio-only and video-only content under success criterion 1.2.1 at Level A. For prerecorded video with sound, 1.2.3 at Level A lets you satisfy the requirement with either audio description or a full text alternative, and 1.2.8 at Level AAA asks for a descriptive transcript outright. A transcript is not a substitute for captions: captions are synchronised and serve someone watching, a transcript is a document and serves someone reading.

Why It Matters

Transcripts do work no other format does. They are the only route for a deaf-blind reader, who takes them on a braille display. They let anyone skim a forty-minute talk in two minutes and find the one part that matters, which captions cannot do. They are also indexable: speech runs at roughly 130 to 150 words a minute, so a twenty-minute episode is around 2,600 to 3,000 words of text that a search engine can read, against an audio file it cannot. Publishing the transcript as HTML on the page rather than as a PDF download keeps all of that — a PDF is a second click, a second file, and often a worse reading experience on a phone.

How It Works

The cheapest route starts from captions you already have: strip the timestamps from a WebVTT file, join the cues into paragraphs, add speaker names, and you have a basic transcript. If there are no captions, run automatic speech recognition and then correct it by hand — plan on roughly an hour of editing per hour of audio for a careful pass, more for multiple speakers. Turn it into a descriptive transcript by adding bracketed notes for anything visual that carries meaning. Then structure it like a document: headings for sections, paragraphs rather than one block, speaker names in bold, and timestamps every minute or so if people will use it alongside the recording. Published as plain HTML, it costs a few kilobytes.

Real-World Example

A podcast publishes episode 14 as 'ep14.mp3' at podcast.99helpers.site, with the transcript as an HTML page in the same folder linked directly beneath the player. The audio is 22 minutes and the transcript runs to about 3,100 words, or 19 KB of HTML — under a thousandth of the size of the 21 MB audio file, and the only part of the episode a search engine can read. Listeners who prefer to skim use the section headings; one reader takes it on a braille display. 99helpers hosts both files as static assets and does not transcribe anything, so the text comes from a transcription service and is uploaded alongside the audio.

Common Mistakes

  • Treating a transcript as a replacement for captions — they serve different people in different moments, and WCAG asks for both in the common case of prerecorded video with sound
  • Publishing a wall of unbroken text — without headings, paragraphs and speaker labels, a transcript is technically present and practically unusable
  • Leaving out what happens on screen — if the presenter says 'as you can see here', a transcript with no description of the slide has lost the point
  • Shipping it only as a PDF — an HTML page on the same URL is lighter, easier to read on a phone, and reads better to a search engine

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →