---
title: "Captions, subtitles and audio descriptions for workout video"
canonical: "https://aifitnessapi.com/accessibility/captions-for-workout-video"
cluster: "Accessibility"
primary_query: "captions for workout videos"
last_reviewed: "2026-08-22"
description: "Apple defines four media alternatives. A demo video's information is visual, so audio description is the one fitness libraries skip and need most."
publisher: "AIFitnessAPI — independent, not sponsored"
cite_as: "\"Captions, subtitles and audio descriptions for workout video\", AIFitnessAPI, https://aifitnessapi.com/accessibility/captions-for-workout-video"
---

# Captions, subtitles and audio descriptions for workout video

> Apple's Human Interface Guidelines define four distinct alternatives and a fitness library usually needs more than one: captions give the textual equivalent of audible information, subtitles let people read live onscreen dialogue in their preferred language, audio descriptions are interspersed between natural pauses in the main audio and supply spoken narration of important information presented only visually, and transcripts give a complete textual description covering both audible and visual information. Captions fix a coach's voiceover, but an exercise demo carries its information in the picture, so a blind user gets almost nothing from a soundtrack of breathing and music. That makes audio description the alternative this category cannot skip, and the script is usually close to what a good coach already says while demonstrating. This page is written from Apple's guidance only: we could not verify Android's captions API surface in this pass and describe none of it.

