Captioning knowledge base and help-centre video: ADA Title III obligations for customer-facing content, platform delivery for Zendesk Guide, Intercom, and Notion

Why help-centre video is a distinct compliance category from internal training

ADA Title I governs employer obligations to employees with disabilities. When a company produces training video — onboarding modules, compliance courses, product training, leadership development — and distributes that video to its own employees through an LMS, it is operating under Title I. The obligation runs from the employer to the employee. Enforcement is by the EEOC, complaints are filed by employees, and the compliance standard is WCAG 2.1 AA SC 1.2.2 (captions for pre-recorded audio in synchronised media). This is the framework that most L&D caption compliance programmes are built around, and it is the correct framework for internal training content.

ADA Title II governs obligations of state and local government entities. Public universities, community colleges, K-12 school districts, state agencies, and city/county governments producing instructional or informational video for their constituents — including lecture capture, government training, and public service content — operate under Title II. The April 2026 ADA Title II enforcement date that drove substantial compliance programme activity in higher education applies here.

ADA Title III governs obligations of places of public accommodation — businesses that provide goods and services to the public. When the DOJ extended Title III to cover websites and mobile applications, it brought into scope any business-operated website accessible to the general public. Your knowledge base and help centre is a page on your company's website, accessible to anyone with a browser and an internet connection. Any visitor — including visitors with hearing disabilities who rely on captions — can access the help articles and the video embedded in them. That makes your help centre a Title III-covered digital service.

How knowledge base video differs from customer education academies

The closest related post in this corpus is the customer education and partner training academy post, which covers the compliance framework for customer-facing learning portals built on Skilljar, Thought Industries, LearnUpon, and Gainsight CE. Customer education academies and knowledge base help centres share the Title III compliance basis, but they are structurally different in ways that matter for caption production.

Customer education academies are structured course environments with registration flows, enrolment tracking, completion certificates, and a learner-facing catalogue. They are typically gated behind an account creation step. The content is courses — sequences of modules with learning objectives, assessments, and progress tracking. Caption compliance for a customer academy mirrors the structure of internal L&D: courses are discrete units that can be inventoried, captioned as a unit, and tracked for compliance in a course-level audit.

Knowledge base help centres are document repositories with embedded video snippets. There is no enrolment, no completion tracking, no structured learning path. A visitor can land on any article directly from a search engine. The content is articles — and some articles contain embedded video, some do not. The video is typically short (30 seconds to 3 minutes), produced informally, embedded as supplementary content within a text article, and not tracked in any learning management system. The caption audit must be conducted at the article level, not the course level, and the video inventory must be extracted from the help platform's article database rather than from an LMS course catalogue.

The compliance obligation is the same — WCAG 2.1 AA SC 1.2.2 for any pre-recorded video with audio — but the production model, the inventory method, and the platform architecture are entirely different. The L&D team's captioning programme does not extend to help-centre video unless explicitly scoped to do so. In nearly every organisation, it is not.

Why help-centre teams have no caption programme

Knowledge base and help-centre content is produced by customer success operations, product teams, technical writers, or a dedicated "customer education" function that sits within CS rather than L&D. These teams have video in their workflow — screen recordings of new features, walkthroughs of product capabilities, demos embedded in troubleshooting articles — but they typically have no captioning vendor relationship, no caption glossary, no QA protocol, and no institutional awareness that the video they publish requires captions under any accessibility standard. The L&D team's caption programme is built for a different content type on a different platform with a different compliance basis, and the help-centre team rarely has visibility into it. The accessibility coordinator, if one exists in the organisation, typically reports through L&D or HR and focuses on the internal training library. The help centre is on a different team's roadmap, in a different tool, with a different publication workflow. The gap exists because no single role is assigned to own both compliance obligations simultaneously, and both teams assume the other is handling it.

ADA Title III and the 2024 DOJ web accessibility final rule

On March 13, 2024, the Department of Justice published a final rule under ADA Title III establishing WCAG 2.1 AA as the web accessibility standard for places of public accommodation (28 CFR Part 36, Subpart D). The rule took effect June 24, 2024, with a phased compliance deadline structure:

• Phase 1 (effective April 24, 2026): Covered entities with $50 million or more in annual gross receipts during any one of the last three calendar years.
• Phase 2 (effective April 26, 2027): Covered entities with $10 million or more in annual gross receipts during any one of the last three calendar years.
• Phase 3 (effective April 26, 2027): All other covered entities (under $10 million in annual gross receipts).

For companies with $50M+ in annual revenue, the April 2026 effective date has already passed at the time this post is published. For mid-market SaaS companies in the $10M–$50M range, the April 2027 deadline is 10 months away. For sub-$10M companies, April 2027 applies as well.

What the rule requires for video content

WCAG 2.1 AA includes two Success Criteria directly relevant to video in help centres:

• SC 1.2.2 (Captions, Pre-Recorded): "Captions are provided for all pre-recorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such." This applies to any video with audio narration — screen recordings with voiceover, walkthroughs with audio explanation, how-to videos with spoken instruction. The caption must be synchronised (timed to the audio, not just a transcript below the video), and must meet the DCMP Captioning Key accuracy standard of 99% or higher, including accuracy on product-specific vocabulary.
• SC 1.2.1 (Audio-only and Video-only, Pre-Recorded): Silent screen recordings with no audio narration require a text alternative (a transcript or text description) rather than a caption track. Most help-centre screen recordings have at least some audio — a voiceover, even informal — which brings SC 1.2.2 into play.

