August 20, 2024 · reala11y team

Captions and Transcripts for WordPress Video and Audio

A practical guide to WCAG 1.2.2 captions and 1.2.1 transcripts for WordPress video and audio — what the criteria require, honest tooling options, and where automation stops.

If your WordPress site embeds a product demo, a podcast episode, or a webinar recording, you have a media accessibility obligation that no scanner can fully resolve for you. Captions and transcripts are among the clearest, most testable parts of WCAG — and among the most commonly skipped.

This is a practical walk-through of two success criteria: 1.2.2 Captions (Prerecorded) and 1.2.1 Audio-only and Video-only (Prerecorded), both Level A in WCAG 2.1 (2018) and carried forward unchanged into WCAG 2.2, which became a W3C Recommendation on 5 October 2023.

What the two criteria actually require

It helps to separate the media types, because the requirements differ.

1.2.2 — Captions for video with sound

If a video has an audio track that carries meaning — speech, important sound effects — it needs synchronized captions. Captions are not the same as a transcript:

• They are time-synced to the video.
• They include who is speaking and relevant non-speech audio ([door slams], [laughter]).
• They are distinct from subtitles, which only translate dialogue and assume you can hear the rest.

YouTube’s auto-captions are a starting draft, not a finished product. They routinely mangle names, technical terms, and punctuation — and uncorrected auto-captions do not satisfy 1.2.2. Treat them as a first pass you edit, not a deliverable.

1.2.1 — Transcripts for audio-only and video-only

This criterion covers two cases:

• Audio-only (a podcast, an MP3): provide a text transcript of the spoken content.
• Video-only (a silent screen-recording, an animation with no audio): provide a text or audio description of the visual information.

For a podcast, a transcript also happens to be excellent for SEO and skimmability — accessibility and discoverability point the same direction here.

Practical options in WordPress

You have a few routes, roughly in order of cost and control.

Caption files (.vtt). The portable, standards-based approach is a WebVTT file referenced by a <track> element:

<video controls>
  <source src="demo.mp4" type="video/mp4">
  <track kind="captions" src="demo.vtt" srclang="en" label="English">
</video>

If you embed a self-hosted <video>, this is the mechanism you want. The browser’s native player renders the track with a caption toggle.

Hosted players. YouTube and Vimeo both support uploading a corrected .vtt (or .srt) caption file against a video. Upload your edited captions rather than trusting the auto-generated set.

Transcripts on the page. For audio, the simplest durable option is a visible transcript published as normal post content directly beneath the player — real HTML text, not an image of text, and not a PDF link.

A note on tooling: an automated checker can confirm a <track> element exists and flag a <video> that has none. It cannot judge whether the caption text is accurate, properly timed, or includes speaker labels. That judgment is human. Our WCAG 2.2 guide covers where each criterion sits on the automatable-vs-manual line.

Where automation stops — and where it helps

This is the honest part. Automated tools, reala11y included, typically detect roughly 30–40% of WCAG issues by criteria — and media accessibility is squarely in the portion that needs human review. A tool can:

• Flag a <video> or <audio> element with no associated caption track or transcript.
• Identify media embeds across your posts so nothing slips through unnoticed.

A tool cannot watch the video and verify the captions are correct. That is reviewer work, every time.

reala11y fixes code-level accessibility issues at the source and flags media that needs your attention — it is not an overlay widget, and it does not pretend a one-click toggle makes captions appear. You can see how that detection-plus-honest-flagging model works on the how it works page.

Why this is worth getting right now

The regulatory backdrop has sharpened. The US Department of Justice published its ADA Title II web accessibility rule in April 2024, the European Accessibility Act became enforceable on 28 June 2025, and on 21 April 2025 the FTC entered a final order against the overlay vendor accessiBe with a $1,000,000 penalty. The throughline: automated claims of accessibility don’t hold up, and missing captions are an easy, documented failure to point at.

The honest takeaway

Captions and transcripts are not a checkbox a plugin can tick on your behalf. The reliable path is mechanical and unglamorous: generate a draft, correct it, attach a real .vtt track or publish a real transcript, and review it before you ship. Automated tooling — reala11y included — helps by flagging the media you’ve missed and keeping the work visible. The accuracy is still yours, and that is exactly as it should be.