WCAG 達成基準 · Level AAA

WCAG 1.4.7: 背景音声が小さい、またはない

WCAG 1.4.7 は、音声を含む事前録音された音声コンテンツについて、背景音を一切含まないか、背景音をオフにできるようにするか、または背景音を前景の音声より少なくとも 20 dB 小さく保つことを求めています。これは、競合する音声から話し言葉を聞き分けるのが難しい、聴覚障害や認知障害のあるユーザーを保護するためのものです。

このルールの意味

WCAG達成基準 1.4.7「背景音が小さい、または無い」は、前景に音声(スピーチ)が含まれる事前録音の音声のみコンテンツに適用されます。これは、楽曲のように音声自体が音楽パフォーマンスである音声や、発話成分を意図していない環境音主体のサウンドスケープには適用されません。音声ベースの音声コンテンツが存在する場合、この達成基準では次の3つの条件のうち少なくとも1つを満たすことが求められます。

  • 背景音がない: 音声トラックには、まったく背景音がないスピーチのみが含まれている — 声の背後は無音である。
  • ユーザーによる制御: いかなる背景音も、前景のスピーチとは独立してユーザーがオフにでき、その際スピーチの内容には影響しない。
  • 20 dBルール: 背景音は前景のスピーチより少なくとも20デシベル音量が低い。20 dBの差は、おおよそ背景音がスピーチより4倍静かな状態に相当し、多くの聴取者にとって意味のある知覚上の差となる。

これら3つの条件のいずれかが完全に満たされている場合は適合となります。前景のスピーチが、オフにできず、かつスピーチ信号に対して音量差が20 dB未満の背景音と競合している場合は不適合となります。なお、1〜2秒程度しか続かない短い通知音などの効果音は、WCAG仕様によりこの要件から明示的に除外されています。

この達成基準は、音声が単体の音声ファイルとして提供されているか、動画の音声コンポーネントとして提供されているか、ポッドキャストプレーヤー、HTML5の<audio>要素、またはサードパーティのメディアウィジェットを通じて埋め込まれているかに関わらず、音声トラックに適用されます。要件の対象は特定のHTML要素やARIA属性ではなく、あくまで音声コンテンツそのものの制作方法であるため、自動スキャンツールでは違反を確実に検出できず、実際の音声コンテンツを人が手動で確認することが常に必要になります。

なぜ重要か

世界保健機関によると、世界で約15億人が何らかの程度の難聴を抱えて生活しています。中等度の難聴であっても、背景音楽、環境音、その他の音声要素が同程度または競合する音量レベルでミックスされている場合、話者の声を聞き分けることが極めて困難になり、ときには不可能になります。補聴器や人工内耳に依存しているユーザーにとっては、背景音による干渉もスピーチと同時に増幅されるため、聞き取りやすさは改善されるどころか劇的に悪化します。

注意欠如障害、聴覚情報処理障害、外傷性脳損傷などを含む認知障害のあるユーザーも、音声トラックに競合する音が含まれている場合、大きな困難に直面します。聴力に測定可能な低下がないリスナーであっても、脳が不要な音声信号をフィルタリングし、スピーチコンテンツに集中することに苦労する可能性があり、その結果、疲労、理解の失敗、あるいはコンテンツからの完全な排除につながります。

具体的な現実のシナリオを考えてみましょう。トルコのある政府機関が、市民がどのように社会給付を申請できるかを説明する録音音声の解説を公開しています。ナレーターの声は、ほぼ同じ音量レベルの連続した背景音楽トラックの上にミックスされています。中等度の感音性難聴のあるユーザーが補聴器を使ってそのページにアクセスします。補聴器はすべての周波数を同時に増幅するため、音楽がナレーターのスピーチと直接競合します。ユーザーは説明を理解できず、給付申請の締め切りを逃してしまいます。もし音声が背景音楽なしで録音されていたか、あるいは背景トラックだけを個別に抑制できる音量コントロールが提供されていれば、そのユーザーも情報に平等にアクセスできたはずです。

障害の有無にかかわらず、背景ノイズを最小限に抑えた明瞭な音声は、すべてのユーザーの理解度を高めます。騒がしい環境でモバイル端末から聴いているユーザー、話されている言語の非母語話者、すでに音質が低下している可能性のある低帯域幅環境のユーザーなどにとっても有益です。また、間接的なSEO上の利点もあります。明瞭に聞き取れる音声の文字起こしは、検索エンジンがインデックスしやすい高品質なテキストコンテンツを生み出し、コンテンツの発見性を高めます。

関連するaxe-coreルール