The 99% accuracy standard for "synchronised captions" is the standard applied in Title III enforcement contexts, derived from the DCMP Captioning Key protocol. A caption track at 88% accuracy — which is typical for a Loom auto-caption on content containing product feature names — is non-compliant regardless of whether it is better than no captions at all. The rule does not grade on a curve. Auto-generated captions are not compliant under WCAG 2.1 AA SC 1.2.2 unless they have been reviewed and corrected to the 99% threshold, which Loom, YouTube, and Zoom auto-captions reliably are not on product-specific content.

Enforcement mechanism under Title III

Title III web accessibility enforcement is primarily civil litigation, not agency investigation. A person with a disability who encounters non-compliant content on your help centre — video without captions, or captions that are inaccurate to the point of being meaningless for product terminology — may file a complaint with the DOJ or bring a private civil action under Title III. DOJ may also initiate investigations or pattern-and-practice lawsuits against larger entities. Unlike Title II (where the Department of Education OCR handles most complaints in the educational context), Title III cases tend to resolve in consent agreements with specific remediation timelines. The damages structure includes compensatory damages, attorney's fees, and civil penalties for DOJ-initiated cases. A documented remediation programme with specific completion dates and evidence of good-faith progress significantly affects the enforcement trajectory, which is why building and documenting the help-centre caption compliance programme before a complaint is received is meaningfully better than beginning after one.

The "authenticated help centre" question

Some companies require a customer login to access their knowledge base — the help centre is gated behind the same authentication as their product. The authentication requirement does not automatically exempt the content from Title III coverage. The DOJ's March 2024 final rule preamble addresses this: an entity operating a website that requires account creation by any member of the public who follows the standard registration flow is operating a place of public accommodation for that website's content. If any person — whether or not they are currently a paying customer — can create an account using a standard email-and-password registration and then access the help content, the help centre is open to the public in the Title III sense. The authentication layer affects who can access the content; it does not change the classification of the entity as a place of public accommodation. The practical test is: can a Deaf or hard-of-hearing user who is not currently your customer create an account through the standard signup flow and then access the help-centre video? If yes, Title III applies. Most SaaS companies with a "sign up for free" flow or a trial account option meet this test. Companies where access requires a pre-issued license key or manual account approval by the sales team have a stronger argument for a narrower classification, but most legal teams, when presented with the risk analysis, prefer to treat the help centre as covered.

What knowledge base and help-centre video actually looks like

Understanding the production model for help-centre video is necessary for designing a caption compliance programme. It is substantially different from L&D training video in ways that affect the caption workflow.

Content types

The vast majority of knowledge base video is one of four types:

Screen recordings with voiceover narration. The most common format: a product team member or technical writer screen-records a walkthrough of a feature while narrating the steps aloud. Length: 30 seconds to 3 minutes. Tools: Loom (most common in SaaS), Camtasia, OBS, macOS/Windows native screen recording with voiceover added in post, or screen recording + Descript narration. Audio quality varies significantly — home-office recording, headset quality, background noise.

Recorded product demo clips. Short clips extracted from longer product demo recordings or sales demo sessions, cut to 1–2 minutes and embedded in relevant articles. Often produced from Zoom or Teams recordings, then edited.

GIF alternatives that became video. Older help centres used animated GIFs for short UI demonstrations. Modern platforms (Zendesk, Intercom) have moved toward embedded video for the same use case. Some of these have no audio narration — they are silent screen recordings. If there is audio (even ambient), SC 1.2.2 applies. If truly silent, SC 1.2.1 applies and a text alternative is required.

Recorded webinar or support call clips. Excerpts from customer webinars, product announcements, or support calls embedded in relevant help articles. Audio quality varies dramatically; speaker identification is more complex (multiple speakers, no clear speaker IDs).

Production volume and velocity

A mature SaaS help centre accumulates help-centre video from years of feature launches and article creation. 200 to 2,000 articles with embedded video is a realistic range for a product-led growth SaaS company that has been publishing help content for 3+ years. The back-catalogue challenge is real and parallels the L&D back-catalogue problem documented in the caption backlog remediation post — except that the content is managed in a help platform rather than an LMS, and the inventory is not immediately visible in a single administrative view.

Production velocity: a typical product team publishes 10–30 new or updated articles per month, many of which include new video. After a major feature release, the rate spikes. A new feature may generate 5–20 new help articles with embedded walkthrough video in the first week after launch. If those videos are not captioned before publication, they begin accumulating non-compliant video inventory on day one of the feature's release.

The Loom problem

Loom is the dominant screen-recording tool for SaaS help-centre video. Loom's built-in auto-captions run on a general-purpose ASR model (Loom uses Whisper-based ASR). The auto-captions appear automatically, which creates the most common misunderstanding in help-centre video compliance: the presence of an auto-caption track is taken to mean the video is captioned and compliant.

Loom auto-captions are not WCAG-compliant. They are not reviewed for accuracy. They are not tested against a reference transcript. On general speech — a narrator describing a generic process in plain language — Loom captions may reach 85–92% accuracy. On product-specific content — a narrator saying "Navigate to the Segments tab in the Audience Manager, click the Create Segment button, and select from the Behavioral Rule dropdown" — accuracy on product terms falls to 60–75%, because "Segments," "Audience Manager," "Create Segment," and "Behavioral Rule dropdown" are all product-specific terms with no representation in Loom's general-purpose ASR training data. The result is a caption track that looks correct to a reviewer who does not know the product UI, and is systematically wrong for every product-specific term that a learner needs to understand in order to follow the walkthrough.

