ログイン

WCAGとは何か？ウェブコンテンツアクセシビリティガイドラインの解説

1 min read
Wcag基準アクセシビリティ

WCAG（Web Content Accessibility Guidelines、ウェブコンテンツアクセシビリティガイドライン）は、障害のある人々がウェブサイトを利用できるようにするための世界的な標準です。このガイドでは、WCAGとは何か、その原則と適合レベルがどのように機能するのか、WCAG 2.2で何が変わったのか、そして非準拠が組織にどのようなコストをもたらすかを解説します。

上位100万件のウェブサイトのうちほぼ94.8%が基本的なアクセシビリティ基準に不合格であり、1つのホームページあたり平均約51件の検出可能なエラーがあります。一方で、2025年だけでも米国では5,100件以上のADA（障害を持つアメリカ人法）に基づくデジタル・アクセシビリティ訴訟が提起されており、アクセシビリティを無視することによる法的・評判上のコストは急速に高まっています。あなたが運営しているのがECストアであれ、SaaSプラットフォームであれ、政府ポータルであれ、ほぼすべてのアクセシビリティの議論の中心にある文書が1つあります。それがWCAG、Web Content Accessibility Guidelines（ウェブコンテンツ・アクセシビリティ・ガイドライン）です。WCAGとは何か、なぜ存在するのか、そして実際にあなたに何を求めているのかを正確に知りたいと思ったことがあるなら、このガイドはまさにあなたが探していた、平易な英語での説明です。

WCAGの起源：この標準はどこから来たのか

WCAGはWeb Accessibility Initiative（WAI）によって公開されています。WAIはWorld Wide Web Consortium（W3C）のプログラムであり、HTMLやCSS、その他ウェブの基盤となる多くの技術を標準化しているのと同じ国際機関です。このガイドラインが存在するのは、ウェブがその本質として「誰もが利用できる」という約束を担っているからです。実際には、意図的なデザイン上の選択を行わなければ、その約束は何百万人ものユーザーにとって崩れ去ってしまいます。

ウェブアクセシビリティ・ガイドラインのルーツは1995年にさかのぼります。この年、Gregg Vanderheidenが、Tim Berners-Leeが第2回World-Wide Web国際会議の基調講演で障害者アクセスに言及した直後に、最初のウェブアクセシビリティ・ガイドラインをまとめました。その後数年のうちに、さまざまな著者や組織から38を超えるウェブアクセス・ガイドラインが生まれ、最終的にはウィスコンシン大学マディソン校のUnified Web Site Accessibility Guidelinesへと収束しました。1998年に公開されたその文書のバージョン8がWCAG 1.0の出発点となり、1999年5月5日に正式なW3C勧告となりました。

WCAG 2.0は2008年12月に登場し、2012年10月にはISO標準（ISO/IEC 40500:2012）として採用されるほど重要なものとなりました。2018年6月に公開されたWCAG 2.1は、モバイルの使いやすさ、ロービジョン、認知アクセシビリティに焦点を当てた17の新しい達成基準を追加することで2.0の基準を拡張しました。そして現在のバージョンであるWCAG 2.2は、2023年10月5日にW3C勧告として公開され、その後ISO/IEC 40500:2025として承認されています。W3Cは全員が最新バージョンを使用することを推奨しており、それにはもっともな理由があります。WCAG 2.2に適合するコンテンツは、自動的にWCAG 2.1およびWCAG 2.0にも適合するからです。

WCAGが何であり、何でないのかを明確にしておく価値があります。WCAGは技術標準であり、世界中の個人や組織と協力しながら、厳格なマルチステークホルダー型のW3Cプロセスを通じて策定された、正確でテスト可能な仕様です。それ自体は法的文書ではありませんが、世界中の数多くの法域で法律や規制に参照形態で組み込まれており、事実上、世界のデジタル・アクセシビリティのルールブックとなっています。

WCAGは誰を支援するためのものか

WCAGは、視覚、聴覚、身体、発話、認知、言語、学習、神経系など、幅広い障害を持つ人々にとってのアクセシビリティ障壁に対処します。これは驚くほど広い人口層です。世界保健機関（WHO）は、約13億人、つまり世界人口の約16%が、日常生活やオンラインアクセスに影響を与える何らかの障害を抱えていると推計しています。これらの人々の誰もが、今まさにあなたのウェブサイトを利用しようとしている潜在的な顧客、市民、学生、あるいは従業員であり得ます。

