Accessibility Requirements for Software Walkthrough Videos

Software walkthrough videos now face a set of accessibility rules that are specific, checkable, and increasingly enforced. Video has become the default format for teaching people how software works, and that popularity has put it squarely in the path of accessibility law. This piece lays out what WCAG 2.2 actually requires, where walkthrough videos tend to fall short, and how to build compliance into the process from the first script draft instead of bolting it on after publish.

The regulatory floor is WCAG 2.2, now an approved ISO standard (ISO/IEC 40500:2025). In one country, disability-rights regulation has extended deadlines through an interim final rule from the national justice department: public entities serving populations of 50,000 or more must comply by April 26, 2027, and smaller public entities and special districts get until April 26, 2028. Section 508 covers federal agencies and their vendors on a shorter clock already. In one region, a regional accessibility law became mandatory in June 2025, backed by WCAG 2.1 AA through EN 301 549 v3.2.1, with WCAG 2.2 adoption expected via EN 301 549 v4.1.1 in September 2026. Companies above certain employee and turnover thresholds fall inside its scope, and content published in 2026 has to comply from day one. No grace period.

None of this is a reason to wait. ASTHO's Advanced Accessibility Training data show that more than 5,000 digital accessibility lawsuits were filed in 2025 alone, and more than 25,000 have been filed since 2018. EcomBack's 2025 figures, cited by Swarmify, show lawsuit filings ran 37% higher in 2025 than the year before. And the cost of getting it wrong isn't just legal: Wonderful.io data cited by Accesstive shows 71% of users with disabilities leave a site that isn't accessible. Deadline extensions read like breathing room. They're really a measure of how much work compliance actually takes.

Once the regulatory backdrop is clear, the next question is mechanical: what, exactly, does WCAG demand of a video file?

The four technical requirements WCAG Level AA imposes on video

Four requirements do almost all the work here, and each maps to a specific WCAG success criterion.

Captions: SC 1.2.2 (Captions, Prerecorded) sits at Level A, and SC 1.2.4 (Captions, Live) sits at Level AA. Captions have to be synchronized with the audio, accurate, and they need to include non-speech information, things like [Music playing] or [Door slams], not just spoken words. Dialogue has to appear verbatim, including who's speaking. The compliance bar for accuracy is 99%, and that's not a stretch goal, it's the standard. One distinction trips up a lot of teams: closed captions (delivered as VTT files a viewer can toggle on or off), open captions (burned permanently into the video frame), and subtitles are not interchangeable. Subtitles assume the viewer can already hear the audio, so they skip sound effects and speaker labels, which means they don't satisfy SC 1.2.2 no matter how accurate the text is. VTT files matter specifically because they let a viewer toggle captions, resize them, and adjust contrast, and that adjustability gives users meaningful control over how captions appear.

Transcripts: these aren't required at Level AA for video that already has synchronized audio, though WCAG does require them for audio-only content. Even so, transcripts are strongly encouraged, because they're the primary way deafblind users access video content, through refreshable Braille displays. A transcript built straight from a caption file is incomplete: it needs visual information layered on top, on-screen text, who's speaking, what's happening in the scene. Placement matters too, the transcript should sit directly below the video embed or link immediately next to it. A transcript by itself does not satisfy SC 1.2.5, a common misread that should be corrected early.

Audio descriptions: SC 1.2.5 (Audio Description, Prerecorded) sits at Level AA and calls for a voiceover track that describes visual content during natural gaps in dialogue. For a software walkthrough specifically, that means describing anything visible but unspoken, such as a cursor moving across the screen, a button being clicked, or a UI state changing from one view to another. There's a useful escape hatch here. If the narration already describes everything visual, on its own, a separate audio description track isn't required. That's a decision made at the script stage, not a patch applied after the video is edited. SC 1.2.3, at Level A, can be satisfied with a descriptive transcript alone, but SC 1.2.5 at Level AA requires the actual audio track.

The video player: WCAG requires that every control in the player, play, pause, volume, captions, works from a keyboard alone. WCAG also requires those same controls to expose their name, role, and current state to assistive technology, so a screen reader can actually announce what a button does. Section 508 adds a specific rule: caption and audio description toggles have to sit at the same menu level as play and volume, not buried three clicks deep in a settings submenu. Players also need to work cleanly with screen readers, since users with motor disabilities depend entirely on keyboard navigation to get through them.