The workflow implication: Loom auto-captions cannot be submitted as WCAG-compliant captions without review and correction. The correct workflow is to export the Loom video as MP4, submit it through a caption service with a product vocabulary glossary, receive a corrected SRT/VTT file, upload that file to the video hosting platform, and embed the captioned video in the help article. If the team is using Loom as both the recording tool and the delivery mechanism (sharing a Loom link rather than hosting video elsewhere), the caption workflow requires moving off the Loom player or using Loom's custom captions upload (available on Business and Enterprise plans), where a manually corrected VTT can replace the auto-generated track.

Platform-by-platform caption workflows

The seven most common knowledge base and help-centre platforms in SaaS have different video architecture, different caption delivery mechanisms, and different failure modes. The common thread: none of them manage caption compliance at the platform level. Caption compliance is owned at the video hosting layer, not the help-platform layer.

Zendesk Guide

Zendesk Guide is the most widely deployed help-centre platform in SaaS. Zendesk article bodies support rich text and embed codes. Video in Zendesk Guide articles is delivered one of three ways: via an embed code (YouTube iframe, Vimeo iframe, Wistia embed script, Loom share embed), via an HTML5 video block, or via a hyperlink to an external video page. Zendesk itself has no video hosting, no caption management interface, and no caption compliance features. It passes through whatever the embedded player configuration provides.

YouTube embed in Zendesk: If the video is hosted on YouTube and embedded via YouTube's standard iframe embed code, the caption delivery depends entirely on what YouTube has. YouTube auto-captions are generated automatically for all videos with detectable audio, but they are not WCAG-compliant on product-specific content. The correct workflow is to upload a corrected SRT or VTT file via YouTube Studio (Creator Studio → Subtitles → Add → Upload file), verify that it replaces the auto-generated track as the default caption option, and confirm that the captions render when the video plays in the Zendesk article embed. YouTube's "CC" button appears in the embedded player if a caption track is present; if auto-captions are disabled by the video owner, no CC button appears. Confirm the embed has CC enabled and visible.

Wistia embed in Zendesk: Wistia is the recommended video hosting platform for help-centre video in Zendesk contexts because Wistia's caption delivery is the most reliable in embedded-player scenarios. Wistia supports SRT and VTT upload via the Customize menu for any video in the Wistia library. Captions uploaded to Wistia appear in the embedded player in Zendesk articles with a "CC" button. Wistia also allows you to disable auto-generated captions and require only reviewed caption files, which eliminates the risk of auto-captions being served as the default track. For teams that want to maintain a glossary-corrected caption track that updates with product releases, Wistia's API allows programmatic SRT/VTT replacement without re-embedding the video in Zendesk.

Loom embed in Zendesk: Loom videos can be shared via Loom's embed code and embedded in Zendesk articles. In this configuration, the caption track served is Loom's auto-generated track, which is not WCAG-compliant on product-specific content. To achieve compliance, one of two paths is required: (1) For Loom Business/Enterprise plans, upload a corrected VTT file to the Loom video via Loom's custom caption upload, which replaces the auto-generated track in the embedded player. (2) Export the Loom video as MP4, caption via a service with product glossary, host on Wistia or YouTube with the corrected caption track, re-embed in Zendesk using the Wistia or YouTube embed code. Path 2 is operationally more reliable because it removes the dependency on Loom's custom caption feature and places the caption track in a more auditable hosting environment.

Audit methodology for Zendesk: Zendesk's Help Center API allows exporting article body content in bulk. For compliance auditing, export all article HTML, search for iframe src attributes and script embed codes, identify hosting platform by URL pattern (youtube.com/embed, wistia.com, loom.com, player.vimeo.com), and build an inventory spreadsheet with article URL, video URL, hosting platform, and caption status. Zendesk Guide does not have a native "video inventory" view; the API export is the only reliable way to build the full inventory.

Intercom Articles

Intercom Articles supports video blocks that can be inserted from Loom (via native Loom integration), YouTube, Vimeo, or direct file upload. Intercom's caption delivery model has a significant non-compliance risk that is unique to the platform.

Intercom native Loom integration: Intercom has a built-in integration that allows authors to insert Loom videos directly from the Intercom editor by pasting a Loom URL. The resulting video block delivers Loom's auto-generated caption track. This is the most common video workflow for CS teams using Intercom, and it delivers non-compliant auto-captions as the default for all product-specific content. The fix is the same as the Zendesk Loom path: either upload a corrected VTT to the Loom video before inserting it, or migrate the video to Wistia/YouTube with a corrected caption track and embed via URL instead of the native Loom integration.

Intercom direct video upload: Intercom Articles allows direct file upload for video files (MP4, MOV). Intercom does not support caption sidecar files (SRT or VTT) for directly uploaded video. A video uploaded directly to Intercom cannot be made accessible via caption track within the Intercom platform — there is no caption upload option, no auto-caption feature that can be reviewed and corrected, and no player-level CC button. This makes direct video upload to Intercom a structural non-compliance risk. Teams using direct video upload for help-centre video must migrate those videos to an external host (Wistia, Vimeo, YouTube) and re-embed them with caption tracks. Direct upload should be removed from the help-centre video production workflow entirely.

YouTube embed in Intercom: YouTube videos can be embedded in Intercom Articles by pasting a YouTube URL into a video block. Caption delivery follows the same pattern as Zendesk: if a corrected caption track is uploaded to the YouTube video, the CC button appears in the Intercom embed. If only auto-captions are present, auto-captions are served. Corrected SRT upload via YouTube Studio is the required workflow.