WCAG 1.4.7は手動テストを必要とします。この違反を検出できるaxe-coreの自動ルールは存在せず、これは意図された仕様です。axe-core、Lighthouse、IBM Equal Access Checkerのような自動アクセシビリティスキャナーは、DOM構造、HTML属性、ARIAロール、計算済みスタイルを解析することで動作します。これらのツールには次のような能力がありません。

  • ファイルの音声コンテンツを解析する: スキャナーは音声ファイルや動画ファイルを開き、前景のスピーチと背景音の相対的なデシベルレベルを測定することができません。これを行うには、DOMベースのアクセシビリティチェッカーの範囲をはるかに超えた音声信号処理が必要になります。
  • 独立した背景音声コントロールが存在し正しく動作するか検出する: DOM内に「背景音楽をオフにする」とラベル付けされたUIコントロールが存在していても、スキャナーはそれがスピーチトラックに影響を与えることなく背景音声トラックを実際に抑制しているかどうかを検証できませんし、すべてのブラウザで期待どおりに動作するかどうかも検証できません。
  • スピーチと非スピーチ音声を区別する: 自動ツールは、ある音声ファイルがスピーチ主体なのか、音楽主体なのか、環境音主体なのかを信頼性高く分類できませんが、この判定はそもそもこの達成基準が適用されるかどうかを決める前提となるものです。

評価はすべて、人間のレビュアーがコンテンツを聴き、必要に応じて音声解析ソフトウェアを使ってデシベルレベルを測定することで行わなければならないため、axe-coreはこの達成基準を「手動レビューが必要」としてフラグ付けします。<audio><video>要素を含むページに対してaxe DevToolsを実行すると、ツールは音声品質の基準を手動で評価するよう促す一般的なメディア関連のアドバイザリを表示する場合がありますが、1.4.7について自動的に適合・不適合の判定を出すことはありません。

テスト方法

  1. ページ上のすべての音声コンテンツを棚卸しする。 ページを読み込み、すべての<audio>要素、音声トラックを持つすべての<video>要素、すべての埋め込みポッドキャストやメディアプレーヤー、自動再生される背景音声を特定します。それぞれの音声が事前録音であり、前景のスピーチを含んでいるかどうかを判断します。純粋な音楽トラックや、スピーチのない環境音のみであれば、1.4.7は適用されません。
  2. 自動スキャンを実行してベースラインの問題を洗い出す。 axe DevTools、Lighthouse、またはAccsibleウィジェットの組み込み監査機能を使ってページをスキャンします。これらのツールは音声品質を評価しませんが、キャプションの欠如、<audio>要素におけるcontrols属性の欠落、その他関連するメディアアクセシビリティの問題を指摘する場合があります。手動で音声評価を行う前に、指摘された問題にはすべて対処してください。
  3. 該当する各音声トラックを最後まで聴く。 ページの組み込みプレーヤーを使うか、ファイルをダウンロードしてメディアプレーヤーで開きます。特に、前景のスピーチと同時に再生される背景音楽、環境音、その他の非スピーチ音声がないかを注意して聴きます。
  4. 背景音声を独立してオフにできるか評価する。 プレーヤーが、音声トラックに影響を与えることなく背景音楽だけをミュートまたは音量を下げるための個別のコントロールを提供している場合、そのコントロールがChrome、Firefox、Safariの各ブラウザで期待どおりに動作することを確認します。キーボードのみの操作でテストし、そのコントロールがアクセシブルであることも確認します。
  5. 背景音声が存在し、オフにできない場合はデシベルレベルを測定する。 音声ファイルをAudacityなどの無料の音声編集ソフトにインポートします。内蔵の波形ビューまたはスペクトログラムビューと「Analyze > Contrast」ツール(または同等の機能)を使って、スピーチ区間の平均RMSレベルと背景音声区間の平均RMSレベルを測定します。その差が少なくとも20 dBあることを確認します。音声解析ソフトにアクセスできない場合は、経験豊富なリスナーとしての専門的判断を用いてください。軽度の難聴を持つ一般的な人が背景音声を気が散る、またはスピーチを覆い隠すと感じるようであれば、不適合の可能性が高いとみなします。
  6. 支援技術でテストする。 NVDA(Firefox)、VoiceOver(macOSのSafari)、JAWS(Chrome)を使って各音声プレーヤーに移動します。背景音声の切り替えなど、すべてのコントロールがキーボード(Tab/Shift+Tab)で到達可能であり、スクリーンリーダーによって正しく読み上げられ、EnterまたはSpaceで操作できることを確認します。これは音声品質そのものを直接テストするものではありませんが、追加した改善用コントロールがアクセシブルであることを確認するものです。
  7. 結果を記録する。 どの音声ファイルが適合(背景音声なし、ユーザーコントロールあり、または20 dB差が確認できる)、どれが不適合、どれが除外対象(2秒未満の短い効果音、またはスピーチではなく音楽が主体の音声)であるかを記録します。