Knowing the requirements is step one. Knowing where teams actually miss them is step two.

Where software walkthrough videos fail accessibility checks most often

Auto-generated captions are the single biggest point of failure. Captions pulled straight from screen-recording tools or video hosting platforms almost never hit the 99% accuracy threshold on their own, a gap flagged specifically by Verbit. They're a starting point, not a finished product.

Walkthrough videos have a failure mode all their own: narration that references something on screen without ever saying what it is out loud. A narrator says "click the button," but the button's label only appears visually, it's never spoken. A sighted viewer fills in the gap without thinking about it. Someone relying on captions or audio alone gets nothing. AI caption tools miss this every time, because there's no audio error to catch, the words match the recording exactly. What's missing from the recording in the first place is the problem.

Audio description gets skipped even more often. Cursor movement, silent clicks, a modal window appearing, none of that gets captured unless the script accounts for it directly. Teams that narrate every action as it happens can skip a separate audio track entirely, but that only works if the discipline is there from the first draft, not applied retroactively to a video that's already been recorded.

Transcripts get miscounted in a quieter way: teams post accurate captions, assume the transcript box is checked, and move on. But a transcript generated straight from an auto-caption file inherits every error in that file, and it still lacks the visual context, on-screen text, scene description, that a real transcript needs.

Player accessibility tends to be the last thing anyone checks, when it gets checked. Plenty of embedded players have no keyboard support, expose no name or role to a screen reader, and hide the caption toggle two menus deep, violating WCAG and Section 508's 503.4 requirement in the same stroke. Open captions, meanwhile, burn text into the video frame and strip away the viewer's ability to adjust font size or contrast, which limits the accessibility of even flawless caption text.

None of this is a fringe problem. According to WebAIM's Million study, cited by Accesstive, roughly 96% of websites fail to meet basic accessibility standards. Noncompliance is the default state of the internet right now, not some rare exception.

Spotting where things break is useful. Building a process that prevents the breakage is where the real leverage is.

Building accessibility requirements into production from the script stage

Every accessibility fix gets cheaper the earlier it happens, and the cheapest point of all is the script, before a camera or screen recorder ever turns on. Narrate every visible action in the draft, and the need for a separate audio description track often disappears on its own. Write speaker identification into the dialogue, and captioners have nothing left to guess at.

A few script habits do most of the work:

• Read every piece of on-screen text out loud: button labels, menu items, field names. If it's visible, it gets said.
• Call out UI state changes directly: "the sidebar collapses," "the modal appears," "the error message reads: field required."
• Name speakers at the top of each segment whenever more than one voice is in the video.
• Cut phrases like "click here" or "as you can see" that lean on a visual cue without describing what that cue actually is.

Recording habits matter almost as much. Pacing that leaves natural pauses gives room for audio description later, if it turns out to be needed, and it makes caption timing easier to sync from the start. A clean, high-contrast UI reduces how much visual description the script has to carry.

Caption production should run on one rule: AI-generated captions are a draft, never a final file. Get them to the compliance accuracy standard through human review or a specialized captioning service before publishing, not after a complaint comes in. Export as VTT or an equivalent toggleable format, never burned-in text, and check every caption block against the actual audio for sound effects, speaker tags, and anything non-speech that got left out.

Transcripts should start from the corrected caption file, not the raw auto-generated one, and then get visual context added on top: on-screen text that was never spoken, descriptions of what's shown, who's talking. Place the finished transcript directly under the video or link it immediately next to the embed.

Player testing closes the loop. Tab through every control before publishing, confirm Enter and the arrow keys activate what they should, and make sure caption and audio description toggles sit at the same menu level as play and volume, not buried in settings. Run it once with a screen reader to confirm every control announces a name and a role.

A careful one-off process gets one video right. Teams publishing walkthroughs at scale need that discipline built into a repeatable workflow, not a checklist someone remembers to open once a quarter.

How AI-assisted video tools fit into accessible production workflows, and their limitations

AI video tools have changed the math on producing walkthrough content. Work that once needed a dedicated production team can now start from a plain screen recording, and that shift matters directly for accessibility, since faster production means faster updates when software UI changes.