しかし、WCAGに準拠することの恩恵は、恒常的な障害を持つユーザーをはるかに超えて広がります。このガイドラインは、加齢に伴う制限（視力の低下、聴力の低下、運動反応の遅れ）を持つ高齢者にも役立ち、しばしばすべての人にとっての使いやすさを向上させます。たとえば動画のキャプションは、もともとろう者のために設計されたものですが、騒がしい環境で視聴している人、内容を追う非ネイティブ話者、聞くより読む方を好む人にも役立ちます。同様に、キーボードでの操作性は、マウスを遅く感じるパワーユーザーを助け、十分な色コントラストは、屋外の明るい画面を見て目を細めている誰にとっても役立ちます。

WCAGはまた、デスクトップ、ラップトップ、キオスク、モバイルデバイスなど、ほぼあらゆる種類のデジタルデバイス上のコンテンツを対象としており、意図的に技術中立です。達成基準は特定の技術を指定しないテスト可能な文として書かれているため、HTML、JavaScriptフレームワーク、支援技術が進化し続けても、基準は有効であり続けます。

POUR原則：WCAGの概念的な土台

WCAGのすべての達成基準（バージョン2.2では全86項目）は、頭文字を取ってPOURと呼ばれる4つの最上位原則の下に整理されています。これらの原則は標準全体の概念的な土台を提供します。これを理解することで、個々の達成基準を1つも読まなくても、アクセシビリティに関する直感的なメンタルモデルを得ることができます。

  • Perceivable（知覚可能）: 情報とユーザーインターフェイスの構成要素は、ユーザーが知覚できる方法で提示されなければなりません。実務的には、コンテンツがユーザーのすべての感覚に対して「見えない」状態であってはならないということです。ユーザーが画像を見ることができない場合は、スクリーンリーダーを通じて聞くことができるテキストの代替が必要です。動画に音声ナレーションがある場合は、聞くことができないユーザーのためにキャプションが必要です。この原則の下での実務的な要件には、画像の代替テキスト（altテキスト）、動画のキャプション、テキストと背景の十分な色コントラスト、コンテンツを失うことなくテキストを拡大できることなどが含まれます。
  • Operable（操作可能）: ユーザーインターフェイスの構成要素とナビゲーションは操作可能でなければなりません。どのようなインタラクションも、ユーザーが実行できない入力を要求してはなりません。最も一般的な含意は、すべての機能がマウスだけでなくキーボードだけでも実行できなければならないということです。この原則にはまた、ユーザーがコンテンツを読み、操作するための十分な時間を与えること、発作を引き起こす可能性のあるコンテンツを避けること、サイトをナビゲートする複数の方法を提供することも含まれます。
  • Understandable（理解可能）: 情報とユーザーインターフェイスの操作は理解可能でなければなりません。コンテンツがあまりに複雑または混乱していて、ユーザーが意図されたとおりに利用できないようではいけません。これには、読みやすい言語（スクリーンリーダーが正しい発音を使えるよう、コード内でページの言語を指定することを含む）、予測可能なページ挙動、明確な指示、何が問題だったのかとその解決方法をユーザーに伝える有用なエラーメッセージが含まれます。
  • Robust（堅牢）: コンテンツは、支援技術を含む多様なユーザーエージェントによって確実に解釈できるほど堅牢でなければなりません。堅牢なサイトは、スクリーンリーダーや点字ディスプレイなどの支援ツールがコンテンツを正しく解析し伝達できるよう、クリーンで妥当なセマンティックマークアップを使用します。これは現在だけでなく、技術が進化した将来においても同様です。
POURを、あなたのウェブサイトのあらゆる要素が通過しなければならない4つのフィルターだと考えてください。あるコンポーネントが4つのフィルターのうち1つでも通過できなければ、それは一部のユーザーにとって障壁である可能性が高いのです。

これら4つの原則は、2.0、2.1、2.2とWCAGのすべてのバージョンを通じて安定しており、その下にある具体的な達成基準が増え、進化してきたとしても変わっていません。この安定性により、POURは、特定の法律がどのバージョンを参照しているかにかかわらず、アクセシビリティを評価するための持続的なレンズとなっています。

