WCAG 1.2.9: 音声のみ（ライブ）

この規定の意味

WCAG 達成基準 1.2.9「音声のみ（ライブ）」は、レベル AAA のガイドライン 1.2（時間依存メディア）に属します。この基準は次のように定めています。「ライブの音声のみコンテンツに対して、同等の情報を提供する時間依存メディアの代替が提供されている。」 実務的には、あなたのウェブサイトやアプリケーションがライブ音声コンテンツを配信しており、そのコンテンツに動画コンポーネントが一切含まれない場合、その情報を忠実に伝えるリアルタイムのテキスト等価物をユーザーに提供しなければならない、ということを意味します。

ライブの音声のみプレゼンテーションとは、同期した動画トラックを伴わず、リアルタイムで放送されるあらゆる音声ストリームを指します。一般的な例としては、ウェブページに埋め込まれたライブラジオ番組、スポーツイベント中のライブ音声解説、音声形式で配信されるライブ記者会見、ライブの決算説明会や投資家向けブリーフィング、動画フィードを伴わないライブ音声ポッドキャストやトーク番組のストリームなどがあります。

この基準で求められるテキスト代替は同等でなければなりません。つまり、話し言葉だけでなく、観客のざわめき、警報音、効果音、情報的な意味を持つ音楽など、関連する非音声情報も捉える必要があります。不完全なトランスクリプトや遅延したトランスクリプトではこの基準を満たしません。代替はライブストリームと同期して（またはほぼ同期して）更新され、聴覚障害者や難聴のユーザーがリアルタイムでコンテンツを追えるようにする必要があります。

この基準を満たすための許容される手法には、リアルタイムテキストを生成するライブの速記者（CART — Communication Access Realtime Translation）を提供すること、資格を持つ字幕サービスによって生成される同期したライブ字幕を埋め込むこと、音声放送と同時に流れるライブテキストフィードを表示することなどが含まれます。音声認識ソフトウェアによって生成される自動字幕も、精度が十分に高く、出力がほぼリアルタイムで提示される場合には、この基準を満たすことがあります。

合格とみなされるもの: ページ上に、ライブ音声ストリームの進行に合わせて同等の情報を提示する、同期したテキスト代替が視覚的に提供されていること（音声プレーヤーに明確にリンクされているか、隣接して表示されていること）。この代替は、音声を聞くことができないユーザーにも知覚可能でなければなりません。

不合格とみなされるもの: テキスト代替がまったく提供されていない場合、テキスト代替が提供されているが大幅に遅延している場合（例: イベント後に掲載されるトランスクリプト）、テキスト代替が音声の一部のみをカバーしている場合（例: 登壇者の発言のみで聴衆からの質問を含まない）、あるいはテキスト代替が存在しても支援技術ユーザーにはアクセスできない場合（例: フォーカス不可能な canvas 要素としてレンダリングされている、または Flash ウィジェット内に閉じ込められている）。

公式な例外: WCAG は、ライブの音声のみコンテンツにのみこの要件が適用されるという一般原則を除き、1.2.9 に対して特定の例外を設けていません。事前録音された音声のみコンテンツは、別の達成基準 1.2.1 の対象です。短い音声クリップや簡単なアナウンスについての例外はありません。コンテンツがライブかつ音声のみであれば、この達成基準が適用されます。

なぜ重要か

世界保健機関によると、世界で4億6600万人が日常生活に支障をきたす聴覚障害を抱えており、この数は 2050 年までに 9 億人を超えると予測されています。これらのユーザーにとって、テキスト等価物のないライブ音声のみコンテンツは完全にアクセス不能です。事前録音されたコンテンツとは異なり（トランスクリプトを事前に用意し、後から添付できる）、ライブ音声は情報が時間依存であり、一過性であるため、固有の課題があります。ろう者のユーザーは、ライブストリームを後から再生しても同じ体験を期待することはできません。定義上、ライブコンテンツはその瞬間が過ぎれば即時性を失うからです。

