# リアルタイムの文字表示がないラジオのライブ配信

Source: https://easeweb.dev/learn/live-audio
Topics: 画像とメディア > ライブ音声にテキストの代替がある (WCAG 1.2.9)
The fix: 放送にリアルタイムの字幕担当者（CART）を手配し、その文字をプレーヤーのすぐそばの枠に表示します。司会者が準備した原稿どおりに読む場合は、ページに原稿を載せる方法でもかまいませんが、補えるのは原稿にある内容だけです。
Test with: sound off, screen reader
References: https://www.w3.org/WAI/WCAG22/Understanding/audio-only-live.html https://www.w3.org/WAI/WCAG22/Techniques/general/G150 https://www.w3.org/WAI/WCAG22/Techniques/general/G151 https://www.w3.org/WAI/WCAG22/Techniques/general/G157 https://www.w3.org/WAI/media/av/captions/ https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/iframe

よくある問題を再現した学習用のサンプルです。実在のクライアントの診断結果ではありません。コードは出発点となる実装例のため、実際の製品でも確認してください。ここでは支援技術でのテスト結果は報告していません。

## 場面

地域のラジオ局リバーサイド・ラジオは、朝のニュースをサイトでライブ配信しています。その日の番組表の下に「ライブで聴く」プレーヤーがあるだけで、ほかには何もありません。8時になると、司会者が今朝のお知らせを読み上げます。補修のためミル通りの橋が10時から通行止めになること、4番と7番のバスが代わりにステーション通りを通ること、ファーマーズマーケットが今週の土曜日に学校の駐車場へ移ることです。ジングルの後には、マーケットは土曜日ではなく日曜日になったという変更が入ります。ろう者が再生ボタンを押しても、経過時間が増えていくのが見えるだけで、何も分かりません。音を消したスマートフォンで開いた人にも、やはり何も伝わりません。どれも今朝のニュースなので、後から録音や書き起こしが載っても、橋やバスには間に合いません。

## 確認できる問題

レベルAAAの達成基準1.2.9は、ラジオの配信やライブの音声イベントなど、音声だけのライブコンテンツにテキストの代替を求めています。代替は、ライブの間に同等の情報を伝えるものです。一般的な方法は、CARTとも呼ばれるリアルタイムの字幕サービスです。訓練を受けた字幕担当者が音声を聞きながら、話された内容を数秒遅れでリアルタイムに入力し、意味のある音も書き添えます。その文字は、ライブ音声と同じページの表示領域に示します（達成方法G157）。準備した原稿に沿う放送なら原稿を代わりにできますが、放送が原稿どおりに進む間に限ります（達成方法G151）。ブラウザーはストリームを音として再生するだけで、`<audio>` 要素だけではリアルタイムの文字を表示できません。この例ではページに文字がまったくないため、満たしません。

W3Cは、この基準がWebアプリでの人と人との双方向の音声通話にまで字幕を求めるものではないとしています。対象は、ラジオの配信、ライブのポッドキャスト、ライブの音声イベントといった放送です。

## 利用者への影響

ライブの音声は、司会者のペースで進みます。プレーヤーで巻き戻せない限り、司会者が読み進める間に聞き逃したことは、その放送の中では取り戻せません。朝の番組のニュースが必要なのは、まさにその朝です。

## 自動チェックとAIの限界

ストリームを聞けるスキャンはなく、放送が始まる前に、誰かがリアルタイムで文字にするかを確かめることもできません。axeには1.2.9のルールがありません。EaseWebの監査は各 `<audio>` プレーヤーの情報を読み込み、この例のように終わりのないストリームなら、書き起こしが必要な録音としてではなく、1.2.9のライブ音声として手動確認の対象に挙げます。リアルタイムの文字が用意されるか、それが正しいかは、放送中かリハーサルでしか確かめられません。自動音声認識なら人がいなくてもリアルタイムの文字を作れますが、名前や数字を聞き違えたり、「ではなく」を落としたりすることがあり、この番組では「土曜日ではなく、日曜日」が間違った曜日になります。W3Cの1.2.9の解説は、訓練を受けていない担当者や、実際の内容と大きく違う文字では満たさないとしています。