適合レベル：A、AA、AAAの説明

4つのPOUR原則の下には13のガイドラインがあり、そのガイドラインの下に、実際にWCAG適合を主張するために満たさなければならない86のテスト可能な達成基準が存在します。各達成基準には3つの適合レベルのいずれかが割り当てられています。

  • レベルAは最低レベルです。これは最も重要な要件であり、特定のユーザーがコンテンツにまったくアクセスできなくなるほど重大な障壁を表します。例としては、非テキストコンテンツにテキストによる代替を提供すること、すべての機能をキーボードで操作可能にすることなどがあります。レベルAだけでは、ほとんどの規制目的には十分ではありませんが、これに不適合であることは根本的な失敗を意味します。
  • レベルAAは中間レベルの標準であり、世界中の法律や規制の大多数が要求しているレベルです。これはすべてのレベルAの基準を満たしたうえで、テキストと背景のコントラスト比を少なくとも4.5:1にすること、ページ間で一貫したナビゲーションを提供すること、事前録画された動画にキャプションを提供することなどの追加要件を満たすことを意味します。米国のSection 508、欧州のEN 301 549、カナダ・オンタリオ州のAODAを含む、世界のほとんどのアクセシビリティ法はレベルAAへの適合を求めています。これはほぼすべての組織が優先すべき目標です。
  • レベルAAAは最も高い標準であり、普遍的に達成可能というよりは、理想的な目標としての基準を含みます。W3C自身も、すべての種類のコンテンツに対してすべてのAAA基準を満たすことは不可能であると認めており、そのためこれらの基準が一般的なポリシー要件として設定されることは通常ありません。例としては、すべての音声コンテンツに手話通訳を付けること、読解レベルを中等教育前期程度より難しくしないことなどがあります。

重要なニュアンスが1つあります。適合レベルは累積的です。レベルAAを達成するということは、レベルAのすべての基準も満たしているということです。レベルAAAを達成するということは、AとAAも満たしているということです。そして重要なのは、各レベルでの適合は「全てか無か」です。あるページでAAの達成基準が1つでも満たされていなければ、そのページについてAA適合を主張することはできません。

ほとんどの組織にとって、WCAG 2.2レベルAAが適切な目標です。これは法律に組み込まれているレベルであり、裁判所がベンチマークとして用いるレベルであり、あなたのデジタル体験を可能な限り広いオーディエンスに実質的に開くレベルです。

WCAG 2.2で何が変わったか：9つの新しい達成基準

2023年10月に公開されたWCAG 2.2は、WCAG 2.1のすべてに加えて9つの新しい達成基準を追加しました。これらの追加は、特に認知障害、運動障害、ロービジョンを持つユーザーが、従来のガイドラインでは十分に対処されていなかった頻繁な障壁にどこで直面しているのかに関する継続的な調査によって促されたものです。WCAG 2.2は既存のWCAG 2.1の要件を削除したり変更したりするものではなく、それらを拡張するものです。