具体的な実例を考えてみましょう。上場企業が、投資家向け情報ページで音声のみのライブ決算説明会を配信しているケースです。ろう者や難聴のアナリスト、ジャーナリスト、個人投資家は、リアルタイムのテキストフィードがなければ、その説明会に参加したり、受動的にフォローしたりすることすらできません。重要な財務情報の開示、ガイダンスの更新、アナリストからの質問への回答はリアルタイムで伝達されており、その情報の受領が遅れることは、これらのユーザーを重大な情報格差に置くことになります。規制産業においては、これは公共情報への公平なアクセスという観点から問題が提起される可能性もあります。

ろう者に限らず、この達成基準はより広いユーザー層に恩恵をもたらします。聴覚情報処理障害のあるユーザーは、音は聞こえても、ライブストリームに追いつく速度で音声を解読するのに苦労することがあります。同期したテキストフィードがあれば、音声を再生しながら、自分の理解速度に合わせて読むことができます。騒音に敏感な環境（オープンオフィス、図書館、公共交通機関など）で音声を大きく再生できないユーザーも、テキスト代替から恩恵を受けます。放送言語が第二言語であるユーザーにとっても、テンポの速いライブ音声よりテキスト代替の方が理解しやすい場合が多くあります。

SEO とコンテンツの発見性の観点からも、ライブテキストトランスクリプトや字幕フィードは、検索エンジンがクロール可能なインデックス対象のテキストを生成します。リアルタイムテキストを生成するライブイベントは、検索結果やニュースアグリゲーターに表示されやすくなり、元の放送時間枠を大きく超えてオーディエンスの裾野を広げることができます。

金融サービス、医療、行政などの規制産業で事業を行う組織にとって、ライブ音声情報への公平なアクセスを提供することは、もはや「配慮」ではなく「当然の期待」となりつつあります。この達成基準を満たさないことは、苦情、評判リスク、そして一部の法域では法的責任にさらされる可能性があります。

関連する Axe-core のルール

WCAG 1.2.9 は手動テストを必要とします。ライブの音声のみストリームに同期したテキスト代替があるかどうかを、axe-core の自動ルールで確実に検出することはできません。この制約の理由は、この達成基準の性質に根本的に関わるものです。

• 自動化でこの違反を検出できない理由: axe-core のような自動ツールは、ある一時点の静的な DOM スナップショットやページ状態を対象に動作します。<audio> 要素やメディアプレーヤーの存在は検出できますが、関連するコンテンツがライブか事前録音か、ページ上の可視テキスト領域が実際に音声ストリームと同期して更新されているか、そのテキストコンテンツが音声と意味的に同等か（すべての発話と非音声情報をカバーしているか）、リンクされた外部字幕サービスが実際に稼働していて正確かどうか、といった点は判断できません。これらすべての判断には、ライブ放送そのものに対する人間によるレビューが必要です。
• 手動監査者が確認すべきこと: 監査者は、ライブ音声ストリームがアクティブな間にページへアクセスし、テキスト代替がどのように（あるいはそもそも）提示されているかを特定し、音声の進行に合わせてテキスト代替がリアルタイムで更新されることを確認し、テキストが話者の識別、非音声の音、場面転換を含むすべての意味のある音声コンテンツをカバーしていることを検証し、さらにテキスト代替が支援技術からアクセス可能であることを確認する必要があります。例えば、aria-live='polite' や aria-live='assertive' を用いたライブリージョンが、スクリーンリーダーユーザーに対して適切に更新を通知しているかどうかなどです。
• 部分的な自動化シグナル: axe-core はライブテキスト代替の欠如を直接フラグ付けすることはできませんが、問題を悪化させる関連事項はフラグ付けします。例えば、テキストトランスクリプト領域が存在するものの display:none で隠されている場合や、メディアプレーヤーにアクセシブルなコントロールがない場合などです。これらのフラグは、手動レビューを行う際の有用な出発点となります。

テスト方法