## 修正前：読める文字がないライブのプレーヤー

```html
<h2>ライブで聴く</h2>
<p>朝のニュース、平日8:00～8:30。</p>
<audio controls preload="none"
  src="https://stream.riverside.example/live.mp3"></audio>
```

- ニュースは、ライブの音声でしか伝えられていません。
- 聞こえない人に見えるのは、再生ボタンと進んでいく経過時間だけです。
- 橋の通行止め、バスの迂回、マーケットの開催日の変更は届きません。

## 修正後：プレーヤーのそばに字幕担当者のリアルタイムの文字

```html
<h2>ライブで聴く</h2>
<p>朝のニュース、平日8:00～8:30。
  字幕担当者が入力するリアルタイムの文字を、プレーヤーの下に表示します。</p>
<audio controls preload="none"
  src="https://stream.riverside.example/live.mp3"></audio>
<iframe title="朝のニュースのリアルタイムの文字"
  src="https://captions.example.com/live/riverside-radio"></iframe>
```

1. 放送にリアルタイムの字幕担当者を手配します。配信を聞き、話された内容を数秒遅れで入力し、意味のある音は［］で書き添えます。
2. 字幕サービスは放送ごとに、入力に合わせて文字が流れるページを用意します。そのページをプレーヤーのすぐ後の枠に入れ、スクリーンリーダーで何の枠かが分かるタイトルを付けます。
3. 字幕担当者が入力するリアルタイムの文字がプレーヤーの下に出ることを、プレーヤーのそばに書いておきます。

これで修正前の例は直り、1.2.9を満たします（達成方法G157）。司会者が話したことは、番組中に入った変更も含めて、情報が古くならないうちに文字でページに届きます。文字は声から数秒遅れて出ますが、G157が求めているのは30秒未満で届くことだけです。

## 修正後：同じページに載せた準備済みの原稿

```html
<h2>ライブで聴く</h2>
<p>朝のニュース、平日8:00～8:30。</p>
<audio controls preload="none"
  src="https://stream.riverside.example/live.mp3"></audio>
<details>
  <summary>今朝のニュース（準備した原稿）</summary>
  <p>おはようございます。8時になりました。リバーサイド・ラジオです。</p>
  <p>ミル通りの橋は、補修のため、今朝10時から通行止めになります。</p>
  <p>4番と7番のバスは、代わりにステーション通りを通ります。</p>
  <p>ファーマーズマーケットは、今週の土曜日、学校の駐車場に移ります。</p>
  <p>番組中に入ったニュースを、司会者が付け加えることがあります。</p>
</details>
```

1. 司会者が読む原稿を、HTMLでプレーヤーと同じページに載せます。同じページなら、開いてもストリームが止まりません。
2. プレーヤーのすぐ後の `details` に入れ、`summary` に準備した原稿であることを書きます。
3. 最後に、番組中に司会者がニュースを付け加えることがあると書きます。

これで修正前の例は直り、1.2.9を満たします（達成方法G151）。ただし、司会者が原稿どおりに話す間に限ります。この例ではそうなりません。曜日の変更は原稿を書いた後に入ったため、原稿は土曜日のままで、原稿を読んだ人は違う日に出かけてしまいます。放送がどこまで進んだかも、原稿からは分かりません。向いているのは、事前に書いたニュース、朗読、台本どおりのラジオドラマで、ニュースが次々に入る番組や、電話やトークのある番組には向きません。

## どの方法を選ぶか