修正方法

シナリオ1: 背景音楽のミックスが大きすぎる — 不適切な例

<!-- Audio file contains a narrator speaking over background music
     mixed at roughly equal volume levels. No separate control exists.
     This fails WCAG 1.4.7 because background audio is not 20 dB below speech
     and cannot be turned off independently. -->
<audio controls src='product-explainer.mp3'>
  Your browser does not support the audio element.
</audio>

シナリオ1: 背景音楽のミックスが大きすぎる — 適切な例

<!-- The audio file has been re-exported with no background music.
     If background music is desired for branding, produce two separate
     audio tracks: one speech-only and one with music. Offer the
     speech-only version as the default accessible option. -->
<audio controls src='product-explainer-speech-only.mp3'>
  Your browser does not support the audio element.
</audio>
<p>
  <a href='product-explainer-with-music.mp3'>
    Listen to version with background music (may be harder to follow for some users)
  </a>
</p>

シナリオ2: 独立したミュートコントロール付きの背景音声 — 不適切な例

<!-- A custom player claims to offer background audio control,
     but the button is not keyboard-accessible and has no accessible name.
     Sighted mouse users can click it, but screen reader users and
     keyboard-only users cannot reach or operate the control. -->
<div class='player'>
  <audio id='main-audio' src='lecture-with-ambience.mp3'></audio>
  <button onclick='document.getElementById("main-audio").play()'>Play</button>
  <div onclick='toggleBackground()' style='cursor:pointer'>
    <img src='music-icon.png'>
  </div>
</div>

シナリオ2: 独立したミュートコントロール付きの背景音声 — 適切な例

<!-- The background audio toggle is now a proper <button> element with
     an accessible name, keyboard focus, and an aria-pressed state so
     screen readers announce whether background audio is on or off. -->
<div class='player'>
  <audio id='main-audio' src='lecture-with-ambience.mp3'></audio>
  <audio id='bg-audio' src='background-ambience.mp3' loop></audio>
  <button onclick='document.getElementById("main-audio").play()'>Play lecture</button>
  <button
    id='bg-toggle'
    aria-pressed='true'
    onclick='toggleBackground()'
  >
    Background audio: on
  </button>
</div>
<script>
  function toggleBackground() {
    var bg = document.getElementById('bg-audio');
    var btn = document.getElementById('bg-toggle');
    if (bg.paused) {
      bg.play();
      btn.setAttribute('aria-pressed', 'true');
      btn.textContent = 'Background audio: on';
    } else {
      bg.pause();
      btn.setAttribute('aria-pressed', 'false');
      btn.textContent = 'Background audio: off';
    }
  }
</script>

シナリオ3: ページ読み込み時の自動再生背景音声 — 不適切な例

<!-- Background audio autoplays when the page loads and there is
     no way to turn it off. If a narrator audio also plays, the
     background audio will compete with it and cannot be suppressed. -->
<audio autoplay loop src='ambient-background.mp3'></audio>
<audio controls src='welcome-message.mp3'></audio>

シナリオ3: ページ読み込み時の自動再生背景音声 — 適切な例

<!-- Background audio does not autoplay. A clearly labeled, keyboard-
     accessible button allows the user to opt in if desired. The speech
     audio is presented independently and cleanly without competition. -->
<audio id='bg' loop src='ambient-background.mp3'></audio>
<button onclick='document.getElementById("bg").play()'>
  Play background music (optional)
</button>
<audio controls src='welcome-message.mp3'>
  Your browser does not support the audio element.
</audio>