Vimeo embed in Intercom: Vimeo videos can be embedded via URL in Intercom Articles. Vimeo supports SRT/VTT upload (Vimeo Plus and above), and caption tracks uploaded to Vimeo travel with the embedded player in Intercom. Vimeo's "Subtitle and Captions" settings allow you to designate a specific language track as the default, which ensures the caption track appears automatically rather than requiring a viewer to manually enable it.

Audit methodology for Intercom: Intercom's Articles API provides article content including inserted video block metadata. Use the API to export article content, identify video block sources (Loom embed, YouTube embed, Vimeo embed, or direct upload), and build an inventory. Direct-upload video blocks require immediate migration — there is no path to compliance for directly-uploaded video without moving to an external host.

Notion Help Centre

A significant number of SaaS companies use Notion as a public-facing help centre by publishing pages in a public Notion workspace. Notion's "Share to web" and workspace-level public access settings make Notion pages indexable by search engines and accessible to the public — which means any video embedded in those public Notion pages triggers Title III obligations.

Notion video embed types: Notion supports video in two ways: embedded from a URL (YouTube, Vimeo, Loom, and other supported embed sources) and direct file upload (MP4 and other video formats). Notion also has an Embed block that can embed arbitrary URLs.

Notion direct video upload: Notion does not support caption sidecar files for directly uploaded video. A video file uploaded to a Notion page block plays inline without any caption track. There is no caption upload option and no CC button in the Notion video player. This is structurally non-compliant. The fix is to move all video to an external host with caption support and embed via URL block.

YouTube embed in Notion: A YouTube URL pasted into a Notion Embed block or Video block renders the YouTube player inline. Caption delivery follows the YouTube platform rules: corrected SRT/VTT uploaded to YouTube Studio will serve the caption track with a CC button in the Notion embed. YouTube auto-captions, if present, will also be served unless the video owner disables them. The recommended workflow is to upload a corrected caption track to YouTube and disable auto-captions for the video, then embed in Notion.

Vimeo embed in Notion: A Vimeo URL embedded in a Notion Video block renders the Vimeo player inline. Caption tracks uploaded to Vimeo travel with the embedded player. This is the recommended video hosting path for Notion help-centre video — Vimeo's caption delivery in Notion embeds is reliable, and the SRT/VTT upload workflow is straightforward.

Loom embed in Notion: Loom URLs embedded in Notion Video blocks render with Loom's auto-captions. Same compliance position as Loom in Zendesk and Intercom — not WCAG-compliant for product-specific content.

The public Notion workspace question: If your Notion workspace is set to "Public access — anyone with the link can view all published pages," all video on those published pages triggers Title III. If Notion pages are only accessible via a direct share link sent to specific customers (and are not indexed by search engines), the Title III classification is less clear-cut. Most teams using Notion as a help centre intend the content to be publicly findable, which means public workspace settings are the norm. If your Notion workspace is accessible to anyone who lands on the page from a search engine, it is a public-facing website and Title III applies.

Confluence Public Spaces

Confluence is primarily an internal documentation and wiki platform, but many companies use Confluence spaces with anonymous access enabled as a customer-facing documentation hub or public knowledge base. A Confluence space set to "anonymous can view" and accessible from the public internet triggers Title III for any video content in those pages.

Confluence video delivery: Confluence supports video via the Video macro (for files uploaded to Confluence as attachments) and via embedded iframe or raw HTML (for YouTube and Vimeo URLs). The Video macro for attached files has no caption sidecar support — it does not render VTT/SRT caption files even if they are attached alongside the video file. Caption delivery for Confluence-hosted video requires external hosting.

YouTube embed in Confluence: YouTube URLs can be embedded in Confluence via the HTML macro or the Widget Connector macro. Caption delivery follows YouTube's platform rules. Use corrected SRT/VTT upload in YouTube Studio, then embed the YouTube URL in Confluence.

Vimeo embed in Confluence: Same approach as other platforms — Vimeo with corrected SRT/VTT uploaded, embedded via URL in Confluence. Vimeo's caption track travels with the embedded player.

Jira Service Management for external help desks: Jira Service Management's Customer Portal (external-facing) and Help Center functionality creates the same Title III obligation for any video embedded in customer-facing portal articles. The video hosting and caption architecture is the same as Confluence — no native caption support for attached video, external hosting required.

Freshdesk Solution Articles

Freshdesk's Solution Articles module (Freshdesk Support or Freshdesk Suite) supports video embedding via YouTube iframe embed codes in the rich-text article editor. Freshdesk does not host video and does not have a native caption management interface. Caption delivery depends entirely on the YouTube caption configuration for each embedded video.

YouTube caption workflow for Freshdesk: Upload corrected SRT/VTT to YouTube Studio, verify the caption track appears in the YouTube player, embed the YouTube URL in the Freshdesk article. The CC button will appear in the embedded YouTube player in the Freshdesk article. This is the only reliable path to compliant caption delivery for Freshdesk-hosted help-centre video.

Vimeo in Freshdesk: Vimeo embed codes can be inserted into the Freshdesk article rich-text editor via the HTML source view. Caption tracks uploaded to Vimeo travel with the Vimeo embedded player in Freshdesk articles. This requires either a Vimeo Pro or higher plan (which includes caption upload) and the ability to edit article HTML in Freshdesk's editor — some plan tiers restrict HTML access.

Audit methodology for Freshdesk: Freshdesk's Solutions API provides article content in HTML. Export all articles, search for YouTube and Vimeo embed codes, build the video inventory by article and video hosting source. Freshdesk does not have a native "all videos in help centre" view.

