WordPressのWCAG 2.2音声コンプライアンス:2026年版ガイド

2 分で読める 29 分で聴ける
WordPressのWCAG 2.2音声コンプライアンス:2026年版ガイド

WordPressの音声機能は、少なくとも4つのWCAG 2.2達成基準を満たす必要があります。1.4.2(音声制御)2.1.1(キーボード)2.5.8(ターゲットサイズ)(2.2で新設)、4.1.2(名前・役割・値)です。欧州アクセシビリティ法(EAA)は2025年6月28日から施行されており、EUのユーザーにサービスを提供するすべてのサイトに法的義務が生じています。WordPressのデフォルト音声プレーヤーや多くのサードパーティ製音声プラグインは、修正なしではこれらの要件のいくつかを満たしていません。

このガイドは、MementoがWordPressサイトのWCAG 2.2適合性を監査する際に使用している実践的なチェックリストです。音声をコンテンツとして扱う場合のアクセシビリティルールと、テキストコンテンツのアクセシビリティ機能としての音声、両面にわたって解説します。

2026年に音声コンプライアンスが重要な理由

2025年、3つの動きが重なりこの問題が急務となりました。EAAが2025年6月28日から施行され、WebAIM Million 2025レポートではホームページの96.3%で検出可能なWCAG違反が確認されました。米国でのADA訴訟も増加し続け、その年に提起されたウェブアクセシビリティ関連訴訟4,000件超の中にWordPressサイトが多数含まれています。

監査で繰り返し目にするパターンがあります。サイト運営者はテーマがアクセシビリティを担保していると思い込んでいます。テーマは音声プラグインの実装をそのまま引き継ぎます。その音声プラグインは、ボタンが小さすぎ、スライダーがキーボードユーザーを操作不能にし、コントラスト比も最初の手動チェックで不合格になります。

WCAG 2.2音声対応チェックリスト(完全版)

WordPressサイトの音声に直接関わる達成基準は8つあります。以下の表では、各基準の実務的な意味、WordPressデフォルト音声の合否、そしてTTSWPプレーヤーの対応状況をまとめています。「NEW」の付いた基準は2023年10月のWCAG 2.2で新設されたものです。

基準レベル内容WPデフォルト音声TTSWPプレーヤー
1.2.1 音声のみ・映像のみA音声のみのコンテンツにはテキスト代替が必要 テーマに依存 ページテキストが代替として機能
1.4.2 音声制御A3秒超の自動再生音声には一時停止・停止手段が必要 ブラウザネイティブコントロール ユーザー操作による再生のみ
1.4.3 コントラスト(最低限)AAプレーヤーUIのテキストと意味のあるアイコンに4.5:1以上 テーマに依存 デフォルトで4.5:1以上を達成
2.1.1 キーボードAすべてのコントロールをキーボードで操作可能にする ブラウザに依存 フルキーボード対応
2.4.11 フォーカスの非遮蔽 NEWAA固定要素がフォーカス中のコンテンツを隠してはならない 対象外 フォーカス競合時にバーが退避
2.5.7 ドラッグ操作 NEWAAドラッグ操作には単一ポインタによる代替手段が必要 スライダーがドラッグのみ対応 クリック位置指定+矢印キー対応
2.5.8 ターゲットサイズ NEWAAインタラクティブなターゲットは24×24CSSピクセル以上 テーマに依存 すべてのコントロールが24px以上
4.1.2 名前・役割・値A各コントロールにアクセシブルな名前・役割・状態を付与 部分的に対応 ARIAを完全実装

W3Cのメディアアクセシビリティユーザー要件ページがこれらの基準の正式な参照先です。上記の8つは音声プレーヤー自体に適用されるものに絞っています。キャプション(1.2.2)と音声解説(1.2.3)も関連しますが、これらは動画に適用されるものであり、純粋な音声ナレーションには該当しません。

WordPressサイトの音声に関わる8つのWCAG 2.2達成基準を示す図
WordPressサイトの音声に関わるWCAG 2.2達成基準は8つあります。そのうち3つは2.2で新設されました。

テキストのメディア代替という例外規定

コンプライアンス関連の記事の95%が見落としているルールがあります。WCAGはテキストのメディア代替を「テキストで既に提供されている情報以上のものを含まないメディア」と定義しています。TTSナレーションが既存の記事を読み上げる場合、その音声はページテキストのメディア代替です。ページテキスト自体がトランスクリプトになります。

