# Videos without sign language, or with a tiny interpreter

Source: https://easeweb.dev/learn/sign-language
Topics: Images and media > Videos have sign language interpretation (WCAG 1.2.6)
The fix: Either publish an interpreted version, with the interpreter in a box beside the picture that takes about a third of the frame, and offer it from a Sign language button under the player, or show a second video of the interpreter beside the player, kept in step by a script. Either way, the interpreter is large enough to follow on a phone.
Test with: sound off, keyboard, screen reader
References: https://www.w3.org/WAI/WCAG22/Understanding/sign-language-prerecorded.html https://www.w3.org/WAI/WCAG22/Techniques/general/G54 https://www.w3.org/WAI/WCAG22/Techniques/general/G81 https://www.w3.org/WAI/media/av/sign-languages/ https://wfdeaf.org/wp-content/uploads/WFD-WASLI-Guidelines-SL-access-FINAL-18March20-1-1.pdf https://github.com/ableplayer/ableplayer https://developer.mozilla.org/en-US/docs/Web/API/Element/requestFullscreen

This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.

## What happens

The coffee roaster's brewing video has accurate captions now: every amount, every step and the timer. For a Deaf customer whose first language is a sign language, though, the captions are in a second language and run at the speed of the narrator, and the shop offers nothing in sign language. A later edit of the same video adds an interpreter, filmed into the bottom right corner of the picture, where signers usually go, at an eighth of its width. In a player 640 pixels wide, as on many laptops, the interpreter is about 105 pixels tall. On a phone held upright, where the video is about 360 pixels wide, they are about 60, and their face and hands are about a dozen pixels or less, their mouth a few: there is an interpreter, and nobody can follow them.

## Why it fails

Success criterion 1.2.6, at Level AAA, asks for sign language interpretation of all prerecorded audio in synchronized media. Captions don't meet it. A sign language is a language of its own, with its own grammar, not a signed copy of English, and W3C's Understanding page for 1.2.6 notes that people whose language is a sign language sometimes have limited reading ability; it adds that signing carries intonation and emotion that captions don't. The first version offers no interpretation at all, so it fails. The second has one, but too small to use. W3C's technique for an interpreter in the video, G54, warns that "if the video stream is too small, the sign language interpreter will be indiscernible", and that an interpreter filmed into the picture "cannot be easily enlarged without enlarging the entire image". W3C's guidance on sign language videos asks for a signer large enough that viewers can "clearly see all movements and facial expressions", and the World Federation of the Deaf and WASLI, in their 2020 guidelines on public health information, prefer for live news broadcasts an interpreter keyed onto the picture at "at least half of the screen", or else in a box of their own "filling 25% of the screen". Here the interpreter takes about 4%.

## Who is affected

Deaf viewers who sign meet it, and so do the hearing people who share the video with them and assume the captions are enough. Sign languages differ by country: ASL in the United States, BSL in the United Kingdom, Auslan in Australia. An interpretation in the wrong one helps no more than a foreign-language soundtrack.

## What automation and AI miss

No automated check finds this. axe checks that a video has a captions track and says nothing about sign language, and a scanner can't see whether the picture holds an interpreter, or how large they are. EaseWeb's audit lists every video for a person to review, but what it asks there stops at Level AA, and nothing in it is about sign language (1.2.6). AI tools can spot a person in the corner of a frame, but not whether they sign the video's speech accurately, in the right sign language: only a fluent signer can judge that.

## Before: captions, and no interpreter

```html
<video controls preload="metadata"
  src="brew-guide.webm" poster="brew-guide.jpg">
  <track kind="captions" srclang="en" label="English"
    src="brew-guide.en.vtt">
</video>
```

The captions are right. Sign language is missing:

- Nothing on the page offers the video in sign language.
- So a Deaf viewer who signs gets the recipe only by reading captions, at the narrator's speed.

## Before: an interpreter filmed small into the corner

```html
<video controls preload="metadata"
  src="brew-guide.signed.webm" poster="brew-guide.jpg">
  <track kind="captions" srclang="en" label="English"
    src="brew-guide.en.vtt">
</video>
```

The markup differs only in the file it plays. The interpreter is in that file, and the file is where it fails:

- The interpreter is filmed into the bottom corner at an eighth of the picture's width, about 4% of its area.
- On a phone held upright they are about 60 pixels tall, so their handshapes, face and mouth can't be made out.
- Being part of the picture, they can't be enlarged without the rest of it, and even in full screen they stay an eighth of its width.

## After: an interpreted version, with the interpreter beside the picture