HubSpot Knowledge Base

HubSpot Knowledge Base (available on Service Hub Professional and Enterprise) provides a CMS-based help centre with support for video embedding. HubSpot's video capabilities include both a native video hosting feature (integrated with Vidyard) and YouTube embed support in knowledge base article bodies.

HubSpot Video (Vidyard integration): HubSpot's built-in video hosting is powered by a Vidyard integration. Vidyard supports SRT caption file upload for closed captions via the Vidyard Dashboard (Video → select video → Accessibility → Upload Captions). An SRT file uploaded to Vidyard is served with the Vidyard player when the video is embedded in a HubSpot Knowledge Base article. This is the most reliable caption path for HubSpot-hosted help-centre video. Vidyard's caption display is compatible with HubSpot's Knowledge Base player configuration.

YouTube embed in HubSpot Knowledge Base: YouTube URLs can be embedded in knowledge base articles via HubSpot's rich-text editor. Caption delivery follows YouTube platform rules. Upload corrected SRT/VTT to YouTube Studio, verify caption track presence, embed in HubSpot article. The CC button renders in the embedded YouTube player.

HubSpot CMS page video: For companies using HubSpot CMS for their full website (including a help centre built on HubSpot CMS pages rather than the Knowledge Base module), video embedded in page templates and blog posts follows the same YouTube/Vidyard rules. HubSpot's native CMS does not have a built-in caption authoring tool for custom HTML video blocks.

Help Scout Docs

Help Scout Docs (the public documentation module in Help Scout) supports video embedding via YouTube URLs inserted into article bodies. Help Scout Docs does not support direct video upload or custom video hosting. All video in Help Scout Docs articles must be externally hosted.

YouTube embed in Help Scout Docs: A YouTube URL pasted into a Help Scout Docs article renders the YouTube player inline in the published article. Caption delivery follows YouTube platform rules — corrected SRT/VTT uploaded to YouTube Studio, verified in the embedded player. This is the only path to caption delivery for Help Scout Docs video.

Vimeo and other hosts in Help Scout: Help Scout Docs supports embedding any URL that returns a valid oEmbed response. Vimeo URLs embedded in Help Scout articles render with the Vimeo player and deliver caption tracks uploaded to Vimeo. For teams that want more caption control than YouTube provides (disabling auto-captions, ensuring only reviewed tracks are served), Vimeo is the better hosting option for Help Scout Docs video.

Vocabulary accuracy for help-centre content

Help-centre and knowledge base video has the highest product-term density of any content type a SaaS company produces. Understanding why, and what it means for caption accuracy, is necessary for building a caption programme that actually reaches the 99% WCAG threshold on this content.

Why product-term density is higher in help-centre video than in any other content type

Internal L&D training video — onboarding, compliance training, leadership development — uses product names and company-specific vocabulary, but it also uses substantial portions of general language: instructions, explanations, context-setting, regulatory language, and interpersonal communication. A 20-minute onboarding module might reference the product name 12 times and a dozen specific feature names. The ratio of product-specific vocabulary to general vocabulary is relatively low.

A 90-second help-centre screen recording showing how to configure a specific feature may contain 40+ product-specific terms — feature names, UI labels, button names, menu paths, dropdown option names, error messages, version identifiers — packed into less than two minutes of audio. A walkthrough narration might sound like: "Start by opening the Integration Settings panel from the Admin Console. Click Add Integration and search for Salesforce CRM. Select Bidirectional Sync from the Sync Mode dropdown. In the Object Mapping tab, configure your Lead to Contact field maps. Enable Deduplication using the Primary Identifier rule. Save by clicking Apply and Sync Now." Every bolded term is a potential glossary miss. Without a product vocabulary glossary, an ASR model encountering this narration for the first time will produce errors on the majority of those product-specific terms.

Product vocabulary failure categories

Feature names. Multi-word feature names that combine common words in product-specific ways. "Integration Settings" might be transcribed correctly; "Lead Deduplication Engine" might become "lead dead application engine." Feature names that are brand constructs — "HubSpot Sequences," "Salesforce Flow Builder," "Zendesk Sunshine Platform" — have near-zero representation in general ASR training data and will be phonetically approximated. For your own product, the feature names you've used for years are invisible to general ASR until they are in the vocabulary model.

UI labels. Button names, tab names, section headers, menu items. These are often capitalised and multi-word ("Create New Segment," "Apply and Sync Now," "Discard Changes"). Capitalisation has no phonetic signal; the ASR model sees the same audio signal whether the text is "create new segment" or "Create New Segment." The accuracy risk is on the specific word choices, which are often product-specific constructions that differ from natural language patterns ("Apply and Sync Now" is not a phrase that appears in ASR training corpora).

Menu paths and navigation descriptions. "Navigate to Settings, then Integrations, then API Keys" — the menu hierarchy in a product is a unique vocabulary structure. If your product uses "Workspace Settings" instead of "Settings," that distinction matters for the learner following the walkthrough, and it will not be produced correctly by a general ASR model that has only the audio signal to work with.

Keyboard shortcuts. "Press Ctrl+K to open the command palette" — the ASR model hears "control cable" or "control K" or "controller K" depending on how the narrator pronounces the key combination. Keyboard shortcuts are frequent in developer-focused product walkthroughs and in productivity tool help content. They require explicit glossary entries or post-production correction.

Error messages. Help-centre troubleshooting articles frequently include narration of the error message displayed on screen: "If you see the error 'Connection timeout — please check your OAuth credentials and retry,' click the Retry Connection button." The quoted error message is a product-specific string that may or may not match the narrator's speech output depending on how they read it.

