Sixteen years is a long time for a federal accessibility law to sit quietly in the background while an entire industry builds itself around ignoring it. The Twenty-First Century Communications and Video Accessibility Act, signed into law on October 8, 2010, is the reason a growing number of streaming platforms, media companies, and video-heavy product teams are getting FCC complaints and enforcement letters over something as specific and fixable as missing captions on content that already had them on television.
The core rule is narrower than most teams assume, which is part of why it gets missed rather than deliberately ignored. The CVAA requires that video programming already closed captioned on US television must carry those same captions when it is distributed online. It does not require every piece of internet video ever created to be captioned. Content that only ever aired online and never appeared on television is not covered by this specific rule, and user-generated content is exempt. What is covered, and covered without much room for interpretation, is the exact video: a broadcast episode, a captioned TV segment, a captioned cable program, republished on a streaming platform, a news site's video archive, or a social clip pulled from a TV broadcast.
The Fact: The FCC enforces the CVAA's online video captioning requirement with penalties of up to $144,000 per violation, and roughly $1.4 million per a single continuing act. (Source: Federal Communications Commission, CVAA enforcement guidance)
The Part Teams Get Wrong: "We're a Streaming Company, Not a Broadcaster"
The most common misconception is treating the CVAA as a broadcaster-only rule. It applies based on the content's history, not the platform distributing it. A streaming service, an on-demand app, or a news site's video archive that republishes content originally aired with captions on television inherits the captioning requirement the moment it distributes that same video online, regardless of whether the platform itself ever touched a broadcast tower. A team that licenses or syndicates TV content for a streaming or on-demand product is directly in scope, even if nobody on that team thinks of themselves as being in the broadcast business at all.
This shows up constantly in practice with clip-based content: a news organization's website embedding a captioned television segment without its captions, a sports platform republishing a captioned broadcast highlight with the caption track stripped out during the video processing pipeline, or a media company's archive of old broadcast content migrated to a new streaming backend that never carried the original caption files forward. None of these are edge cases. They are the ordinary, repeated way this requirement gets missed.
Why This Is Different From General WCAG Video Guidance
WCAG's own video accessibility guidance, covered separately in our accessible video player controls guide, is a general best-practice standard that applies to all video content regardless of its broadcast history. The CVAA is narrower and, in its specific lane, stricter: it is a binding federal statute with FCC enforcement authority and real dollar penalties, triggered specifically by content that already carried captions on television. An organization can be doing a reasonably good job on general WCAG video accessibility and still be out of compliance with the CVAA specifically, if the one piece of previously-captioned broadcast content it republished online lost its captions somewhere in the technical pipeline.
The Player Itself Is Also in Scope
The CVAA's requirements extend beyond just the caption track existing. The video player interface itself, the controls used to turn captions on and off, needs to be accessible, including to users who are blind or have low vision and need to operate caption settings without being able to see the control. This is a frequently missed detail: a platform can have technically correct caption files attached to its video and still fail the accessibility requirement if the caption toggle control itself is a small icon-only button with no accessible name, unreachable by keyboard, buried in a custom player skin that was never tested with a screen reader.
What to Check First
The fastest way to find real CVAA exposure is not a general accessibility audit of your whole site. It is a targeted review of any video content on your platform that originated from a television broadcast: does the caption track still exist after every re-encode, migration, or platform change the content has been through, and can the caption toggle itself actually be operated by keyboard and announced correctly by a screen reader. If your team has built or maintains a video player from scratch rather than using a vetted, accessible player component, that custom build is the highest-risk place to look first, a pattern covered in more depth in our piece on why your video player is a lawsuit waiting to happen.
If your platform carries any previously broadcast video content and you are not certain the captions and player controls have survived every technical migration intact, that is worth verifying directly rather than assuming. Our team can run a real audit of your video delivery pipeline and player accessibility. Reach us at experts@wcag.world, or review the FCC's own CVAA guidance and the full CVAA program page directly for the current enforcement rules.
A practical review loop
Start with the task a person needs to complete, not with the score produced by a single automated scan. Write down the entry point, the expected focus order, the announcement a screen reader should receive, and the recovery path when something goes wrong. Then repeat that task with a keyboard and at least one assistive technology setup. This turns a vague accessibility concern into an observable acceptance test.
The useful evidence is specific. Capture the URL, the control label, the keystrokes, the browser state, and the expected result. Separate a defect from a design choice, and separate both from a limitation in the test environment. Give the product owner a short reproduction and a clear severity rationale. A developer can fix a named interaction. Nobody can reliably fix a general instruction to make a page more accessible.
Finally, put the check into the delivery process. Add the scenario to a pull request checklist, retest it after JavaScript changes, and keep a small set of representative pages available for regression testing. That routine protects the people who depend on the workflow and gives the team a defensible record of what was tested, when it was tested, and what happened.
For the next review, use these related resources: request the relevant WCAG review.
A short written test plan also makes handoffs safer. Name the user goal, the starting focus, the success announcement, and the exact fallback when the preferred path is unavailable. Review that plan with someone who uses the interface differently from its author, then record the result alongside the release notes. This is a small habit, but it catches regressions that a green automated result cannot describe.