- Canonical: https://aifitnessapi.com/accessibility/captions-for-workout-video
- Last reviewed: 2026-08-22
- Publisher: AIFitnessAPI (https://aifitnessapi.com) — independent, not sponsored
- Cite as: "Captions, subtitles and audio descriptions for workout video", AIFitnessAPI, https://aifitnessapi.com/accessibility/captions-for-workout-video

---

A workout demo is a video whose information is almost entirely visual. Somebody sets up for a hinge, the camera holds a side view for three reps, and the soundtrack is breathing and eight bars of music. Mute it and a sighted user loses nothing. Turn off the picture and there is nothing left at all.

That asymmetry is why captioning a fitness library and calling it done is the standard mistake in this category. Captions fix the coach's voice. They do nothing for the part of your product that is a person demonstrating a movement in silence.

This page is engineering guidance, not a legal position; [compliance](/compliance) owns that layer.

## Apple's four terms, quoted, because the distinctions matter

Apple's [Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/accessibility) open the media section with the principle: "It's important that dialogue and crucial information about your app or game isn't communicated through audio alone." Then they define four separate things, and teams routinely collapse them into one line item on a backlog.

> "Captions give people the textual equivalent of audible information in video or audio-only content."

> "Subtitles allow people to read live onscreen dialogue in their preferred language."

> "Audio descriptions are interspersed between natural pauses in the main audio of a video and supply spoken narration of important information that's presented only visually."

> "Transcripts provide a complete textual description of a video, covering both audible and visual information."

Read them as four different jobs rather than four synonyms. Captions carry audible information into text. Subtitles carry dialogue across languages. Audio descriptions carry visual information into sound. Transcripts carry everything into text.

| Your content | What it needs first | Why |
| --- | --- | --- |
| Coached class with continuous voiceover | Captions | The instruction is audible; text is the equivalent Apple describes |
| Silent exercise demo loop | Audio description, then a transcript | There is no audible information to caption. The content is the picture |
| Cue-heavy strength video with counting | Captions plus audio description | Both channels carry different halves of the same set |
| Class you ship in several languages | Subtitles | Apple's definition is specifically about dialogue in a preferred language |
| Warm-up with music and on-screen text only | Transcript | Text burnt into the frame is a picture of text to everything except an eye |

## Audio descriptions are the one this category cannot skip

Apple's definition sets a constraint you have to design around: audio descriptions are "interspersed between natural pauses in the main audio of a video". A demo loop is nothing but natural pauses, which sounds easy and is not, because the description then has to carry the whole exercise: the start position, what moves, what stays still, the tempo, and where the rep ends.

The useful discovery for most teams is that this script already exists in draft form. It is what a competent coach says out loud while demonstrating. "Feet hip width, bar over mid-foot, hinge back until you feel the hamstrings, chest stays up, drive the floor away." Written down, that is an audio description, and it is also better coaching for the sighted user with the phone propped on a bench two metres away. Producing it is usually a scripting job rather than an accessibility engineering job, which is worth knowing before somebody scopes it as the latter.

Two failure modes to avoid. Do not describe the video, describe the movement — "the trainer smiles and picks up a dumbbell" is a caption of the wrong thing. And do not let the description depend on visual references the listener has no access to, such as "like the last one" or "as shown on the left".

Transcripts are the cheapest artefact of the four and the one Apple defines most broadly: a complete textual description covering both audible and visual information. For a class library, a transcript per class is also the version somebody can read on a train, search, or skim before committing forty minutes, so it tends to survive prioritisation better than the rest.

## Live classes and the subtitle case

Apple's subtitle definition is about live onscreen dialogue in a preferred language. In a live-class product that is two decisions, not one: which languages you carry, and whether your live path can produce anything at all. We have no verified guidance on live captioning pipelines to give you here, so we are not going to invent a workflow. The design point that survives without one is Apple's opening sentence: it's important that dialogue and crucial information isn't communicated through audio alone. For a live class the things you cannot afford to lose that way are the count, the interval boundary, and any safety instruction. Those should also exist as on-screen state that does not depend on hearing the coach say them.

## The gap: we could not verify Android's captions APIs

This page is written from Apple's guidance. We could not verify Android's captions API surface in this pass. The reference material loaded, but we did not extract a single sentence we are prepared to quote, so we describe nothing about it: no class names, no defaults, and nothing about how a system captioning preference is expected to reach your player. If you are building the Android side, treat this page as the conceptual model — four distinct jobs, not one — and verify the API surface against Google's current documentation yourself. The general Android accessibility entry point we did read is [Google's accessibility principles](https://developer.android.com/guide/topics/ui/accessibility/principles).

We would rather ship that admission than a paragraph of plausible Android class names. If a captions page cannot tell you which sentences it verified, it is not usable as a reference.

## The player is part of the problem

Whatever you generate has to be reachable while the user is on the floor, and a caption track behind a settings screen three taps deep is a caption track nobody turns on mid-plank. Two things are worth getting right in the player: the control that toggles the track is available from the playback surface itself, and the choice persists to the next video, so the user makes it once rather than at the start of every class.

Contrast matters more than usual here too, because captions sit over moving video that you do not control the brightness of. A translucent plate behind the text is doing the same job as a solid background elsewhere in your app.

If your product's video is a camera coaching loop rather than a library, the surrounding design questions live in [camera coaching engagement](/engagement/camera-coaching-engagement), and the two build guides where this bites hardest are [home workout apps](/build/home-workout-app) and [yoga apps](/build/yoga-app), where a large share of instruction is a body position rather than a sentence.

## Monday morning

Take ten videos from your library and sort them into the table above. Most teams find the split is not what they assumed: the captioned classes are fine, and the demo loops — usually the largest and most reused asset in the product — have nothing at all.

Then write the audio description script for one exercise, by transcribing what your own coach says on camera and filling the gaps where the camera is doing the talking. Ship that one. It will tell you within an afternoon whether this is a content pipeline problem or a player problem, and those get solved by different people. Verification of any of it belongs with the rest of your accessibility pass, which is [test strategy](/test) plus a run through the app with the screen reader on.

## FAQ

### What is the difference between captions and audio descriptions for an exercise demo video?

They move information in opposite directions. Apple defines captions as the textual equivalent of audible information in video or audio-only content, and audio descriptions as narration interspersed between natural pauses in the main audio that supplies important information presented only visually. A demo loop is mostly visual information, so captions have almost nothing to carry while an audio description has to carry the whole movement: start position, what moves, tempo, and where the rep ends. Captioning a silent demo and calling the video accessible is the common mistake in fitness libraries.

[Permalink](https://aifitnessapi.com/accessibility/captions-for-workout-video#faq-1)

### Does a silent exercise demo loop need anything if there is no dialogue to caption?

Yes, and it needs the most work of anything in your library. With no dialogue there is nothing for captions to do, but the whole instruction is in the picture, which is exactly the case Apple's audio description definition covers: spoken narration of important information presented only visually. A transcript, which Apple defines as a complete textual description covering both audible and visual information, is the cheaper companion artefact and is usually reusable elsewhere in the product. Start from what your coach says on camera and fill the gaps the camera was carrying.

[Permalink](https://aifitnessapi.com/accessibility/captions-for-workout-video#faq-2)

### Do you have verified guidance for captioning video in an Android fitness app?

No, and we will not improvise it. When we compiled the evidence for this cluster the Android captions reference loaded but produced no sentence we were prepared to quote, so we describe no class names, no defaults, and nothing about how a system captioning preference is expected to reach a player. What transfers from Apple's guidance is the conceptual model: four separate jobs rather than one, with audio description as the one fitness content usually lacks. Verify the Android API surface against Google's current documentation before you build against anything.

[Permalink](https://aifitnessapi.com/accessibility/captions-for-workout-video#faq-3)