つまり、記事のTTS音声版には別途トランスクリプトファイルが不要です。WebAIMもこの点を明確に説明しています。ただし、音声がメディア代替であることを明確にラベル付けし、スキップしても情報を見逃さないことをユーザーが理解できるようにする必要があります。「この記事を聴く」という見出しや「この記事の音声版」というプレーヤーラベルがあれば十分です。

この例外は、音声にコメンタリーや意味のある音楽、テキストにない内容が含まれる場合には適用されません。ページコンテンツの純粋なナレーションであれば該当します。音声追加によって新たなトランスクリプト義務が生じると心配するパブリッシャークライアントへのアドバイスでは、この規定を頻繁に活用しています。

WCAG 2.2で音声に関わる変更点

音声プレーヤーに直接影響するレベルAAの新基準が3つあります。

2.5.8 ターゲットサイズ(最低限)

すべてのインタラクティブコントロールには、24×24CSSピクセル以上のターゲットが必要です。この基準が最も多くのWordPress音声プラグインを不合格にしています。サードパーティ製音声プラグインを使用するWordPressサイトの監査では、スキップバックボタンとスキップフォワードボタンが一貫してこの閾値を下回っています。WCAG 2.2で24ピクセルルールが導入される前、ビジュアルデザイナーはコンパクトさを優先しており、プラグイン開発者の多くがまだ対応できていません。テーマのデフォルトスタイルがさらにターゲットを小さくするケースもあります。

修正はアイコンサイズではなく、パディングで対応するのが通常です。各辺に4ピクセルのパディングを持つボタン内の16ピクセルSVGアイコンは、見た目を変えずに24ピクセルの閾値を達成できます。

2.4.11 フォーカスの非遮蔽

ページ下部の固定音声バーは、キーボードユーザーがフォーカスしている要素を隠してしまいます。フォーカスされたリンクがバーの後ろにある場合、この基準は不合格です。バーを閉じられるようにするか、フォーカスターゲットの上に余白を確保するか、ドキュメントにscroll-padding-bottomを設定してフォーカス要素が常に見えるようにするかのいずれかで対応できます。

2.5.7 ドラッグ操作

ドラッグ操作のみに対応したカスタムスクラブバーやボリュームスライダーはこの基準を満たしません。すべてのドラッグ操作には単一ポインタによる代替手段が必要です。プログレスバーへのクリックで位置指定できれば要件を満たします。適切に構築されたrole="slider"へのキーボード矢印キー操作も同様です。

実際の監査で見つかったWordPress音声の問題

クライアントサイトで同じパターンが繰り返されます。よく見られる問題は4つです。

WordPressコアのデフォルト<audio>ブロックはブラウザネイティブプレーヤーをレンダリングします。ブラウザネイティブ音声コントロールはスクリーンリーダーとの動作が一貫しない長い歴史があり、再生位置の矢印キー操作はChrome、Firefox、Safariで異なります。NVDAやJAWSを使用するユーザーはタイムスタンプは聞こえますが、キーボードで再生位置を確実に移動できないことが多いです。適切なARIA値属性を持つrole="slider"を公開するカスタムプレーヤーで音声をラップすることが修正方法です。

プラグインのプレーヤーには24ピクセル未満のボタンが含まれています。WCAG 2.2でルールが導入される前、ビジュアルデザイナーはコンパクトさを優先していました。テーマがプラグインスタイルを上書きすることで、状況が改善されることも悪化することもあります。

固定音声バーがフォーカスされたコンテンツを隠します。キーボードナビゲーションをテストしていない固定フッタープレーヤーを使用するすべてのサイトで、この問題を確認しています。

波形のコントラストは常に4.5:1を下回っています。デザイナーは白地に薄いグレーの波形を好みます。スクリーンリーダーには関係ありませんが、ロービジョンのユーザーには問題であり、1.4.3が不合格となります。