どちらも、扱う範囲では1.2.9を満たします。字幕担当者のリアルタイムの文字を使いましょう。予定になかったことも含めて話された内容をすべて伝えますが、原稿は事前に書かれた内容しか伝えません。字幕担当者がいても、原稿を加えるのは良い方法です。リアルタイムの文字が誤りやすい名前や数字を、正確に示せます。原稿だけに頼るのは、一言一句そのとおりに読む放送に限りましょう。

## 実装の判断

字幕担当者は、放送を計画する段階で手配します。リアルタイムの字幕担当者は、電話回線やインターネット経由の音声で遠隔からも作業できます。事前に、出演者の名前、地名、原稿などの資料が必要です。一日中放送する局では、すべての時間に字幕を付けるより、ニュースや利用者がよく頼る番組から始めるほうが現実的です。どの番組にリアルタイムの文字があるかを、ページに書いておきます。

枠の中は字幕サービスのページです。新しい行が届いても読んでいる位置が保たれるか、文字の大きさを変えられるか、スクリーンリーダーで読めるかは、サービス側の作りで決まります。頼る前に、スクリーンリーダーで確かめましょう。点字ディスプレイを使う人にも届いた文字をすぐ伝えたい場合は、サービスのページが新しい行を読み上げるかを確認します。読み上げない場合、流れる文字の枠は、誰かが読みに行くまで何も知らせません。

自動音声認識なら人がいなくてもリアルタイムの文字を作れ、終日の配信に使っている局もあります。字幕担当者のいない番組には何もないよりは役立ちますが、ニュースで1.2.9を満たす方法にはなりません。名前や数字を間違えることがあり、表示前に誰も確認しないためです。ライブ映像でも同じで、[字幕がない、または自動字幕だけのライブ配信](/ja/learn/live-captions)で扱っています。

番組が終わり、聞き逃し用の録音を載せると、それは収録済みの音声になり、[書き起こしのないポッドキャストと無音の動画](/ja/learn/transcripts)が当てはまります。字幕担当者の文字を録音と照らし合わせて直せば、書き起こしの良い下書きになります。ウェビナーのような映像のあるライブ配信には、代わりにプレーヤーのライブ字幕が必要です（1.2.4）。

## 修正の確認

1. 放送中か、字幕担当者とのリハーサルで、リアルタイムの文字を配信と見比べます。遅れが数秒以内に収まり、番組の最後まで途切れません。
2. 音を消し、数分間、文字だけを読みます。名前、通りの名前、数字、曜日、否定がすべて正しく、意味のある音は［］に入っています。
3. 原稿を文字の代わりにする場合は、原稿を開いたまま放送を最後まで聞きます。司会者が原稿どおりに話し、大切な内容を原稿の外で話していません。
4. スクリーンリーダーで、プレーヤーの上の見出しから読み進めます。次にリアルタイムの文字か、原稿を開く `summary` があり、何の文字かが分かります。

OS、ブラウザーと支援技術のバージョン、ビルド、実施日、各手順の実際の結果を記録してください。リアルタイムの文字がある番組ごとに、また字幕サービスを替えるたびに確認し直してください。

## 制限

これは出発点となる実装例であり、すべてのアプリケーションでの適合を保証するものではありません。リアルタイムの文字が正しいかはライブでしか確かめられず、このガイドが代わりに確かめることはできません。ウェビナーのようなライブ映像に必要なライブ字幕（1.2.4）は、[字幕がない、または自動字幕だけのライブ配信](/ja/learn/live-captions)で扱っています。番組の録音のような収録済みの音声に必要な書き起こし（1.2.1）は、[書き起こしのないポッドキャストと無音の動画](/ja/learn/transcripts)で扱っています。勝手に流れ始める音は、[止められない自動再生の音声](/ja/learn/autoplay-audio)で扱っています。実際に聞いて読む人と、その人が使う端末で、一連の流れ全体をテストしてください。

---

このガイドをコーディングエージェントで使う: MCP https://easeweb.dev/mcp（設定は https://easeweb.dev/ja/services/developers）