9つの新基準のうち、4つはレベルAA（したがってほとんどの組織にとって法的に重要）、2つはレベルA、3つはレベルAAAです。ここでは、AA以下の各基準が実務上何を意味するのかを説明します。

  • 2.4.11 フォーカスの非隠蔽 — 最小限（AA）: キーボードユーザーがインタラクティブなコンポーネントにナビゲートしたとき、そのコンポーネントが他の制作者が作成したコンテンツによって完全に隠されてはなりません。これは、モダンなデザインパターンでよく見られる問題に直接対応するものです。つまり、固定ヘッダー、クッキーバナー、固定フッターなどがページコンテンツの上にスライドし、キーボードフォーカスを静かに飲み込んでしまい、ユーザーがページ上のどこにいるのか視覚的な手がかりがないまま取り残されてしまう状況です。
  • 2.5.7 ドラッグ操作（AA）: ドラッグ操作を必要とする機能（ドラッグ＆ドロップによるファイルアップロード、並べ替え可能なリスト項目、カスタムスライダーなど）は、ドラッグを必要としない単一ポインタの代替手段を持たなければなりません。手の震えや細かい運動制御の制限があるユーザーにとって、ポインタを画面上で動かしながら継続的に押し続けることはほとんど不可能な場合があります。クリックして選択し、もう一度クリックして配置する代替手段や、並べ替え可能なリストに上下矢印ボタンを設けることなどで、この問題を解消できます。
  • 2.5.8 ターゲットサイズ — 最小限（AA）: ボタンやリンクなどのインタラクティブなターゲットは、少なくとも24×24 CSSピクセルでなければなりません。小さなタップターゲットは、運動障害のあるモバイルユーザーや高齢ユーザー、そして実際にはスマートフォンで何かをしながら操作している誰にとっても、使い勝手の悪さとしてよく知られた問題です。
  • 3.3.8 アクセシブルな認証 — 最小限（AA）: 認証プロセスは、代替手段が提供されない限り、従来型のCAPTCHAのような文字認識やパズル解決を要求する認知機能テストをユーザーに課してはなりません。これは、ログインや登録フローで標準的なCAPTCHAチャレンジを使用しているあらゆるサイトにとって重要な基準です。解決策としては、パスワードマネージャーのサポート、メールやSMSによるマジックリンク、生体認証、オブジェクト認識型の代替手段などがあります。
  • 3.2.6 一貫したヘルプ（A）: サイトが複数のページでヘルプ機能（ライブチャットボタン、FAQリンク、サポート電話番号など）を提供している場合、その機能はページ間で同じ相対位置に表示されなければなりません。ヘルプを必要とする認知障害のあるユーザーは、毎回探さなくても、どこに行けばヘルプが見つかるのかを正確に把握できることで大きな恩恵を受けます。
  • 3.3.7 再入力の不要化（A）: マルチステッププロセスでユーザーが以前に入力した情報は、再入力を要求するのではなく、自動入力されるか選択可能でなければなりません。これは、フォーム入力が特に負担となる認知障害や運動障害のあるユーザーにとって摩擦を減らします。

WCAG 2.2では、2.1の基準のうち1つ、4.1.1 構文解析が正式に削除されました。この基準はもともと、支援技術がマークアップを正しく解析できるよう、厳密に妥当なHTMLを要求するものでした。しかし、現代のブラウザや支援技術は独自のエラー訂正メカニズムによって不正なマークアップを堅牢に処理できるようになっており、この基準はアクセシビリティの観点から実質的な意味を持たなくなったため、廃止されました。

WCAGと法律：不適合が実際に招くコスト

WCAGは技術標準であり、法律ではありません。しかし、ほとんどの主要な法域でデジタル・アクセシビリティの法的枠組みに織り込まれており、適合していないことは現実的な法的リスクを伴います。

米国では、ADAやSection 508は文面上WCAG 2.2を明示的に名指ししてはいないものの、訴訟や執行において技術的なベンチマークとして一貫してWCAGが用いられています。司法省は2024年に最終規則を公表し、Section 508の遵守および州・地方政府に適用されるADA第2編の遵守における公式標準としてWCAG 2.1レベルAAを定めました。オンラインで事業を行うほとんどの民間企業を含む「公共施設」に適用されるADA第3編は、私人による訴訟を通じて積極的に執行されています。2024年には、デジタル資産に関連するADA訴訟が連邦および州裁判所で4,000件以上提起され、その傾向は2025年にかけても上昇し続けました。ADAの初回違反に対する民事罰は2024年にインフレ調整され、現在では最大$115,231に達し、再犯の場合は$230,464にまで増加します。

欧州でも状況は同様に重要です。European Accessibility Act（EAA、欧州アクセシビリティ法）は2025年6月28日にEU加盟国で法的に適用され、ウェブサイト、アプリ、電子書籍、ECプラットフォーム、PDFに対してWCAG 2.1 AA基準への適合を求めています。欧州標準EN 301 549は現在WCAG 2.1を参照しており、次のバージョンではWCAG 2.2への更新が見込まれています。欧州に事業拠点を持つ組織にとって、EAAへの準拠はもはや任意ではありません。

訴訟データはまた、中小企業にとって特に痛みを伴うパターンも浮き彫りにしています。「小規模でいれば安全だ」という考えは神話です。2023年には、ADAのデジタル・アクセシビリティ訴訟の77%が、年間売上$25 million未満の企業を標的としていました。ECは依然として、他を大きく引き離して最も訴訟の多いセクターです。そして重要なのは、一度訴えられたからといって、再度訴えられない保証はまったくないということです。近年のデジタル・アクセシビリティ訴訟のほぼ半数は、すでに少なくとも1件の請求を受けたことのある企業を標的としていました。