Automatic voiceover generation and script rewriting, along with several other capabilities, appear across most of these tools. Automatic voiceover generation and script rewriting cut down on the loose, unscripted narration that tends to cause caption errors. Automated caption generation speeds up the first draft significantly, though it's not sufficient on its own at the 99% accuracy bar compliance demands. Smart editing and caption overlay features speed production further, but every output still needs a human pass before it goes live. One-click translation and localization also affects accessibility here, since many learners prefer training content in their native language, making multilingual captioning an accessibility feature in its own right, not just a nice-to-have for global teams.

Different platforms take different approaches to the same problem. Some capture a workflow as it's performed on screen and auto-generate a step-by-step guide with narration attached. Others work more like a structured script-to-video pipeline built around an on-screen presenter, useful for content that needs frequent updates as information changes. A third category starts from existing source material, SOPs, manuals, PDFs, and builds a storyboard-first video from an already-approved document, which helps keep the finished video accurate to what's actually written down. And some platforms generate the video and a companion written document, an article or SOP, from the same screen recording in one pass. That last approach solves a specific accessibility problem directly: a transcript needs visual context beyond caption text, and a document generated alongside the video can carry exactly that context without extra manual work.

The gap across every one of these tools is the same. AI-generated captions, no matter which platform produces them, tend to land below the 99% accuracy threshold compliance demands. The workflow that actually works is AI draft, then human review, then publish. Never AI straight to publish.

When evaluating a tool for accessible output, a few questions cut through the marketing fast. Does it export VTT files, or does it only burn captions into the video? Does it produce a separate text document that can stand next to the video as a real transcript? Does its translation output get reviewed by a person, or does it publish machine translation untouched? And does the player it hands you for embedding actually support keyboard navigation and screen readers, or does that get left for someone else to solve?

Update speed carries its own accessibility weight. Software interfaces change constantly, and a tool that makes re-recording and re-captioning fast shrinks the window where a published walkthrough shows an outdated screen, which isn't just an accuracy problem, it's a trust problem for anyone relying on that video to actually complete a task.

The tools and the workflow are the mechanics. The remaining question is why any of this is worth the investment to a stakeholder who sees accessibility as a line item and nothing more.

The business case for accessible walkthroughs beyond legal compliance

Scale alone makes the case. More than 1.5 billion people worldwide live with some degree of hearing or visual impairment. The European Commission reports that in the EU, more than 87 million people live with a disability. In one country, an estimated 61 million adults live with a disability, per 2026 figures from Verbit. That's not a niche audience carved out by a regulation, it's a significant share of anyone a walkthrough video is trying to reach.

Captions in particular serve a far bigger group than the audience they were built for. Roughly 87% of Americans use captions at least sometimes, and nearly half use them "always" or "often," according to data from XR cited by Swarmify. Captions also change how much of a video actually gets watched: 80% of consumers say they're more likely to finish a video when captions are on, per 3Play Media data cited by Swarmify and S1. TikTok's own creative research found that on-screen text increases view time, boosts ad recall, and makes a video more likable, and that same mechanic applies just as directly to a product walkthrough trying to hold someone's attention.

Transcripts add a return that has nothing to do with accessibility law at all: search engines can't watch a video, but they can crawl a transcript. Every properly captioned, properly transcribed walkthrough becomes a piece of indexable, discoverable text, on top of whatever accessibility benefit it provides.

Accessible design also functions as onboarding equity. A keyboard-operable player is the only way someone with a motor disability can get through a walkthrough. A transcript lets someone with a cognitive disability read at their own pace while working alongside the product in a second window. Captions and localized audio together open the same video to a non-native speaker who'd otherwise miss half of what's said. One accessible video reaches every one of those users. An inaccessible one excludes all of them by default, not by exception.

The litigation numbers back this up without needing to be inflated. 2023 figures from Lainey Feingold, cited by Accesstive, show brands have paid more than $6 million in damages and settlements tied to inaccessible video content. Digitala11y data cited by Accesstive shows that in 2023 alone, 4,605 ADA-related digital accessibility lawsuits were filed, and Accessibility.com figures cited by the same source show 1,200 of those targeted non-captioned or otherwise inaccessible video specifically. That's the cost of fixing the problem after a lawsuit lands. Building it in from the script stage costs a fraction of that, and it reaches more people while doing it.