Version identifiers and product SKUs. "This workflow applies to API version 3.2 and above" — version numbers are spoken in different ways by different narrators and have no consistent ASR handling. "Three point two" and "3.2" produce different transcriptions. Explicit glossary entries for version identifiers used in narration prevent the most common errors.

The release velocity problem

SaaS products rename features, add new features, deprecate old ones, and rebrand product lines at a cadence that exceeds any other L&D content category. Your internal L&D caption glossary, built to cover the product vocabulary used in training content, may be updated quarterly or semi-annually. Your help-centre caption glossary needs to be updated on the product release cadence — which may be weekly or bi-weekly for a product-led-growth SaaS company. A feature renamed in the v4.2 release needs to be in the help-centre caption glossary before the first walkthrough video for that feature is recorded. If the glossary lags the release, the first wave of help-centre video for the new feature ships with incorrect feature names in the caption track.

The operational fix is to add a "caption glossary update" step to the feature launch checklist. When a feature is named, or renamed, the new term is added to the help-centre caption glossary on the same day. The release notes or changelog entry is the source of truth — any product term that appears in the changelog should be in the glossary. This requires the caption glossary to be owned by the same team that owns the help-centre content and the release notes, not by a separate L&D or compliance team that receives updates at a delay. The caption glossary maintenance workflow post covers the ownership, submission, and version-control mechanics for production glossary operations in detail.

Comparison with internal L&D content accuracy

An L&D onboarding module for a SaaS product will contain product vocabulary, but it also contains substantial L&D-standard content: learning objectives, role expectations, compliance disclaimers, HR policy explanations. A WCAG 2.1 AA-compliant caption service with a product name glossary will achieve 99%+ accuracy on that content type because the ratio of general language to product-specific vocabulary is high.

A help-centre screen recording is almost entirely product-specific vocabulary from start to finish. Without a product vocabulary glossary, accuracy on help-centre video content runs 73–85% in our testing across a 50-video sample of typical SaaS help-centre walkthroughs — significantly below the internal L&D accuracy for comparable non-glossary content. With a current, maintained product vocabulary glossary applied at the caption model level, accuracy on the same content reaches 96–99%. The glossary is not a nice-to-have for help-centre video. It is load-bearing.

Caption production workflow for CX and product teams

Most CX and product teams building a help-centre caption programme are starting from zero: no vendor relationship, no glossary, no QA protocol. The following workflow builds the programme from first principles, using only tools and steps that are accessible to a non-L&D team.

Step 1: Inventory all help-centre video

Before any captioning work begins, build a complete inventory of video in the help centre. This is harder than it sounds because help-centre video is scattered across article-level embed codes, not managed in a centralised video library.

For Zendesk and Freshdesk: use the Help Center API to export all article body HTML. Write a simple regex search or paste the exported HTML into a search tool to find all <iframe> src attributes and script embed codes. The most common patterns are youtube.com/embed, wistia.com, loom.com, and player.vimeo.com. Build a spreadsheet with: Article URL, Article Title, Video URL, Video Hosting Platform, Caption Status (Compliant/Non-Compliant/No Caption/Unknown).

For Intercom: Intercom's Articles API returns article body content. Export and search for video block metadata, Loom embed URLs, YouTube URLs, Vimeo URLs. Flag all direct-upload video blocks for immediate migration.

For Notion: export Notion pages as HTML via the "Export" option. Search for embedded video URLs. For public Notion workspaces, also check which pages have public access enabled.

For Confluence: use the Confluence REST API to export page content. Search for Video macro instances and embedded iframe URLs.

Completion criterion: the inventory spreadsheet has one row per video with hosting platform and caption status. Aim to complete this in one session — it is foundational to everything else.

Step 2: Establish the video hosting standard

Choose one primary video hosting platform for all new help-centre video going forward. The recommendation depends on your tech stack and existing relationships:

• Wistia: Best for teams that want caption delivery reliability across all embed contexts, API access to caption management, and the ability to disable auto-captions. Wistia Pro or higher required for SRT/VTT upload. Wistia also provides viewer analytics that can help prioritise back-catalogue captioning by video view count.
• Vimeo: Best for teams that are already using Vimeo for other video content. Vimeo Plus or higher required for SRT/VTT upload. Reliable caption delivery in most embed contexts including Notion and Confluence. Slightly less flexible than Wistia for caption-specific API operations.
• YouTube (unlisted): Acceptable if the team is already managing YouTube content and has YouTube Studio familiarity. YouTube unlisted videos are not indexed by search engines but can be embedded in help articles. Auto-captions must be replaced with corrected SRT. YouTube's caption upload workflow is accessible and free but requires manual management of auto-caption vs. corrected-caption status per video.

Once the hosting standard is chosen, create a policy: all new help-centre video must be hosted on the chosen platform before being embedded in any article. No direct upload to Intercom, Notion, or Confluence. No Loom-embedded-link delivery (Loom can be used for recording; delivery must go through the hosting standard).

Step 3: Build the product vocabulary glossary

Seed the help-centre caption glossary from the following sources:

• Product changelog / release notes: Every named feature, every renamed UI element, every new integration partner name appears in the changelog before it appears in any help article. Use the changelog as the primary glossary seed source. Include any term that is a proper noun, a capitalised UI label, or a product-specific construction.
• Help centre article titles and headers: Export all article titles and H2/H3 headers. Any proper noun or capitalised multi-word term in those headers is a likely audio vocabulary term in the corresponding walkthroughs. Add to glossary.
• In-app UI strings: If your development team exports a list of all button labels, navigation labels, and menu item strings used in the product, this is the highest-density source of help-centre vocabulary. Even a partial list of frequently used UI strings provides significant glossary coverage.
• Integration partner names: If your product integrates with third-party tools (Salesforce, HubSpot, Slack, Zapier, Workday), include the partner product names as glossary entries. These names are frequently mentioned in help-centre walkthroughs covering integration setup.