アクセシブルな音声プレーヤーの構築:技術チェックリスト

  1. プレーヤーをrole="region"でラップし、内容を説明するaria-labelを付与する。
  2. 再生、一時停止、スキップ、ミュートには必ず本物の<button>を使用する。クリックハンドラーを持つ<div>は使わない。
  3. 再生ボタンにaria-pressedを設定してトグル状態を伝える。
  4. パディングを使用してすべてのコントロールのターゲットを最低24×24CSSピクセルにする。
  5. スクラバーとボリュームをrole="slider"に設定し、aria-valueminaria-valuemaxaria-valuenowを付けて矢印キーに対応させる。
  6. ドラッグの代替として、スクラバーへのクリック位置指定を提供する。
  7. すべてのテキスト要素と意味のあるアイコンのコントラストを最低4.5:1でテストする。
  8. フォーカスリングが見えており、overflowルールで切り取られていないことを確認する。
  9. プレーヤーを固定する場合は、フォーカス用の余白を上に確保するか、閉じられるようにする。
  10. TTSナレーションプレーヤーを「この記事の音声版」とラベル付けして、メディア代替例外が適用されるようにする。

最小限のアクセシブルな再生ボタンの実装例は以下の通りです。

<div role="region" aria-label="Article audio player">
  <button type="button"
          aria-pressed="false"
          aria-label="Play article narration"
          style="min-width:24px;min-height:24px;padding:8px">
    <svg aria-hidden="true" width="16" height="16">...</svg>
  </button>
  <input type="range"
         aria-label="Playback position"
         min="0" max="100" value="0">
</div>

これが骨格です。ボタンのスタイルを整え、カスタムトラックを使いたい場合はネイティブのrange表示を非表示にしても構いません。ただし、基盤となるセマンティクスは維持してください。

TTSナレーションによるWCAG全体の適合性向上

音声はアクセシブルにすべきコンテンツであると同時に、それ自体がアクセシビリティ機能でもあります。世界保健機関の推計では、世界人口の約16%にあたる13億人が何らかの重大な障害を持って生活しています。ディスレクシア、ADHD、ロービジョン、さまざまな認知障害を持つ人々の多くが、テキストと音声を組み合わせたマルチモーダルなアクセスで読みやすさを向上させています。

音声読み上げナレーションの追加は、監査要件を満たす前にユーザーを直接助ける数少ないアクセシビリティ投資のひとつです。WordPressへのTTS追加は、Text to Speech – TTSWPプラグインを使えば15分以内で完了します。プレーヤーはWCAG 2.1 AAに準拠したデフォルト設定、24ピクセル以上のターゲット、キーボードサポート、適切なARIAロールを備えています。

TTSWPを有効にした記事のGTmetrixパフォーマンスレポート
TTSWPプレーヤーが有効な公開記事のGTmetrixパフォーマンスレポート。全項目でグレードAを達成し、累積レイアウトシフトはゼロです。

最小ランタイムペイロードはgzip圧縮後で約35〜40KB(非圧縮時151KB)で、JavaScriptプレーヤーロジックと共有CSSの両方をカバーしています。プレーヤーが有効な公開記事でGTmetrixを実行した結果、グレードA、パフォーマンス93%、ストラクチャー99%、LCP 1.3秒、TBT 46ミリ秒、CLS 0を達成しました。バンドルはプレーヤーを含むページでのみ遅延読み込みされるため、音声のない静的ページに余分なオーバーヘッドは発生しません。

アクセシビリティに関するドキュメントはアクセシビリティ信頼ページで確認できます。ナレーションにはElevenLabsの生成エンジンを使用しており、韻律が十分に改善されているため、リスナーが機械的な読み上げで離脱することなく最後まで記事を聴き続けます。

欧州アクセシビリティ法(EAA)の実務

EAAは2025年6月28日から執行可能となりました。それ以降にEU市場に投入された新しいデジタルサービスは現時点で準拠が必要です。既存のサービスは2030年6月28日までに完全に適合させる必要があります。この指令は、事業所の所在地に関わらず、EUのユーザーにサービスを提供するすべての企業に適用されます。

EAAが参照する技術規格はEN 301 549です。現在の調和版(V3.2.1、2021年8月)はWCAG 2.1レベルAAを基盤としています。2025年11月に公開されたドラフトV4.1.0では、第9条、第10条、第11条をWCAG 2.2に合わせて更新しており、2026年中に最終的な調和が見込まれています。この更新がEU官報に掲載されるまでは、WCAG 2.1 AAが法的に拘束力を持つ最低基準ですが、移行まで年単位ではなく月単位であることから、今すぐ2.2を目標にすることを推奨します。