```html
<video id="brew-video" controls preload="metadata"
  src="brew-guide.webm" poster="brew-guide.jpg"
  data-signed="brew-guide.interpreted.webm">
  <track kind="captions" srclang="en" label="English"
    src="brew-guide.en.vtt">
</video>
<button type="button" id="sign" aria-pressed="false">
  Sign language
</button>

<script>
  const video = document.getElementById('brew-video');
  const plain = video.getAttribute('src');
  document.getElementById('sign').addEventListener('click', (event) => {
    const button = event.currentTarget;
    const on = button.getAttribute('aria-pressed') !== 'true';
    const { currentTime, paused, playbackRate } = video;
    video.src = on ? video.dataset.signed : plain;
    // Carry on from the same moment, at the same speed.
    video.addEventListener('loadedmetadata', () => {
      video.currentTime = currentTime;
      video.playbackRate = playbackRate;
      if (!paused) video.play();
    }, { once: true });
    button.setAttribute('aria-pressed', String(on));
  });
</script>
```

1. Edit an interpreted version of the video (W3C technique G54): shrink the picture to two thirds of the frame, and put the interpreter in the third beside it, at the frame's full height, so they cover none of the picture and their whole signing space shows, from below the waist to above the head.
2. Name the file on the player, in `data-signed`.
3. Put a Sign language button right under the player, with `aria-pressed`. It says what it offers and whether it is on.
4. On a click, swap in the interpreted file and carry on from the same moment. The soundtrack is the same, so the captions file stays.

This fixes both Befores and passes 1.2.6. The interpreter is part of the file, so full screen enlarges them with the picture, and the version can be uploaded as it is to a video platform. A version cut the same length as the original keeps its timing; if it isn't, start it from the beginning instead.

## After: an interpreter video beside the player, kept in step

```html
<div class="player">
  <video id="brew-video" controls controlslist="nofullscreen" playsinline
    preload="metadata" src="brew-guide.webm" poster="brew-guide.jpg">
    <track kind="captions" srclang="en" label="English"
      src="brew-guide.en.vtt">
  </video>
  <video id="interpreter" class="interpreter" muted playsinline
    preload="metadata" src="brew-guide.interpreter.webm" hidden></video>
</div>
<button type="button" id="sign" aria-pressed="false">
  Sign language
</button>
<button type="button" id="full-screen">
  Full screen
</button>

<style>
  .player:has(.interpreter:not([hidden])) {
    display: grid;
    grid-template-columns: 2fr 1fr;
    gap: 0.5rem;
  }
  .player video {
    width: 100%;
  }
  .interpreter {
    height: 100%;
    object-fit: cover;
  }
</style>

<script>
  const player = document.querySelector('.player');
  const video = document.getElementById('brew-video');
  const interpreter = document.getElementById('interpreter');
  const button = document.getElementById('sign');
  // Keep the interpreter at the video's moment, speed, and play or pause.
  function follow() {
    if (interpreter.hidden) return;
    interpreter.playbackRate = video.playbackRate;
    if (Math.abs(interpreter.currentTime - video.currentTime) > 0.3) {
      interpreter.currentTime = video.currentTime;
    }
    if (video.paused) interpreter.pause();
    else interpreter.play();
  }
  for (const type of ['play', 'pause', 'seeked', 'ratechange', 'timeupdate']) {
    video.addEventListener(type, follow);
  }
  button.addEventListener('click', () => {
    const on = button.getAttribute('aria-pressed') !== 'true';
    interpreter.hidden = !on;
    button.setAttribute('aria-pressed', String(on));
    follow();
  });
  // Full screen takes the interpreter with the picture.
  document.getElementById('full-screen').addEventListener('click', () => {
    player.requestFullscreen();
  });
</script>
```

1. Record the interpreter as a video of their own (W3C technique G81), the same length as the original.
2. Put it in the page beside the player, muted, and hidden until it is asked for. Give both videos `playsinline`, so an iPhone plays them in the page rather than taking the picture to full screen on its own.
3. Add a Sign language button under the player, with `aria-pressed`, that shows and hides the interpreter.
4. Keep the two in step: when the video plays, pauses, seeks or changes speed, the interpreter follows, and drifts of more than 0.3 seconds are corrected.
5. Lay them out side by side, each video the width of its column: the interpreter a third of the width, at the full height of the picture.
6. Add a Full screen button that puts the wrapper around both into full screen, and hide the video's own full screen button with `controlslist="nofullscreen"`.