最も一般的なWCAG違反（とその見つけ方）

ほぼ95%のウェブサイトが基本的なアクセシビリティ基準に不合格であることを踏まえると、どのような具体的な違反が最も多いのかを知っておく価値があります。上位100万件のウェブサイトのホームページを監査する年次レポート「WebAIM Million」は、ほとんどのページに繰り返し現れる同じ少数の問題を一貫して特定しています。

  • 低い色コントラスト: 2025年の分析では、低コントラストのテキストはホームページの79.1%に影響し、1ページあたり平均ほぼ30件の事例が見つかりました。これは最も一般的な違反であると同時に、自動ツールで検出しやすい問題の1つでもあります。レベルAAを満たすには、テキストは背景に対して少なくとも4.5:1（大きなテキストの場合は3:1）のコントラスト比を持たなければなりません。
  • 代替テキストの欠如: altテキストの欠如は55.5%のページに影響しています。全盲またはロービジョンでスクリーンリーダーを使用しているユーザーにとって、altテキストのない画像は単に「見えない」存在です。支援技術はその画像を黙って飛ばすか、意味のないファイル名を読み上げるだけです。リンクされた画像にaltテキストがない場合、ナビゲーションは完全に破綻します。
  • フォームラベルの欠如: 関連付けられたラベルのないフォーム入力欄では、スクリーンリーダーユーザーはそのフィールドにどのような情報を入力すべきかを知ることができません。これは、チェックアウト、登録、問い合わせフォームなど、あらゆる場面で突破不可能な障壁となります。
  • 空のリンク: 説明テキストのないリンク（アイコンだけのリンクや、altテキストのない画像リンクなど）は、キーボードユーザーやスクリーンリーダーユーザーに対して、そのリンクがどこへ行くのかという文脈を一切提供しません。
  • 文書言語の欠如: HTMLでページの言語を宣言しないと、スクリーンリーダーが誤った言語の発音ルールでコンテンツを読み上げてしまい、テキストが理解不能になります。

このリストで注目すべき点は、これらが高度なエンジニアリングを必要とする特殊なケースではないということです。いずれも、マークアップとデザインに関する単純な決定事項です。それにもかかわらず、これらの問題がウェブの大部分で依然として見られるのは、技術的な限界ではなく、アクセシビリティが典型的なウェブ開発ワークフローにどのように（あるいは全く）組み込まれていないかという構造的なギャップを反映しているのです。

組織としてWCAG準拠に取り組む方法

現在のほとんどのウェブサイトの状態から、真のWCAG 2.2レベルAA適合に到達するには、体系的なアプローチが必要です。これは一度きりのプロジェクトではなく、継続的なプロセスです。なぜなら、コンテンツは変化し、フレームワークは更新され、サードパーティコンポーネントは入れ替わるからです。ここでは、その取り組みを効果的に構造化する方法を示します。

まずベースラインの監査から始める。何かを修正する前に、何が壊れているのかを把握する必要があります。自動スキャンツールは、色コントラストの問題、altテキストの欠如、フォームラベルの欠如など、問題の意味のあるサブセットを迅速かつ大規模に特定できます。しかし、自動ツールにはよく知られた限界があります。検出できるWCAGの問題はおよそ30〜40%に過ぎません。残りは手動テストが必要です。キーボードだけでサイトをナビゲートし、WindowsではNVDAやJAWS、macOSやiOSではVoiceOverなどの実際のスクリーンリーダーでテストし、理想的には障害のあるユーザーをテストプロセスに参加させる必要があります。

影響と頻度で優先順位を付ける。すべての問題が同じ重みを持つわけではありません。装飾用アイコンのaltテキストが欠けていることは、ユーザーがモーダルダイアログから抜け出せなくなるキーボードトラップや、スクリーンリーダーではまったく使えないログインフォームに比べれば、はるかに重要度が低い問題です。最初の修正スプリントでは、見た目の問題や影響の小さい項目に取り組む前に、チェックアウト、アカウント作成、検索、問い合わせといったコアなユーザージャーニーを妨げる障壁に焦点を当ててください。

