トピックを検索
手話通訳がない、または手話が小さすぎて読み取れない動画
淹れ方の動画には字幕はあるが手話の版がなく、あっても通訳者が画面の隅に小さく映るだけで、手の動きや表情を読み取れない
問題
手話を使うろう者には、第二言語かもしれない字幕でしかレシピが伝わらない
コーヒー焙煎店の淹れ方動画には、分量も手順もタイマーの音も入った正しい字幕が付きました。けれども、手話を第一言語とするろう者の客にとって、字幕は第二言語の文字で、ナレーションの速さで流れていきます。店は手話の版を用意していません。後で編集し直した版には通訳者が加わりましたが、手話通訳者がよく置かれる映像の右下の隅に、幅の8分の1の大きさで映っているだけです。ノートパソコンでよくある幅640ピクセルのプレーヤーでは、通訳者の高さは105ピクセルほどです。縦に持ったスマートフォンで動画の幅が360ピクセルほどになると、高さは60ピクセルほどで、顔も手も十数ピクセル以下、口は数ピクセルしかありません。通訳者はいるのに、誰も読み取れません。
レベルAAAの達成基準1.2.6は、同期したメディアの収録済みの音声すべてに、手話通訳を付けることを求めます。字幕ではこれを満たせません。手話はそれ自体が独自の文法を持つ言語で、日本語を手の形に置き換えたものではありません。1.2.6の解説書も、手話を母語とする人の中には文字を読むのが得意でない人もいること、手話は字幕にはない抑揚や感情を伝えることを挙げています。最初の版には手話通訳がまったくないため、満たしません。次の版には通訳者がいますが、小さすぎて使えません。通訳者を動画に映す達成方法G54は、動画が小さすぎると手話通訳者を見分けられなくなり、映像に埋め込んだ通訳者は映像全体を拡大しない限り大きくできない、と注意を促しています。W3Cの手話動画のガイダンスも、視聴者が動きと表情をすべてはっきり見られる大きさを求めています。世界ろう連盟(WFD)と世界手話通訳者協会(WASLI)が2020年に出した公衆衛生情報のガイドラインは、ライブのニュース番組について、通訳者を映像に重ねるなら「画面の少なくとも半分」、別の枠に置くなら「画面の25%」を勧めています。この例の通訳者は4%ほどです。
手話を使うろう者が最も影響を受けます。周りの聞こえる人も、字幕があれば十分だと思って動画を勧めてしまい、問題に気付きません。手話は国ごとに異なり、日本の日本手話、アメリカのASL、イギリスのBSLはそれぞれ別の言語です。視聴者と違う手話の通訳は、外国語の音声と同じで役に立ちません。
10グループ中2グループに影響
これを見つける自動チェックはありません。axeが確かめるのは動画に字幕トラックがあるかどうかで、手話には触れません。自動チェックには、映像に通訳者がいるかどうかも、その大きさも分かりません。EaseWebの診断はすべての動画を人が確認する項目として挙げますが、そこで求める確認はレベルAAまでで、手話通訳(1.2.6)には触れません。AIツールはフレームの隅の人物を見つけられても、その人が動画の話を正しい手話で正確に通訳しているかは判断できません。それができるのは、その手話に堪能な人だけです。
試してみる
淹れ方の動画を手話で見る方法を探し、通訳者の手と表情が見えるか確かめてみましょう
問題1: 動画に字幕はありますが、手話で見る方法はページのどこにもありません。
問題2: 同じ動画の右下の隅に、通訳者が映っています。手と表情を見てから、スマートフォンのようにウィンドウを狭くしてみましょう。この通訳者はデモ用に描いた静止画で、手話はしていません。実際の手話通訳版は、資格のある通訳者を撮影した映像です。
修正を適用します。 プレーヤーの下の「手話」ボタンを押すと、通訳者が映像の横に、プレーヤーの幅の3分の1の大きさで表示されます(2つ目の修正では、狭い画面だとプレーヤーの下に表示されます)。
問題あり 修正できますか?
ハウスブレンドの淹れ方
アニメーションによる説明・待ち時間は短縮しています。
修正方法
手話通訳者を、読み取れる大きさで映す
字幕だけで、通訳者がいない
<video controls preload="metadata" src="brew-guide.webm" poster="brew-guide.jpg"> <track kind="captions" srclang="ja" label="日本語" src="brew-guide.ja.vtt"></video>問題点2点
字幕は正しく、足りないのは手話です。
- 動画を手話で見る方法が、ページのどこにもありません。
- そのため手話を使うろう者は、ナレーションの速さで流れる字幕を読むしか、レシピを知る方法がありません。
映像の横に通訳者を置いた手話通訳版
<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="ja" label="日本語" src="brew-guide.ja.vtt"></video><button type="button" id="sign" aria-pressed="false"> 手話</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; // 同じ位置、同じ速度で続ける。 video.addEventListener('loadedmetadata', () => { video.currentTime = currentTime; video.playbackRate = playbackRate; if (!paused) video.play(); }, { once: true }); button.setAttribute('aria-pressed', String(on)); });</script>修正の手順4ステップ
- 動画の手話通訳版を編集します(W3Cの達成方法G54)。映像を画面の3分の2に縮め、残りの3分の1に、画面の高さいっぱいで通訳者を置きます。通訳者は映像のどこも覆わず、腰の下から頭の上までの手話の空間がすべて映ります。
- そのファイルを、プレーヤーの
data-signedに書いておきます。 - プレーヤーのすぐ下に、
aria-pressed付きの「手話」ボタンを置きます。何が選べるかと、オンかどうかを伝えます。 - クリックされたら手話通訳版のファイルに替え、同じ位置から続けます。音声は同じなので、字幕ファイルはそのままです。
これで二つの修正前の例は直り、1.2.6を満たします。通訳者はファイルの一部なので、全画面にすると映像と一緒に大きくなり、そのまま動画サービスにも上げられます。元の動画と同じ長さに編集すればタイミングも保たれます。長さが違う場合は、最初から再生します。
どちらも1.2.6を満たします。選ぶなら手話通訳版です。一つのファイルなので、どのブラウザーでも、上げたどの動画サービスでも同じように再生され、全画面にしても通訳者が残ります。プレーヤーの横の通訳者の動画は、Chromium系以外のブラウザーで動画自体の全画面にすると通訳者が置き去りになり、iPhoneでは二つを一緒に全画面にできないため、それだけでは足りません。元の映像を元の大きさのまま見せたいとき、一つの通訳者の録画を映像の複数の編集版で使い回すとき、手話のウィンドウを表示できるアクセシブルなプレーヤーを使うときに選び、「全画面」ボタンは残してください。
動画を再生する場所によって、手話通訳の届け方が変わります。
- 自分の
<video>:上のどちらの方法でもよい。W3Cの手話動画のガイダンスが勧めるように、「手話」ボタンはプレーヤーのすぐ下に、大きく、ラベル付きで置く。プレーヤーが独自の操作バーを持つ場合は、操作バーに字幕のボタンがない動画プレーヤーと同じく、字幕の操作の隣に置く。 - YouTubeやVimeoなどの動画サービス:一つの映像しか再生しないため、手話通訳版を別の動画として上げ、埋め込みのすぐ下に、手話で見られることが分かる名前(「手話で見る」)でリンクする。
- アクセシブルなプレーヤー:Able Playerは、手話の動画をメインの動画と同期した別のウィンドウに表示し、視聴者はマウスでもキーボードでも移動や拡大縮小ができる(動画の
sourceにdata-sign-src)。READMEには、iOSでは使えないとある。
通訳者の大きさは、視聴される最も小さな画面に合わせて決め、その画面で確かめます。画面の幅の3分の1で高さいっぱいの枠は面積の3分の1で、WFDとWASLIの言う4分の1を超え、隅の小さな通訳者の9倍あります。W3Cのガイダンスは、通訳者は右下に置くことが多いとしたうえで、大切な情報を覆わないよう求めています。通訳者の下に映像の文字や字幕、テロップが重ならない位置に置きます。
通訳者は画面で見られることを前提に撮影します。背景と服は、肌の色と対比する無地にし、照明を十分に当て、腰の下から頭の上まで、左右には肘の幅ほどの手話の空間をすべて画面に収めます。通訳者の動画には音声がないため字幕は要りません。ただし、2本目の <video> に字幕を求める自動チェックもあります。
手話は、動画の視聴者が使うものを選び、視聴者が国をまたぐなら複数用意します。ろう者の団体や資格のある手話通訳者に翻訳や通訳を頼み、公開する前に、その手話に堪能な人に確認してもらいます。
字幕は別の要件で、字幕のない動画と、確認されていない自動字幕で扱っています。ろう者や難聴者の多くは手話を使わないため、字幕も欠かせません。
修正の確認
4項目、マウス不要
確認方法: 音を消して視聴、キーボード、スクリーンリーダー
OS、ブラウザーと支援技術のバージョン、ビルド、実施日、各手順の実際の結果を記録してください。動画や手話通訳を差し替えた際は、再度確認します。
スクリーンリーダーでの aria-pressedの読まれ方
制限
これは出発点となる実装例であり、すべてのアプリケーションでの適合を保証するものではありません。通訳の質や、視聴者に必要な手話がどれかは、このガイドでは判断できず、判断できるのはその手話に堪能な人だけです。手話通訳はレベルAAAのため、WCAGのレベルAAを基準とする多くの法令や方針では求められていません。ライブ配信は字幕がない、または自動字幕だけのライブ配信で扱っており、1.2.6が手話通訳を求めるのは収録済みの動画だけです。ろう者の視聴者と一緒に、動画が実際に再生されるプレーヤーやサービスで、一連の流れ全体を試してください。
よくある問題を再現した学習用のサンプルです。実在のクライアントの診断結果ではありません。コードは出発点となる実装例のため、実際の製品でも確認してください。ここでは支援技術でのテスト結果は報告していません。
参考資料
- WCAG Understanding: sign-language-prerecorded(新しいタブで開きます)
- WCAG Technique G54(新しいタブで開きます)
- WCAG Technique G81(新しいタブで開きます)
- w3.org: sign-languages(新しいタブで開きます)
- wfdeaf.org: WFD-WASLI-Guidelines-SL-access-FINAL-18March20-1-1.pdf(新しいタブで開きます)
- github.com: ableplayer(新しいタブで開きます)
- developer.mozilla.org: requestFullscreen(新しいタブで開きます)
EaseWebのサービス
修正した問題を、次のリリースで再発させない
このガイドのような修正方法を、コーディングエージェントが従うルールと、CIのチェックに組み込みます。あわせて定期的に、キーボードとスクリーンリーダーで手動の再テストを行います。