The glossary should be maintained in a shared document owned by the team that owns the help centre. See the glossary maintenance workflow for the operational model, including how to handle product rebrands, deprecated features, and quarterly audits.

Step 4: Establish the caption-before-publish gate

Add a caption review step to the help-centre article publishing workflow. The specific mechanics depend on your publication process, but the requirement is: no video is embedded in a published help article without a verified, compliant caption track at the video hosting platform.

For teams using a project management tool (Jira, Linear, Asana) for article production, add a "Captions Verified" task to the article production ticket. The task is not marked done until the caption track has been uploaded to the video hosting platform and verified to appear in the embedded player.

For teams using a lighter-weight process (articles written directly in Zendesk/Intercom/Notion draft), add a pre-publish checklist item: "All videos have compliant caption tracks uploaded to [hosting platform]."

The gate does not need to be manual for every video once the workflow is running. A caption service that integrates with the video hosting platform (via API) can automate the upload step after review is complete. But the verification step — confirming the caption track appears and is accurate — should remain a human check, particularly for new content where the glossary coverage for new feature vocabulary is being validated for the first time.

Step 5: Back-catalogue remediation

The back-catalogue remediation priority model for help-centre video differs from the L&D back-catalogue model because there is no equivalent to "mandatory training compliance deadline" — all help-centre content needs to be compliant under Title III, and there is no prioritisation framework based on regulatory obligation category. The practical prioritisation criteria for help-centre back-catalogue are:

• Video view count (highest first): Most help-centre platforms or their embedded video hosts provide view counts per video. Prioritise the highest-viewed videos first — these are the videos most likely to be encountered by a learner with a disability in the near term.
• Article traffic (highest first): If video view counts are not available, use article pageview data from your analytics tool (Google Analytics, HubSpot Analytics, Zendesk's built-in analytics). Caption video embedded in your top-100 most-visited articles first.
• Content category (customer-facing first): If some help content is gated behind customer accounts and some is fully public, prioritise the fully public content — it has the broadest potential audience reach and the clearest Title III applicability.
• Recency (newest first): Newer content about current features is more likely to be actively searched and visited than archived content about deprecated features. Prioritise the past 12–18 months of video production.

Build a remediation plan with quarterly milestones: "Q3 2026: top 100 videos by view count captioned. Q4 2026: all videos published in 2025–2026 captioned. Q1 2027: full back-catalogue complete." Document the plan and the milestones, and update the plan with completion evidence at each milestone. A documented good-faith remediation plan is significantly better than no plan from a Title III enforcement standpoint.

Step 6: QA — minimum viable for help-centre teams

The caption QA methodology post covers the full DCMP spot-check protocol for L&D teams. For a CX or product team without existing QA infrastructure, the minimum viable QA for help-centre video is simpler:

1. Watch the video with captions enabled, audio muted, at normal speed. Any time a product name, UI label, or feature name appears in the audio, verify the caption reads the correct term. Errors on product-specific vocabulary are the most common failure mode and the most meaningful accuracy failure for a learner using the walkthrough.
2. Spot-check timing at 3 points: beginning, middle, and end. Caption should appear within 2 seconds of the corresponding audio. Significant timing drift at any of the three points is a WCAG synchronisation failure.
3. Verify the caption track is visible without user action. The CC button should be present in the player, and the default should be captions-on (or the captions should be visible by default). A hidden CC button that requires a non-obvious interaction to enable is an accessibility barrier.

This 5-minute-per-video QA check is sufficient for the initial caption pass. Systematic accuracy issues (a pattern of specific product terms being consistently wrong) should trigger a glossary update before the next batch of videos is captioned.

Connecting help-centre captioning to the broader accessibility programme

The help-centre caption programme does not need to be built in isolation from the organisation's broader accessibility work. Two integration points are worth establishing explicitly.

Shared vendor relationship, separate glossary

If the L&D team already has a relationship with a caption service, that relationship can be extended to cover help-centre content. The same vendor, the same SRT/VTT output format, the same delivery mechanism — but with a separate glossary for help-centre content. The L&D glossary and the help-centre glossary share entries for company name, executive names, and broad product names. They diverge on UI-level vocabulary (the help-centre glossary contains button names, menu paths, and feature names that never appear in internal training content) and on release-cadence vocabulary (the help-centre glossary must be updated on product-release cadence, which is faster than the L&D glossary update cadence). A single caption vendor relationship supporting two glossary configurations is operationally simpler than maintaining two separate vendor relationships.

Accessibility coordinator scope extension

The accessibility coordinator playbook covers the role design for caption compliance at the L&D level. For most organisations, the accessibility coordinator's remit is the internal training library. The help-centre extension requires explicitly expanding that scope or assigning a parallel role in the CS/CX organisation. The minimum viable structure:

• The L&D accessibility coordinator owns the internal training caption programme and the shared caption vendor relationship.
• A designated owner in the CS/CX or product team owns the help-centre caption glossary, the article-level caption audit, and the publication gate.
• Both owners report compliance status to the same compliance dashboard (or the same accessibility coordinator if that role has cross-organisational scope).
• The annual accessibility audit (covered in the caption programme annual review post) explicitly includes the help-centre video inventory as a separate audit scope from the internal training library.

This structure prevents the compliance gap that exists when the accessibility coordinator assumes the help-centre is someone else's problem and the help-centre team assumes the accessibility coordinator is covering it.

What to tell legal

The help-centre caption compliance programme produces two outputs that legal needs: a compliance baseline and a remediation plan. "Our help-centre video is compliant" without supporting documentation is not useful to legal. "As of the Q2 2026 audit, 34% of the 847 videos in our help-centre library have compliant caption tracks (WCAG 2.1 AA SC 1.2.2, verified by QA review). The Q3 2026 remediation plan covers the top 300 videos by view count, bringing coverage to 71% by September 30, 2026. Full coverage is targeted by Q1 2027" — this is a defensible compliance position that legal can support in a DOJ inquiry or civil litigation context. See the US compliance matrix post for the evidence structure by compliance framework.

Eight failure modes

The following failure modes are the most common reasons help-centre video remains non-compliant even when the team believes it is being addressed.

Failure mode 1: Loom auto-captions treated as WCAG-compliant. The presence of a caption track in the Loom player is taken as evidence of compliance. Loom auto-captions are not reviewed, not corrected, and not tested against a reference transcript. Accuracy on product-specific vocabulary runs 60–75%. This is the single most common compliance failure for SaaS help-centre video. Detection: play any Loom-embedded video with audio muted and captions on; verify product feature names and UI labels appear correctly in the caption text. Fix: export MP4 from Loom, caption via glossary-corrected service, host on Wistia or YouTube, re-embed.

Failure mode 2: Direct video upload to Intercom or Notion with no caption support. Video files uploaded directly to Intercom Articles or Notion page blocks have no caption track and no mechanism to add one at the platform level. The video plays without captions. Detection: identify all articles in your Intercom or Notion help centre where video was inserted via direct file upload rather than external embed URL. Fix: migrate all direct-upload video to Wistia, Vimeo, or YouTube with caption track; re-embed via URL in Intercom or Notion.

Failure mode 3: Caption track present at video host but not enabled in the embedded player. A corrected SRT file has been uploaded to Wistia or Vimeo, but the embedded player configuration does not show the CC button, or the CC button requires a non-obvious interaction to locate. The caption track exists but is not accessible to the learner. Detection: open the embedded video in the help article in a private browser window with captions enabled; verify the CC button is visible and activates the caption track without requiring navigation to the video hosting site. Fix: check the embedded player configuration settings on the hosting platform; ensure the caption track is set as the default or at minimum that the CC button is visible in the embedded player.

Failure mode 4: Glossary not updated after product rebrand or feature rename. The help-centre caption glossary was built at product launch with the original feature names. Since then, three features have been renamed, one product line has been rebranded, and two deprecated features have had their names reassigned to new capabilities. The caption glossary still reflects the original names. New walkthroughs for the renamed features are being captioned with the old feature names appearing in the caption text. Detection: compare the current product changelog against the caption glossary; identify any term in the changelog that is not in the glossary as currently named. Fix: add a "glossary update" step to the feature release checklist; treat the changelog as the authoritative source for current term list. See the glossary maintenance workflow post.

Failure mode 5: Help-centre team assumes the L&D caption programme covers their content. The L&D team has a caption vendor, a compliance programme, and regular QA. The help-centre team assumes this coverage extends to their content because they are at the same company. It does not — the L&D programme covers the internal training library, not the public-facing help centre. The help-centre video is not in the LMS, not in the L&D vendor's submission queue, and not in the L&D accessibility audit. Detection: ask the L&D accessibility coordinator whether the help-centre video inventory is in scope for their audit. Fix: explicitly scope the help-centre to a designated owner and build a separate programme with separate audit trail.

Failure mode 6: Treating help-centre video as "too short to require captions." WCAG SC 1.2.2 has no length exception. A 25-second walkthrough clip with audio narration requires a compliant caption track on the same terms as a 20-minute training module. "It's only 30 seconds" is not a compliance argument. Detection: review your help-centre video inventory for any video flagged as "exempt" due to length. Fix: remove length as an exemption criterion; apply SC 1.2.2 to all pre-recorded video with audio in the help centre.

Failure mode 7: No audit trail for caption compliance status. The team believes most videos have been captioned, but there is no record of which videos have a compliant caption track, when the track was added, which glossary version was used, or when the content was last QA'd. Without an audit trail, the compliance state is unknown at the video level. Detection: check whether the help-centre video inventory spreadsheet has a caption status column with specific verification dates. Fix: build and maintain the inventory spreadsheet (article URL, video URL, hosting platform, caption status, verification date, glossary version at time of caption). This is the minimum audit evidence required for a Title III compliance demonstration.

Failure mode 8: Screen recordings with system audio or background noise treated as uncaptionable. Some help-centre walkthroughs are recorded with system notification sounds, mouse clicks captured by the microphone, or ambient office noise that causes the auto-caption to degrade significantly. The team decides the audio quality makes the video "difficult to caption" and leaves it without a caption track. WCAG SC 1.2.2 does not have an audio-quality exception for foreseeable audio conditions. Mouse clicks and notification sounds are foreseeable recording conditions that should be mitigated before publication (by muting system audio during recording or using post-production noise removal). If the audio is genuinely unintelligible due to an unforeseen technical failure, a full transcript as an alternative satisfies the spirit of the requirement — but this exception is narrow. The standard practice should be to record with clean audio and caption the result, not to publish uncaptioned video on grounds of audio quality.

FAQ