Accessibility video in 2026: more than subtitles

Christopher Ross

8 min read

AI and learning, kept human · Fort Erie, Ontario

Title card for the article “Accessibility video in 2026: more than subtitles” on This Is My URL

Watch enough recorded lectures with the auto-captions on and you will eventually hit the moment: the captions turn a lecturer’s name into three unrelated words and render a key technical term as something that sounds rude. The speaker never notices. The captions are on, the little “CC” badge glows, and by every dashboard in the building the video counts as accessible. A deaf student watching it gets a garbled mess with confident timing.

That gap between “captions are on” and “a student can actually learn from this” is the whole subject of this piece. Auto-captions are genuinely useful. They are also where a lot of course teams stop, and stopping there is the trap.

Captions are the floor, not the ceiling

Here is the thesis up front: subtitles are the floor. They are the first thing you owe a viewer, and they are nowhere near the last.

Nobody who has finished a wooden tabletop would sand it once and call it done. Sanding is the first pass of many: sand, seal, first coat, sand again, more coats, rub it out. Skip the steps after the first and you have bare wood that photographs fine and fails the moment someone puts a warm mug on it. Auto-captions are that first pass of sandpaper. Necessary. Not a finished surface.

Real accessible video in 2026 is a stack of parts working together: accurate captions, a full transcript, audio description for what matters visually, a player people can actually operate, no flashing that can trigger a seizure, readable on-screen text, and a text alternative when the video is the only place the information lives. Let me walk each one, in human terms, and name the standard behind it so you can hold a vendor or a platform to it.

The standard is WCAG, the Web Content Accessibility Guidelines. It is the reference nearly every institution, funder, and procurement office points at, and its media rules are specific about video. I will name the relevant criteria as I go, not to spec-dump, but so you can look them up and cite them.

Accurate captions, which is not the same as auto-captions

WCAG calls for captions on prerecorded video (success criterion 1.2.2). The word doing the work there is captions, and the unwritten word is accurate. Auto-captioning has become very good at ordinary conversational speech. It is still weak at exactly the things that carry the meaning in a lecture: proper names, discipline-specific terms, acronyms, numbers, and punctuation. A caption track with no sentence breaks and a mangled key term reads like a transcript of a guess, and a deaf student cannot learn from a guess.

The practical rule I hold: auto-captions are a first draft, and a human who knows the material corrects them before the video is called done. That correction pass is where the names come back, the terms get spelled right, and the punctuation returns so a sentence reads as a sentence. On a one-hour lecture it is not a huge job. Skipping it is the difference between a caption and a compliance decoration.

The transcript and the audio description

Two more parts of the stack, and they protect two different students.

A full transcript is a plain-text version of everything spoken and everything shown that matters. It helps the student on a phone on transit who cannot play sound, the student who reads faster than the video talks, the student who wants to search the lecture for the one part they need, and the screen-reader user who would rather read than scrub. Transcripts also feed search and captioning, so the work pays for itself more than once. For video where the moving picture is the only source of some information, WCAG treats a text alternative, a media alternative, as a requirement, not a nicety.

Audio description covers what the eyes get that the ears do not. If the lecturer says “as you can see here” and points at an unlabelled diagram, a blind student just lost the point. Audio description is a spoken track, or a scripted alternative, that says out loud what is on screen: the values on the chart, the step being demonstrated, the thing being pointed at. WCAG asks for this on prerecorded video (criteria 1.2.3 and 1.2.5). The good news for a lot of teaching video is that the fix is upstream and free: coach presenters to narrate what they show. “The line climbs to sixty percent by week three” serves everyone and needs no separate track at all.

The player itself has to work

You can get every track right and still shut people out at the player. This is the part teams forget because it is invisible to anyone using a mouse and good eyes.

An accessible player is operable from the keyboard alone (criterion 2.1.1), because a lot of people cannot use a mouse. Every control, play, pause, volume, captions, speed, has a real label a screen reader can announce, not an unlabelled icon. Controls are visible and do not vanish. Video does not autoplay, and if anything moves or plays on its own the viewer can stop it (criterion 2.2.2), which matters enormously for anyone with a cognitive or attention disability who needs the page to hold still. Speed is adjustable, because the student who needs to slow a fast lecturer to three-quarter speed is often the student the material was hardest for. On-screen text has enough contrast to read. And nothing flashes more than three times a second (criterion 2.3.1), because that three-per-second threshold is the line that can trigger a seizure, which is why it is a hard rule and not a style preference.

Most learning platforms ship a player that handles the basics. The failure I see is a custom player, or an embedded one, bolted on for branding, that quietly drops keyboard support and control labels. If you are choosing or building a player, that is the thing to test first, with the mouse unplugged.

What this actually costs, and who pays it

Here is the part I want educators to sit with. The cost of inaccessible course video is not a compliance fine. It is a student who could not learn from the material everyone else got.

I am partway through a master’s in learning and technology, and the one belief that has hardened for me is that access belongs at the start of a build, as a precondition, the same way a legible font or a working link is a precondition. Treating it as a phase you schedule near the end is how it gets cut when the term runs short. When a deaf student gets garbled captions, a blind student gets no description, a commuting student gets no transcript, and a student who needed to slow it down gets a player that will not let them, you have not delivered a slightly rougher version of the course. You have delivered a course four groups of students cannot take. They notice long before any auditor does.

None of this requires heroics. It is a checklist you run before a video ships, and once presenters get in the habit of narrating what they show, half of it stops being extra work at all. I go through this same stack whenever I run a technical and accessibility audit, and I hold my own material to it, which is why the site carries its own accessibility statement rather than a badge and a shrug. If you want the mindset behind all of it in one story, I wrote about the restaurant with the ramp, which is really about access as a decision you make on purpose instead of a box you tick.

Turn the auto-captions on. They are a good first pass. Then correct them, write the transcript, describe what the screen shows, and make sure a student with the mouse unplugged can still press play.

Getting video right is one piece of building a course every learner can finish. Accessibility that holds up under a real student, not just a compliance dashboard, is built into the learning platforms I build. If your course video stops at auto-captions and you are not sure what is slipping through, book a call and we will check it.

Keep reading

Working through something on your own site? Get in touch →

Leave a Reply

Your email address will not be published. Required fields are marked *

Your rating (optional)

Your name and email are stored with your comment; only your display name is shown publicly. See our privacy policy.