WCAG 1.2.6 — Sign Language (Prerecorded)

What this requires

For prerecorded synchronised media at Level AAA, sign-language interpretation must be provided for the audio content. The interpretation is typically rendered as a picture-in-picture overlay, a sign-track that the user can opt into, or a separate version of the video with the interpreter on screen. The required sign language depends on the primary audience — American Sign Language (ASL) for English-speaking North America, British Sign Language (BSL), Spanish Sign Language (LSE), and so on.

How AI coding tools fail this

This is content production, not code. AI tools have nothing to fail here because the criterion is satisfied by producing additional content. The relevant failure pattern is upstream: AI tools that present captions and audio description as "the accessibility checklist" without surfacing that Level AAA also includes sign language. Teams aiming for AAA can finish the lower levels and never realise this one exists.

The second pattern, where code does matter: video players that don't expose alternate-version switching. Even when a signed version of the video has been produced, a custom-built player rarely surfaces it. The user gets the default track and nothing else.

Failing examples

A single-track video player with no way to switch to a signed version, even when one exists:

<video controls>
  <source src="/launch-keynote.mp4" type="video/mp4" />
  <track kind="captions" src="/launch-keynote.en.vtt" srcLang="en" default />
</video>

Passing examples

Offer a signed version of the video alongside the default, with a clear control to switch:

<>
  <div role="group" aria-labelledby="version-label">
    <span id="version-label">Choose version:</span>
    <button onClick={() => setVersion("default")} aria-pressed={version === "default"}>
      Standard
    </button>
    <button onClick={() => setVersion("signed")} aria-pressed={version === "signed"}>
      With ASL interpretation
    </button>
  </div>
  <video controls key={version}>
    <source
      src={version === "signed" ? "/launch-keynote.asl.mp4" : "/launch-keynote.mp4"}
      type="video/mp4"
    />
    <track kind="captions" src="/launch-keynote.en.vtt" srcLang="en" default />
  </video>
</>

Or a picture-in-picture composite where the interpreter is already in the frame:

<video controls>
  <source src="/launch-keynote.with-asl.mp4" type="video/mp4" />
  <track kind="captions" src="/launch-keynote.en.vtt" srcLang="en" default />
</video>

Edge cases

Captions are not a substitute. For native signers, written language is a second language and reading speed is often slower than for native readers.
Choice of sign language depends on the audience. ASL is not a signed form of English; BSL is not a signed form of ASL. Pick by audience, not by spoken-language defaults.
Picture-in-picture vs. side-by-side both work as long as the interpreter is large enough and well-contrasted. A tiny corner inset defeats the purpose.
Live sign-language interpretation is a similar concept but applies to live content and is not required by WCAG 2.2 at any level (it is not in 1.2.4).
Production cost is the real reason this is rare. Plan for it on flagship videos rather than every clip.

How Jeikin handles this

This is a manual review item. The scanner records every <video> and asks the reviewer whether a sign-language version is in scope for the project's compliance target. The dashboard keeps the decision as evidence, including the rationale when a video is exempted from AAA because the project targets AA.