1. 自動スキャンによるベースライン確認: ライブ音声ストリームをホストしているページに対して、axe DevTools や Lighthouse を実行します。メディア要素、ラベルの欠如、アクセシブルでないコントロールに関するフラグを確認します。これらのツールはいずれも、ライブテキスト代替の欠如を直接フラグ付けすることはありませんが、音声プレーヤーにアクセシブルネームがない、トランスクリプトコンテナがアクセシビリティツリーから隠されているなど、関連するバリアを表面化させることがあります。これらの所見を記録し、全体的なアクセシビリティ評価の一部として扱います。
2. ライブ音声コンテンツの特定: ライブ放送がアクティブな間に、音声ストリームがライブ（録音ではない）であり、動画トラックを伴わないことを確認します。ページソースやネットワークリクエストを確認し、手がかりを探します。ライブストリームは通常、HLS（.m3u8）、MPEG-DASH、または WebSocket ベースの配信を使用します。コンテンツが音声のみであることを確認します。
3. テキスト代替の有無を確認: ページ上、またはページから直ちにリンクされている場所に、可視のテキスト領域、字幕オーバーレイ、明確にラベル付けされたトランスクリプトフィードがないか探します。代替は、設定メニューの奥深くに隠されていたり、リクエストした場合にのみ利用可能であったりしてはならず、目立つ形で提示されている必要があります。可視のテキスト代替が存在しない場合、この達成基準は即座に不合格となります。
4. 同期性の検証: ライブテキスト代替を表示した状態で、音声ストリームを聞きながら同時にテキストフィードを読みます。CART やプロの字幕サービスであれば、通常数秒以内の遅延でテキストが更新されることを確認します。数分おきにしか更新されないテキストフィードや、放送終了後にのみ更新されるテキストフィードは、この達成基準を満たしません。
5. 同等性の検証: テキスト代替が、話し言葉、複数の話者がいる場合の話者の識別、関連する非音声（例: 「[拍手]」「[警報音]」「[音楽再生中]」）、オンエアのアナウンスや中断など、すべての意味のある音声コンテンツを捉えていることを確認します。
6. スクリーンリーダーテスト — NVDA + Firefox: NVDA を有効にした状態でページを開き、ライブテキスト領域に移動します。その領域が aria-live を使用している場合、NVDA は新しいテキストの挿入を自動的に読み上げるはずです。スクロールするテキスト領域である場合は、フォーカスを当てられること、内容が読み取れることを確認します。音声プレーヤーのコントロールがキーボードで操作可能であることも確認します。
7. スクリーンリーダーテスト — VoiceOver + Safari（macOS/iOS）: VoiceOver を有効にし、ライブテキスト領域に移動します。新しいテキストが表示されると、VoiceOver がそれを読み上げることを確認します。iOS では、モバイルでの体験も検証します。ライブイベントはモバイルブラウザからアクセスされることが非常に多いためです。
8. スクリーンリーダーテスト — JAWS + Chrome: JAWS を有効にした状態でページに移動し、ライブリージョンのアナウンスが機能していることを確認します。JAWS は aria-live='polite' と aria-live='assertive' を異なる方法で扱うため、コンテンツの種類に応じて冗長度設定が適切であることを確認します（高速に更新される字幕フィードでは、キューの遅延を避けるために assertive の方が適している場合があります）。
9. モバイルおよび低帯域幅でのテスト: サイトがモバイルユーザーを対象としている場合、中程度のスペックの Android デバイスで回線を制限した状態（スロットリング）でライブテキスト代替をテストします。制約のある条件下でも、テキストフィードが同期性とアクセシビリティを維持していることを確認します。

修正方法

シナリオ 1: テキスト代替のないライブ音声プレーヤー — 不適切

<!-- Live radio stream embedded with no accompanying text alternative -->
<section>
  <h2>Live Broadcast</h2>
  <audio controls src='https://stream.example.com/live'>
    Your browser does not support the audio element.
  </audio>
</section>

シナリオ 1: ARIA ライブリージョンのトランスクリプト付きライブ音声プレーヤー — 適切

<!-- Live radio stream with a synchronous ARIA live region for real-time captions -->
<section>
  <h2>Live Broadcast</h2>
  <audio controls src='https://stream.example.com/live'
         aria-describedby='live-caption-feed'>
    Your browser does not support the audio element.
  </audio>
  <!-- aria-live='assertive' ensures screen readers announce new text immediately -->
  <!-- aria-atomic='false' allows incremental updates rather than re-reading the whole block -->
  <div id='live-caption-feed'
       role='region'
       aria-label='Live captions'
       aria-live='assertive'
       aria-atomic='false'
       tabindex='0'>
    <!-- Caption text is injected here by the captioning service JavaScript -->
  </div>