アクセシビリティを開発ワークフローの「後付け」ではなく「組み込み」にする。最もコストのかかるアクセシビリティ対応は、ローンチ後の修正です。アクセシビリティチェックをデザインシステム、コンポーネントライブラリ、コードレビュー、CI/CDパイプラインに組み込むことで、問題を最も安く修正できる段階で発見できます。チーム内でアクセシビリティの明確な責任者を定め、デザイナー、開発者、コンテンツ編集者に対して役割別のトレーニングを提供しましょう。

アクセシビリティ声明を維持する。ウェブサイト上で明確かつ誠実なアクセシビリティ声明を公開し、どの標準を目標としているのか、ユーザーがどのように障壁を報告できるのか、報告にどのように対応するのかを説明することは、誠意を示すものであり、EU Web Accessibility Directive（EUウェブアクセシビリティ指令）など一部の法域では法的に義務付けられています。また、テストで見落とした問題を発見するためのフィードバックループも生み出します。

オーバーレイウィジェットは、コードレベルのアクセシビリティの代替ではなく補完として使う。Accsibleを含むアクセシビリティ・オーバーレイウィジェットやSDKは、テキストサイズ、コントラストモード、キーボードナビゲーションの強化など、ユーザーが制御できる設定を表面化させるための有用なツールになり得ます。しかし、データは明確です。基盤となるアクセシビリティ対応の代わりにウィジェットを導入しても、訴訟を防ぐことはできません。法的な保護は、ウィジェットが載っている土台ではなく、基盤となるコードがWCAG基準を満たしていることから生じます。オーバーレイは本質的な修正を補完するために使い、置き換えるために使ってはいけません。

これからの道のり：地平線上のWCAG 3.0

組織がまだWCAG 2.2の達成に取り組んでいる最中であっても、W3C Accessibility Guidelines Working Groupは、ウェブアクセシビリティガイダンスのより大きな再構成であるWCAG 3.0を策定中です。最初の公開ワーキングドラフトは2021年初頭に公開され、2025年末時点でもワーキングドラフトは大幅な開発が続いています。WCAG 3.0のいかなる部分もまだ公式な勧告ではなく、確定したリリース日も定められていません。

WCAG 3.0は、A/AA/AAAの適合モデルから大きく離れ、スコアリングベースのアプローチを導入し、ネイティブモバイルアプリケーションや新興技術を含む、より広範なデジタルコンテンツタイプを対象とすることが期待されています。現時点では、組織はWCAG 2.2レベルAAに集中すべきです。これは現在執行可能な標準であり、当面の間その地位は変わりません。今のうちに堅固なWCAG 2.2の基盤を築いた組織は、将来WCAG 3.0が勧告となったときに、はるかにスムーズに適応できるようになります。

重要なポイント

  • WCAG 2.2は、現在のグローバルなウェブアクセシビリティ標準であり、W3Cによって公開され、ISO/IEC 40500:2025として承認されています。WCAG 2.2を満たすコンテンツは自動的に2.1と2.0も満たします。常に最新バージョンを目標にしましょう。
  • レベルAAこそが重要なターゲットです。ADA、Section 508、EAA、EN 301 549、AODAなど、ほぼすべてのグローバルなアクセシビリティ法は、必要な適合レベルとしてWCAGレベルAAを参照しています。まずはそこに注力してください。
  • 最も一般的な違反は修正可能です。低い色コントラスト、altテキストの欠如、フォームラベルの欠如、空のリンクが、ウェブ全体のアクセシビリティエラーの大半を占めています。これらは比較的少ない労力で解決でき、効果は大きい問題です。
  • 自動テストは必要ですが、それだけでは不十分です。ツールが検出できるWCAGの問題は約30〜40%です。自動スキャンに加えて、キーボードテスト、スクリーンリーダーテスト、そして理想的には障害のある人々によるユーザーテストを組み合わせることで、全体像を把握できます。
  • アクセシビリティは一度きりのプロジェクトではなく、継続的なプロセスです。コンテンツは変化し、サードパーティコンポーネントは変わり、標準も進化します。アクセシビリティをデザイン、開発、コンテンツのワークフローに組み込み、苦情や訴訟の後に受動的に修正するのではなく、継続的に維持されるようにしましょう。