Search topics
Videos without sign language, or with a tiny interpreter
The brewing video has captions but no sign language version, or one with the interpreter filmed so small into a corner that hands and face can't be followed.
The problem
Deaf viewers who sign get the recipe only from captions, in a language that may be their second
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.
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%.
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.
2 of 10 groups affected
- No vision (not affected)
- Low vision (affected)
- Colour vision (not affected)
- No hearing (affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (not affected)
- Reach, strength (not affected)
- Cognitive (not affected)
- Seizures (not affected)
- Without hearing For many Deaf people a sign language is their first language, and the captions are in a second one, at the speed of speech. With no interpreter, or one too small to follow, the captions are all they get.
- Limited vision Deaf signers who also have low vision, as many with Usher syndrome do, can't enlarge an interpreter filmed into the picture without enlarging the rest of it. An interpreter in a corner is the first part of the picture they lose.
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.
Try it
Find a way to watch the video in sign language, and check you can see the interpreter’s hands and face
Broken 1: the video has captions, and nothing on the page offers it in sign language.
Broken 2: the same video with an interpreter filmed into the bottom corner. Look at their hands and face, then make the window narrow, as on a phone. The interpreter is a still stand-in drawn for the demo: a real one is a recording of a qualified interpreter.
Apply a fix. Press Sign language under the player, and the interpreter shows beside the picture, a third of the player wide (in the second fix on a narrow screen, under it).
Broken Can you fix this?
How to brew our house blend
Animated guide · waiting times are shortened.
The fix
Show a sign language interpreter large enough to follow
Captions, and no interpreter
<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>What is wrong2 points
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.
An interpreted version, with the interpreter beside the picture
<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>How it is fixed4 steps
- 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.
- Name the file on the player, in
data-signed. - Put a Sign language button right under the player, with
aria-pressed. It says what it offers and whether it is on. - 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.
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.
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. - 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-srcon the video'ssource); 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: many Deaf and hard of hearing people don't sign.
Verify the fix
4 checks, no mouse.
Test with: Sound off, Keyboard, Screen reader
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.
How screen readers handle aria-pressed
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, 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.
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.
References
- WCAG Understanding: sign-language-prerecorded (opens in a new tab)
- WCAG Technique G54 (opens in a new tab)
- WCAG Technique G81 (opens in a new tab)
- w3.org: sign-languages (opens in a new tab)
- wfdeaf.org: WFD-WASLI-Guidelines-SL-access-FINAL-18March20-1-1.pdf (opens in a new tab)
- github.com: ableplayer (opens in a new tab)
- developer.mozilla.org: requestFullscreen (opens in a new tab)
EaseWeb service
Fixed it? Keep it from coming back.
I turn guides like this one into rules your coding agents follow and checks your CI runs. Then I retest by hand with a keyboard and screen readers, periodically.