</section>

シナリオ 2: イベント終了後にのみ掲載されるトランスクリプト — 不適切

<!-- Transcript link appears but only resolves after the broadcast -->
<div>
  <audio controls src='https://stream.example.com/press-conference'></audio>
  <p>A full transcript will be available after the press conference concludes.</p>
</div>

シナリオ 2: プレーヤーの横にリンクされたリアルタイム CART フィード — 適切

<!-- Real-time CART captions are displayed inline during the live event -->
<div>
  <audio controls src='https://stream.example.com/press-conference'
         aria-describedby='cart-feed'></audio>
  <!-- The CART feed is an iframe served by a professional captioning provider -->
  <!-- The iframe must itself be accessible with an appropriate title -->
  <iframe
    id='cart-feed'
    src='https://cart-provider.example.com/feed/press-conference-2025'
    title='Real-time captions for live press conference'
    width='100%'
    height='200'>
  </iframe>
  <p>A full transcript will also be published after the event concludes.</p>
</div>

シナリオ 3: 設定トグルの奥に隠された自動生成字幕 — 不適切

<!-- Captions exist but are hidden by default and require multiple steps to enable -->
<div class='player-wrapper'>
  <audio controls src='https://stream.example.com/webinar'></audio>
  <button onclick='toggleSettings()'>Settings</button>
  <div id='settings-panel' hidden>
    <button onclick='enableCaptions()'>Enable Captions</button>
  </div>
</div>

シナリオ 3: デフォルトで有効になっており明確なトグルを備えた字幕 — 適切

<!-- Captions are ON by default; a prominent toggle lets users turn them off if preferred -->
<div class='player-wrapper'>
  <audio controls src='https://stream.example.com/webinar'
         aria-describedby='webinar-captions'></audio>
  <!-- Default state is captions-on; aria-pressed reflects current state -->
  <button id='caption-toggle'
          aria-pressed='true'
          onclick='toggleCaptions(this)'>
    Live Captions: On
  </button>
  <div id='webinar-captions'
       role='region'
       aria-label='Live webinar captions'
       aria-live='polite'
       aria-atomic='false'
       tabindex='0'>
    <!-- Caption text injected here in real time -->
  </div>
</div>

よくある間違い