This fixes both Befores and passes 1.2.6, and the picture stays its full size. The viewer can turn the interpreter off, and the page can lay them out larger, or under the player on a narrow screen. `controlslist` works only in Chromium: in Firefox and Safari the video's own full screen button stays, and enlarges the picture without the interpreter. Safari can't put the wrapper into full screen on an iPhone at all, so the Full screen button works on an iPad but not on an iPhone.

## Which option to use

Both pass 1.2.6. Use the interpreted version: it is one file that plays the same in every browser and on every platform it is uploaded to, and full screen keeps the interpreter. The interpreter video beside the player is partial, because full screen from the video's own controls leaves the interpreter behind outside Chromium, and an iPhone can't put the two into full screen together; choose it when the original picture has to stay full size, when one interpreter recording serves several edits of the picture, or with an accessible player that already shows a sign language window, and keep its Full screen button.

## Implementation decisions

Where the video plays changes how the interpretation reaches viewers:

- Your own `<video>`: either fix, as above. Keep the Sign language button right under the player, large and labelled, as W3C's guidance on sign language videos asks, and beside the captions control if the player has its own bar, as in [video players with no captions button in the control bar](/learn/caption-controls).
- A video platform such as YouTube or Vimeo: they play one picture, so upload the interpreted version as a video of its own, and link to it right under the embed, named for the sign language ("Watch in ASL").
- An accessible player: Able Player shows a sign language video in a window of its own, synchronized with the main one, which viewers can move and resize with the mouse or keyboard (`data-sign-src` on the video's `source`); its README notes that it doesn't work on iOS.

Size the interpreter for the smallest screen it will be watched on, and check it there. A box a third of the frame wide, at its full height, is a third of the area, more than the quarter WFD and WASLI ask for, and nine times the corner inset's share. W3C's guidance notes the signer is usually at the bottom right, and asks that they not cover important content: put them where no on-screen text, subtitle or ticker runs underneath.

Film the interpreter for the screen: a plain background and plain clothing in colours that contrast with their skin, good light, and the full signing space in shot, from below the waist to above the head and an elbow's width to each side. The interpreter video has no sound of its own, so it needs no captions, though an automated check may still ask for them on a second `<video>`.

Choose the sign language of the audience the video is for, and more than one where the audience is international. Ask a Deaf organisation or a qualified interpreting service to translate or interpret it, and have a fluent signer check the result before it is published.

Captions remain a separate requirement, covered in [videos without captions, or with unchecked automatic ones](/learn/video-captions): many Deaf and hard of hearing people don't sign.

## Verify the fix

1. Find the sign language version from the page, the way a viewer would: under or beside the player, by name. Turn it on and check an interpreter shows for the whole video.
2. Watch it on a phone held upright, on a laptop and in full screen. The interpreter's hands, face and mouth can be followed at each size, and the interpreter covers no text in the picture.
3. Using only the keyboard, and then a screen reader, reach the Sign language button, turn it on and off, and check the screen reader says whether it is pressed and the video keeps its place.
4. Have a fluent signer watch it through: every line of speech and every sound that matters is signed, in the right sign language, in step with the video, also after pausing, seeking and changing speed.

Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat whenever the video or its interpretation is replaced.

## Limits

This is a starting pattern, not a guarantee for every application. The guide can't judge the quality of an interpretation or which sign language your audience needs; only fluent signers can. Sign language interpretation is Level AAA, so most laws and policies that cite WCAG at Level AA don't require it. Live video is covered by [live streams with no captions, or only automatic ones](/learn/live-captions), and 1.2.6 asks for interpretation of prerecorded video only. Test the complete journey with Deaf viewers, in the players and platforms the video really plays in.

## What screen readers do (tested by hand by EaseWeb)

`aria-pressed`: Makes a button a toggle that is on or off.

| Screen reader | Browser and system | Press it | Tab to it |
| --- | --- | --- | --- |
| JAWS | Chrome, Windows 11 | Not tested | Not tested |
| NVDA | Chrome, Windows 11 | Not tested | Not tested |
| JAWS | Edge, Windows 11 | Not tested | Not tested |
| NVDA | Firefox, Windows 11 | Not tested | Not tested |
| NVDA | Edge, Windows 11 | Not tested | Not tested |
| JAWS | Firefox, Windows 11 | Not tested | Not tested |
| VoiceOver | Safari, macOS | Not tested | Not tested |
| VoiceOver | Safari, iOS | Not tested | Not tested |
| TalkBack | Chrome, Android | Not tested | Not tested |

https://easeweb.dev/learn/screen-reader-support

---

Get this guide in your coding agent: MCP https://easeweb.dev/mcp (setup at https://easeweb.dev/services/developers)