罰則は加盟国によって異なります。ドイツとフランスは最も積極的な執行体制を持ち、国家アクセシビリティ当局が苦情を調査し罰金を科す権限を持っています。施行日から数ヶ月以内に、日本企業を含む欧州クライアントがエンドユーザーから正式な苦情を受けるケースがあり、通常は音声とフォームコンポーネントに関するものです。苦情は罰金より先に届くため、チームが準備できていれば30日間の修正期間は通常達成可能です。

コンプライアンスのテスト方法

自動化ツールは問題の約30〜40%を検出します。残りは手動テストが必要で、特にキーボード操作や動的状態での意味のあるコントラストの確認が求められます。

  • NVDA:Windows上でChromeとFirefoxで使用。無料。
  • JAWS:エンタープライズクライアントの要件確認にWindows上で使用。
  • VoiceOver:macOSとiOSに標準搭載。
  • TalkBack:Androidに標準搭載。
  • axe DevTools:自動スキャン用ブラウザ拡張機能。
  • Lighthouse:Chrome DevToolsでの簡易チェック。
  • キーボードのみによる操作確認。マウスを外してすべてのプレーヤーコントロールを操作する。

キーボードのみによる操作確認が、最も費用対効果の高いテストです。マウスなしでプレーヤーが動作すれば、WCAG 2.2のほとんどの要件はすでに満たされています。

よくある質問

WCAG 2.2では音声ポッドキャストにキャプションが必要ですか?

不要です。キャプション(1.2.2)は同期した音声を持つ収録済み動画に適用されます。ポッドキャストのような音声のみのコンテンツに関連するのは1.2.1で、トランスクリプトや詳細な要約などのテキスト代替が必要です。キャプションとトランスクリプトは異なる目的を持ちます。ポッドキャストにはトランスクリプトが必要で、動画チュートリアルには映像のみの情報のためにキャプションと音声解説の両方が必要です。

EAAのもとで自動再生音声は違法ですか?

違法ではありませんが、制限があります。EAAがEN 301 549を通じて参照するWCAG 1.4.2(音声制御)では、3秒を超えて自動再生される音声には一時停止、停止、または独立したボリューム制御が必要です。その制御なしの自動再生はレベルAを不合格とし、不適合の指摘事項となります。ほとんどの執行機関はこれをグレーゾーンではなく明確な違反として扱います。

記事の音声版がある場合、トランスクリプトは必要ですか?

通常は不要です。音声が記事テキストの直接ナレーションであり新しい情報を含まない場合、WCAGの「テキストのメディア代替」の定義のもとで、記事テキスト自体がトランスクリプトとなります。プレーヤーを記事の音声版として明確にラベル付けすれば例外が適用されます。音声にコメンタリー、意味のある音楽、またはテキストにないセクションが含まれる場合は、別途トランスクリプトが必要です。

WCAG 2.2での音声プレーヤーの最小ボタンサイズは?

レベルAAの達成基準2.5.8「ターゲットサイズ(最低限)」のもとで、インタラクティブなターゲットは24×24CSSピクセル以上が必要です。ターゲットにはパディングが含まれるため、各辺4ピクセルのパディングを持つ16ピクセルアイコンは要件を満たします。テキスト内のインラインリンクやユーザーエージェントが決定するコントロールには例外がありますが、独立したプレーヤーボタンには例外がなく、閾値を満たす必要があります。

WCAG 2.2はWordPress.comホストのサイトにも適用されますか?

はい。WCAGはホスティングプラットフォームに関わらず、あらゆるウェブコンテンツに適用されます。WordPress.comのサイトも、セルフホスト型WordPressと同様にEAA、ADA、各国の同等法律のもとで同じ法的リスクを負います。ホスティング形態は義務を変えません。変わるのは、サイト運営者がプレーヤーのマークアップをどれだけコントロールできるかです。WordPress.com BusinessプランとCommerceプランではカスタムプラグインが使用できますが、下位のプランでは使用できません。

まず何から始めるか

サイト内の記事を1つ選び、音声プレーヤーのキーボードのみによる操作確認を行い、すべてのボタンを24ピクセルルールと照合してください。その1回の監査で、現在の設定がWCAG 2.2適合に近いのか遠いのかが明確になります。そこから、既存のプレーヤーを修正するか、デフォルトで準拠している設計のものに置き換えるかを選択できます。EAAへの対応が求められるサイトに推奨する設定については、アクセシビリティドキュメントをご覧ください。