• イベント後にトランスクリプトを公開し、それで 1.2.9 を満たしていると主張すること: ライブ放送の数時間後や数日後に掲載されるトランスクリプトは、リアルタイムのテキスト代替ではありません。WCAG 1.2.9 は、代替がライブ音声と同時に利用可能であることを明確に求めており、事後的な提供では不十分です。
• 高速に更新される字幕フィードに aria-live='polite' を使用すること: polite ライブリージョンは、ユーザーの操作が終わるまで新しいコンテンツのアナウンスを待機します。頻繁に更新される字幕では、これによりスクリーンリーダーユーザーがアナウンスを聞き逃す原因となります。各更新が時間的に重要なライブ字幕ストリームには、aria-live='assertive' を使用してください。
• 新しいコンテンツだけでなく、更新のたびに字幕履歴全体を挿入すること: aria-atomic='true' が設定されていて、更新のたびにテキストブロック全体が置き換えられると、スクリーンリーダーは領域全体を再読み上げしようとし、非常に不快な体験になります。aria-atomic='false' を使用し、新しいテキストノードのみを追加して、追加分だけがアナウンスされるようにします。
• 字幕フィードを <canvas> 要素や動画オーバーレイのグラフィックとして埋め込むこと: canvas 上のピクセルや動画フレームに焼き付けられた字幕テキストは、支援技術からは見えません。テキスト代替は、実際の DOM テキストノードとして提供されなければなりません。
• position:absolute; left:-9999px でライブ字幕領域を画面外に配置すること: このように視覚的にコンテンツを隠すと、アクセシビリティツリーには残るものの、聴覚障害のある視覚ユーザーが字幕を読むことができなくなります。テキスト代替は、スクリーンリーダーユーザーだけでなく、すべてのユーザーに視覚的に利用可能でなければなりません。
• 複数話者の放送で話者を識別しないこと: 発話を文字起こししていても、「[司会]:」「[CEO]:」「[聴衆]:」のように特定の話者に帰属させていない字幕フィードは、完全に同等とは言えません。ライブイベントの会話構造をユーザーが追えるようにするには、話者の識別が不可欠です。
• テキスト代替から非音声情報を省略すること: 拍手、技術的な中断、バックグラウンドミュージック、警報、笑い声などの関連する音は情報的な意味を持つため、「[拍手]」「[技術的な問題 — 音声が中断]」のようにテキストフィードで説明する必要があります。
• テキスト代替を、同じページに埋め込まず、別のサードパーティ URL でのみ提供すること: 音声が元のページで再生されている間、字幕にアクセスするために別のブラウザタブやウィンドウを開くことをユーザーに強いるのは、特にスクリーンリーダーユーザーやキーボードのみのユーザーにとって、コンテキスト切り替えの大きなユーザビリティ障壁となります。
• 自動生成字幕が常に同等性の基準を満たすと想定すること: AI 生成字幕は、なまりのある話し方、専門用語、固有名詞、早口の発話に対して高いエラー率を示すことがあります。医療ブリーフィングや財務情報の開示など、重要度の高いライブイベントで、修正されていない自動生成字幕をそのまま使用すると、字幕フィードが形式上存在していても、同等性の基準を満たさない可能性があります。
• 実際のライブ放送中に、実機のスクリーンリーダーでライブテキスト領域をテストしないこと: 多くのチームは、プレーヤーと字幕コンテナを静的なプレースホルダーテキストで個別にテストするだけで、実際のライブストリーム中の動的な挙動をテストしていません。キャプション更新を挿入する JavaScript のバグ（DOM MutationObserver が黙って失敗するなど）は、ライブテスト中にしか表面化しないことがあります。

トルコのアクセシビリティ規制との関係

トルコの大統領通達 2025/10は、2025 年 6 月 21 日付官報第 32933 号で公布され、トルコで事業を行う幅広い組織に対して拘束力のあるウェブアクセシビリティ義務を定めています。この通達は、WCAG 2.2 レベル AA への準拠をベースライン標準として義務付けています。対象となる組織には、公共機関・行政機関、e コマースプラットフォーム、銀行・金融機関、病院・民間医療機関、20 万人以上の加入者を持つ通信会社、認可旅行代理店、民間輸送会社、国民教育省（MoNE）に認可された私立学校などが含まれます。

WCAG 1.2.9 はレベル AAAの達成基準であり、通達が AA ベースラインとして義務付けている準拠要件には含まれていません。大統領通達 2025/10 の対象組織は、別途 WCAG 2.2 レベル AAA への完全準拠を約束していない限り、ライブ音声のみコンテンツのテキスト代替を法的に実装する義務はありません。

しかし、厳密な法的最低要件を超えても、1.2.9 がトルコの組織にとって非常に重要となる実務的な理由がいくつかあります。通信事業者、金融機関、公共放送事業者は、投資家向け説明会、公共アナウンス、ライブのカスタマーサービス放送など、トルコのろう者や難聴ユーザーが依存するライブ音声コンテンツを頻繁に提供しています。AAA レベルの準拠を示すことは、一流のアクセシビリティへのコミットメントを示すとともに、障害者法第 5378 号およびその施行規則を含むトルコの広範な障害者権利枠組みの下での差別に関する苦情リスクを大幅に低減します。

アクセシビリティ姿勢の差別化、より厳しい要件を持つ国際市場への対応、AAA を求める調達基準との整合などの理由から、自発的に WCAG 2.2 レベル AAA 準拠を目指す組織にとって、1.2.9 を正しく実装することは不可欠です。Accsible は、規制産業に属するトルコの組織に対し、ライブ音声コンテンツを積極的に評価し、特に情報の公平性が具体的なステークホルダーの期待となる対外的なライブイベントについて、CART サービスや高精度リアルタイム字幕の統合可能性を検討することを推奨します。