よくある間違い

  • 背景音楽を必要な-20 dBではなく-10 dBでミックスしてしまう: 制作者は背景音楽の音量を少し下げれば十分だと考えがちです。しかしWCAG標準では、単に「少し小さい」ではなく、20 dB(おおよそ4倍静か)という十分な差が求められます。主観的な判断だけに頼らず、必ず音声解析ツールで確認してください。
  • プレーヤー全体の音量コントロールと独立した背景音声コントロールを混同する: スピーチと背景音声の両方を同時に下げるマスターボリュームスライダーは、「ユーザーが背景音声をオフにできる」という条件を満たしません。コントロールは前景のスピーチに影響を与えず、背景音声だけを抑制しなければなりません。
  • この達成基準が単体の音声ファイルにのみ適用されると誤解する: 多くの開発者は、video要素の音声トラックにも1.4.7が同様に適用されることを見落としています。背景音楽が大きくミックスされた動画の解説は、ポッドキャストファイルと同様にこの達成基準に不適合となります。
  • すべての短い音を除外対象とみなす: 短い効果音に対するWCAGの除外は、2秒以下の音にのみ適用されます。数秒ごとに繰り返される短いジングルや、短い音のループで構成された背景音は、この除外の対象ではなく、依然として要件を満たす必要があります。
  • 背景音声の切り替えボタンをキーボードのみの操作でテストしない: チームはしばしば、<div><span>のような非インタラクティブ要素を使って見た目の良いミュートボタンを実装しますが、これらはTabキーでフォーカスできず、EnterやSpaceで操作することもできません。キーボードと支援技術のサポートを標準で備えたネイティブの<button>要素を使用してください。
  • 背景音声の切り替えボタンにaria-pressedなどの状態を付与し忘れる: 状態インジケーターがないと、スクリーンリーダーユーザーはボタンを操作できても、現在背景音声がオンなのかオフなのかを知ることができません。ボタンのアクセシブルネームに現在の状態を反映するか、aria-pressedを使って必ず状態を示してください。
  • 別トラックを提供せず、1つのミックス済み音声ファイルだけを制作する: 背景音声が創作意図にとって不可欠な場合でも、チームはしばしば単一のミックス済みファイルだけを書き出し、スピーチのみの代替版を提供しません。スピーチのみの別バージョンを提供することは、追加の制作コストがほとんどかからず、コンプライアンスリスクを完全に排除できます。
  • ライブ音声ストリームに1.4.7を適用してしまう: この達成基準は明示的に事前録音の音声のみを対象としています。ライブ音声放送はこの特定のルールの対象ではありませんが、1.4.4(テキストのサイズ変更)やキャプション要件など、関連する他の達成基準が適用される場合があります。
  • サードパーティの埋め込みプレーヤーを確認しない: コンテンツが外部プラットフォーム(ポッドキャストホスティング、動画CDN、音声共有サービス)から埋め込まれている場合、チームはしばしばコンプライアンスはプラットフォーム側の責任だと考えがちです。しかし、ページ所有者は、埋め込みメディアを含むページ上のすべてのコンテンツのアクセシビリティについて責任を負います。サードパーティのプレーヤーが音声品質の要件を満たしているか、または必要なコントロールを提供しているかを必ず確認してください。
  • 20 dB要件の確認にピークレベルではなく平均RMSレベルを使わない: WCAG 1.4.7の20 dB閾値は、音声の知覚上の大きさを指しており、瞬間的なピークレベルではなく、平均RMS(Root Mean Square)レベルで最もよく近似されます。ピークレベル測定を用いると、実際の聴取体験を反映しない、過度に好意的な測定結果が出てしまう可能性があります。

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

2025年6月21日付官報第32933号で公布されたトルコ大統領通達2025/10は、トルコで事業を行う幅広い公的・民間セクターの組織に対して、デジタルアクセシビリティ要件の遵守を義務付けています。この通達は、技術的標準としてWCAG 2.2を採用し、組織の種類に応じて具体的な適合義務を定めています。

通達の下で遵守が義務付けられている主体には、あらゆるレベルの公的機関・政府機関、eコマースプラットフォーム、銀行および金融サービス提供者、病院および医療機関、20万件以上の加入者を持つ通信事業者、認可を受けた旅行代理店、民間の交通事業者、国民教育省(MoNE)に認可された私立学校が含まれます。これらの組織は、少なくともWCAG 2.2レベルAおよびレベルAAを満たすことが求められます。

WCAG 1.4.7「背景音が小さい、または無い」はレベルAAAの達成基準です。これは、2025/10通達のベースライン要件の下で、対象組織が法的に満たす義務のある達成基準には含まれていないことを意味します。しかし、いくつか重要な点があります。第一に、AAA適合を自主的に約束している組織や、病院、聴覚クリニック、社会福祉機関など、聴覚障害者が多く利用する組織は、自らの状況において1.4.7を事実上必須とみなすべきです。第二に、音声ベースの教材コンテンツ、カスタマーサービスの録音、eラーニングモジュール、一般向けの情報放送などのデジタルサービスを提供しているあらゆる主体にとって、1.4.7を満たすことは、聴覚障害のあるトルコ市民に対するこれらサービスの実際の使いやすさを大幅に向上させることになります。

トルコには多くの聴覚障害者が存在しており、この通達は、平等なデジタル参加を確保しようとする政府のコミットメントを反映しています。AAA達成基準は技術標準上は「目標水準」と位置付けられていますが、特にトルコの公的機関は、コンテンツとリソースが許す限り、最低要件を上回ることが奨励されています。1.4.7への適合を示すことは、組織としての成熟度を示し、法的・評判上のリスクを低減し、AAA適合が契約上求められる可能性のある国際市場を含め、トルコのデジタルサービスをインクルーシブデザインのリーダーとして位置付けることにつながります。