WCAG 2.2 と WCAG 2.1 の違い：新しい点と更新が必要な点

WebAIM の 2024 年のアクセシビリティ分析によると、ホームページの 96% 以上が依然として基本的な WCAG 要件を満たしていません — しかも、それはすでに 5 年前の基準に対しての話です。2023 年 10 月 5 日、W3C は WCAG 2.2 を公式なウェブ標準として公開し、9 つの新しい達成基準を追加し、時代遅れとなった 1 つの基準を廃止することでハードルを引き上げました。もしあなたがウェブサイトを運営している、デジタルプロダクトを構築している、あるいはコンプライアンスを管轄しているのであれば、このアップデートは無期限に先送りできるものではありません。EU、UK、そして増えつつある米国の州の規制は、すでに WCAG 2.2 をベンチマークとして参照する方向に動いています。

簡単な歴史: WCAG 2.1 から WCAG 2.2 へ

Web Content Accessibility Guidelines は、2008 年 12 月に WCAG 2.0 が公開されて以来、着実に進化してきました。WCAG 2.1 は 2018 年 6 月に登場し、特にモバイルユーザーやロービジョン、認知障害のある人々に焦点を当てた 17 の新しい達成基準を追加しました。5 年間にわたり、ADA、Section 508、EU Web Accessibility Directive のような法律における事実上のコンプライアンス基準として機能してきました。

WCAG 2.2 は、まさに 2.1 が終わったところから引き継いでいます。W3C は、3 つの主要なグループ — 認知または学習障害のあるユーザー、ロービジョンのユーザー、モバイルデバイスを利用する障害のあるユーザー — に対するアクセシビリティガイダンスを継続的に改善するという明確な目的を掲げてこれを開始しました。この系譜は重要です。なぜなら、このアップデートが革命的というよりは進化的なものであることを意味するからです — とはいえ、あなたの側での対応が必要になるほどには十分に意味のある変更です。

構造的に最も重要なポイントの 1 つは、WCAG 2.2 が WCAG 2.1 と完全な後方互換性を持っているということです。WCAG 2.2 に準拠するということは、自動的に WCAG 2.1 および WCAG 2.0 にも準拠していることを意味します。もしあなたの組織が現在 WCAG 2.1 AA に準拠しているのであれば、2.2 で新たに導入された基準に対応するだけでよく、ゼロからやり直す必要はありません。W3C も、WCAG 2.0 と 2.1 は依然として有効な勧告であるものの、アクセシビリティ対応の将来の有効性を最大化するために、組織は WCAG 2.2 を使用すべきだと助言しています。

また、WCAG 2.2 は WCAG 2.x ファミリーの最後のドットリリースになると広く予想されています。次のメジャーバージョンである WCAG 3.0 は、アクセシビリティガイドラインの構造そのものを一から見直す、まったく別物です。つまり WCAG 2.2 は、2008 年から続く系譜の決定版であり、今まさに正しく対応すべきバージョンだということです。

数字で見る: 実際に何が変わったのか

変更の範囲について正確に見ていきましょう。WCAG 2.1 には、3 つの適合レベル（A、AA、AAA）にまたがって 78 の達成基準がありました。WCAG 2.2 では 9 つの新しい達成基準が追加される一方で、1 つ — 達成基準 4.1.1 Parsing — が削除され、合計 86 の有効な基準となりました。追加された 9 つのうち、2 つがレベル A、4 つがレベル AA、3 つがレベル AAA です。

多くの法律や規制で参照されているレベル AA 準拠を目標とする大多数の組織にとって、実務上の影響は、新たに 6 つの基準を実装する必要があるという点です。3 つのレベル AAA の追加はベストプラクティスと見なされており、政府や医療の文脈では推奨されることが多いものの、現時点で多くの法域において厳格な法的要件ではありません。

新しい基準は主に、実際のアクセシビリティ監査で既存の標準では十分にカバーされていないと繰り返し指摘されてきた 4 つの問題領域に対応しています。それは、キーボードフォーカスの可視性、タッチおよびポインター操作、認知アクセシビリティ、そして認証の障壁です。これらは理論上の懸念ではありません。ログイン、フォームの入力、固定ヘッダーのあるページのナビゲーションといった日常的なタスクを、障害のある人々が完了できなくなる原因となる種類の障壁です。

9 つの新しい達成基準の解説

ここでは、それぞれの新しい基準の内訳と、その要件、および実務上なぜ重要なのかを説明します。基準は適合レベルごとに示しているので、是正作業の優先順位付けに役立てることができます。

レベル A（最小 — すべてに必須）

• 2.4.11 Focus Not Obscured (Minimum): UI コンポーネントがキーボードフォーカスを受け取ったとき、そのコンポーネントが作成者によるコンテンツによって完全に隠されてはなりません。ここで最も一般的な原因となるのは、固定ヘッダー、フローティングのクッキーバナー、ページ上に重なって表示されるライブチャットウィジェットなどです。ユーザーが Tab キーを押してフォーカスがボタンに移動した際、そのボタンが固定ナビゲーションバーに完全に覆われてしまう場合、この基準に違反します。なお、一部が隠れることはレベル A では許容されます — 要素が 100% 隠れてしまってはならない、ということです。
• 2.5.7 Dragging Movements: ドラッグ動作を必要とするあらゆる機能 — たとえばドラッグ＆ドロップによるファイルアップロード、並べ替え可能なリスト項目、スライダーコントロールなど — は、ドラッグを伴わない単一のポインター操作（クリックやタップなど）でも操作できなければなりません。これは、制御されたドラッグジェスチャーを安定して実行できない運動障害のあるユーザーにとって極めて重要です。この要件は作成者が作ったコンテンツに適用され、ブラウザのネイティブな挙動は対象外です。

レベル AA（標準的な準拠に必須）

• 2.4.12 Focus Not Obscured (Enhanced): 2.4.11 のより厳格なバージョンです。レベル AA では、要素がキーボードフォーカスを受け取ったとき、フォーカスインジケーターの一部も作成者によるコンテンツによって隠されてはなりません。これによりレベル A バージョンの抜け穴が塞がれ、フォーカスされた要素は一部ではなく完全に見えていなければならないことが求められます。
• 2.5.8 Target Size (Minimum): インタラクティブ要素のクリックまたはタップ可能な領域は、特定の例外（インラインテキストリンク、ユーザーエージェントが制御する要素、近くに同等の 24×24 ターゲットが存在する場合）を除き、少なくとも 24×24 CSS ピクセルでなければなりません。これは、44×44 ピクセルのターゲットサイズが AAA レベルでのみ推奨されていた WCAG 2.1 からの大きな変更です。今や最低ラインが AA レベルで強制可能になりました。24×24px はあくまで下限であり、AAA の基準（2.5.5）では依然として 44×44px が推奨されており、タッチフレンドリーなデザインのゴールドスタンダードであることに変わりはありません。
• 3.2.6 Consistent Help: ウェブサイトが何らかのヘルプ手段 — 人による連絡先情報、セルフヘルプツール、自動チャット、問い合わせフォームなど — を提供しており、それらが複数のページに登場する場合、それらは各ページで同じ相対的な位置に表示されなければなりません。特に認知障害のあるユーザーなど、ヘルプを必要とするユーザーは、探し回ることなく常に同じ場所でヘルプを見つけられるべきです。
• 3.3.7 Redundant Entry: ユーザーが同じプロセスの前のステップで既に入力した情報については、再度入力しなくても済むように、自動入力されるか、選択できるようになっていなければなりません。たとえば、複数ステップのチェックアウトフローで請求先住所を入力させた後、配送先住所を再度尋ねる場合 — ユーザーには、すでに入力した情報をコピーできる手段が提供されるべきです。情報の再入力がセキュリティ上不可欠な場合（パスワードの確認など）や、以前入力したデータがもはや有効でない場合には例外が認められます。
• 3.3.8 Accessible Authentication (Minimum): パズルの解決、パスワードの記憶、画像 CAPTCHA の文字の書き写しといった認知機能テストは、認証の唯一の手段として要求してはなりません。代替手段が利用可能であるか、あるいはユーザーを支援する仕組み（パスワードマネージャーの利用を許可する、パスワードフィールドへのコピー＆ペーストを許可するなど）が提供されなければなりません。この基準は CAPTCHA を全面的に禁止するものではありませんが、それを完了できないユーザーにとって唯一の選択肢であってはならない、ということを求めています。

レベル AAA（強化 — 多くの場合は推奨だが必須ではない）

• 2.4.13 Focus Appearance: キーボードフォーカスインジケーターが表示されている場合、そのサイズとコントラストについて特定の最小要件を満たさなければなりません。フォーカス領域は、要素の周囲に 2 CSS ピクセルの太さの輪郭を描いた場合と同等以上の大きさである必要があり、フォーカスされた状態とされていない状態の間で少なくとも 3:1 のコントラスト比が必要です。この基準は当初レベル AA に配置される予定でしたが、その複雑さから AAA に移されました。つまり、AA のみの準拠においては、フォーカスインジケーターの最小サイズは依然として規範的には定義されておらず、「可視であること」のみが求められているということです。
• 2.5.9 Dragging Movements (Enhanced): ちょっと待ってください — このリリースには 2.5.9 は存在しません。AAA レベルのドラッグ操作の強化は、以下の 3.3.9 に含まれています。
• 3.3.9 Accessible Authentication (Enhanced): 3.3.8 のより厳格なバージョンです。レベル AAA では、オブジェクト認識や個人コンテンツテスト（「すべての信号機をクリックしてください」や「あなたのアカウントから写真を選択してください」といったもの）も禁止され、AA レベルで認められていた例外だけが対象となるわけではありません。例外は 4 つではなく 2 つだけになります。

削除されたもの: 4.1.1 Parsing

WCAG 2.2 では、WCAG 2.0 以来存在していた 1 つの達成基準、4.1.1 Parsing が削除されました。この基準はもともと、HTML が適切に構造化されていること — 開始タグと終了タグが揃っていること、入れ子が正しいこと、重複した属性がないこと — を求めていました。その意図は、ブラウザや支援技術がマークアップを確実に解析し、ユーザーに正しくコンテンツを提示できるようにすることでした。

この削除は特に物議を醸しているわけではなく、技術的な状況の実際の変化を反映したものです。2008 年以降、ブラウザは不正な HTML を標準化されたエラー訂正アルゴリズムに従ってうまく処理できるようになり、非常に高い能力を持つようになりました。スクリーンリーダーのような支援技術も、今では生の HTML ソースコードではなくブラウザの Document Object Model (DOM) に依存しています。W3C は、この基準が現代の環境ではもはや意味のあるアクセシビリティ上の利益を提供していないと結論づけました。かつて 4.1.1 によって検出されていたアクセシビリティ問題は、今でも 1.3.1（情報及び関係）や 4.1.2（名前、役割、値）といった、より具体的な基準によってカバーされています。

あなたのチームにとっての実務的な意味合いとしては、もし自動テストツールが 4.1.1 Parsing の失敗を検出していたとしても、それらはもはや WCAG 2.2 の問題ではないということです。バージョンアップだけで報告される失敗が減少する可能性がありますが、それは何かを修正したからではありません。とはいえ、有効でよく構造化された HTML を書くことは依然として強力なベストプラクティスであり、それ自体がコンプライアンス要件ではなくなった、というだけの話です。

規制および法的な影響

新しい基準を理解することと、それが法的リスクにとって何を意味するのかを理解することは別問題です。結論としては、WCAG 2.2 は複数の法域で「事実上の法律」になりつつあり、そのタイムラインは多くの組織が認識しているよりも速く進んでいる、ということです。

英国では、Public Sector Bodies Accessibility Regulations の下で、公的機関はすでに WCAG 2.2 レベル AA を満たすことが求められています。欧州連合では、European Accessibility Act を支える技術標準である EN 301 549 が、WCAG 2.2 をベースラインとして採用するプロセスにあります。EAA 自体は、EU で製品やサービスを提供するほとんどの民間企業に対し、2025 年 6 月の施行期限を定めています。米国のいくつかの州（Colorado を含む）も、州のアクセシビリティ法を WCAG 2.1 から WCAG 2.2 に更新する意向を示しています。

米国では、ADA Title II は現在、州および地方自治体のウェブサイトに対する技術標準として WCAG 2.1 AA を参照しています。しかし、米国の裁判所はアクセシビリティ訴訟において WCAG 2.2 を引用するケースが増えており、その方向性は明らかです。正式な連邦レベルの義務化を待ってから対応するというコンプライアンス戦略は、特に e コマース、金融サービス、医療機関など、アクセシビリティ訴訟の標的になりやすい組織にとって、法的リスクが高まりつつあります。

あなたの組織がまだ WCAG 2.2 に準拠する法的義務を負っていないとしても、新しい達成基準をできるだけ早く満たすことで、変化する規制を先取りできるだけでなく、何よりも、今日あなたのユーザーが直面している実際のアクセシビリティ障壁を先回りして解消することができます。

サイトを監査・更新する方法

すでに WCAG 2.1 AA に準拠しているのであれば、WCAG 2.2 へのアップグレードパスは十分に管理可能です。ここでは、そのための実践的なフレームワークを示します。

まずは 6 つの新しいレベル AA 基準に絞った監査から始めましょう。これらは多くの組織にとって法的な重みを持つ基準です。特に 2.4.11 と 2.4.12（フォーカスの隠蔽）、2.5.8（ターゲットサイズ）、3.2.6（一貫したヘルプ）、3.3.7（重複入力）、3.3.8（アクセシブルな認証）に注目してください。熟練したアクセシビリティエンジニアであれば、中程度の複雑さのサイトであれば、これらの基準を数時間で手動監査できることが一般的です。

まずは sticky / 固定位置の要素を監査しましょう。フォーカスの隠蔽に関する基準（2.4.11 と 2.4.12）は、ウェブ上で最も一般的な UI パターン — 固定ヘッダー、フローティングアクションボタン、クッキー同意バー、チャットウィジェットなど — によって違反されがちです。サイト全体を Tab キーだけで操作し、フォーカスされた要素が固定レイヤーの下に隠れてしまう場面がないか確認してください。CSS による修正は通常、次のように比較的簡単です。

/* Prevent sticky header from covering focused elements */
:focus {
  scroll-margin-top: 80px; /* match your sticky header height */
}

すべてのインタラクティブ要素のタップターゲットサイズを監査しましょう。これは、コンプライアンスとユーザー体験の両面で、しばしば手早く成果を上げられる部分です。ボタン、リンク、フォームコントロール、アイコンはすべて、最低 24×24 CSS ピクセルが必要です。多くのデザインシステムはすでにこの閾値を上回っていますが、小さなアイコンボタン — 閉じるアイコン、ソーシャルシェアボタン、インラインのアクションリンクなど — は違反しがちです。コンポーネントを確認し、必要に応じてパディングを追加したり、サイズを調整したりしてください。

認証フローを慎重に見直しましょう。SC 3.3.8（Accessible Authentication）は実効性の高い基準です。バイパスできない、あるいは代替手段で解決できない CAPTCHA を使用している場合、非準拠である可能性が高いでしょう。ログイン、登録、二要素認証のフローにおいて、パスワードマネージャーによる自動入力が許可されているか、コピー＆ペーストが可能か、代替の認証手段（マジックリンクやワンタイムコードなど）が提供されているか、あるいは認知的なチャレンジを完了できないユーザーに対する何らかの配慮があるかどうかを評価してください。

複数ステップのフォームで重複入力がないか監査しましょう。チェックアウト、オンボーディングフロー、申請など、複数のステップにまたがるプロセスを洗い出し、ユーザーに以前提供した情報を再度求めている箇所をすべて特定してください。該当箇所には自動入力ロジックや「上と同じ」トグルを追加しましょう。これは通常、複雑なアーキテクチャの大幅な見直しではなく、バックエンドやフォーム状態管理の変更で対応できます。

ヘルプ手段が一貫した位置にあることを確認しましょう。チャットウィジェット、ヘルプリンク、電話番号などがフッターやサイドバーに複数ページで表示されている場合、その相対的な位置が変動していないか確認してください。これは多くの場合、ページごとの問題ではなくテンプレートやレイアウトの問題です — コンポーネントライブラリや CMS テンプレートで修正すれば、全ページに反映されます。

自動ツールは初期調査に使いつつ、それだけで終わらせないようにしましょう。自動スキャナーは WCAG 2.2 の問題のおよそ 40% を検出できます — ターゲットサイズの違反や明らかなフォーカス管理の問題を見つけるのには有用ですが、CAPTCHA が唯一の認証手段かどうか、ヘルプ手段が一貫した位置にあるかどうかを評価することはできません。キーボードのみのナビゲーションやスクリーンリーダーによるテストを含む手動テストは依然として不可欠です。障害のある実際のユーザーによるテストは、自動ツールでは決して見つからない問題を発見してくれます。

WCAG 2.2 とオーバーレイウィジェット: 知っておくべきこと

アクセシビリティオーバーレイウィジェットや SDK — Accsible のようなツール — は、特にフォントサイズの拡大、コントラストの変更、キーボードナビゲーションの強化といったリアルタイムの調整を必要とするユーザーに対して、特定の種類のアクセシビリティ問題の検出と是正に有意義な支援を提供できます。WCAG 2.2 準拠という文脈で、オーバーレイができることとできないことを冷静に理解しておく価値があります。

オーバーレイは、フォーカスの可視性に関する特定の問題に対処したり、代替のナビゲーションモードを提供したり、デザインレベルの不足を補うユーザー側のカスタマイズを提供したりすることができます。長期的な是正作業が進行中の間に、ユーザー体験を迅速に改善する必要があるチームにとって、有用なアクセシビリティスタックの一層となり得ます。しかし、オーバーレイは基盤となるコードを修正する代わりにはなりません。新しい WCAG 2.2 の基準 — 特に認証（3.3.8）、重複入力（3.3.7）、ドラッグ操作（2.5.7）に関するもの — は、アプリケーションの構築方法そのものに対する構造的な変更を必要としており、見た目のレイヤーだけで解決できるものではありません。

最も効果的なアプローチは、ユーザー向けの柔軟性を高める適切に実装されたオーバーレイと、新しい 2.2 の基準に対応するコードレベルの修正を組み合わせることです。オーバーレイ SDK を「力を増幅するもの」と考えてください。それはあなたの対応範囲を広げ、より多くのユーザーの体験を改善し、ギャップを埋めてくれます — しかし、その土台は依然として堅牢でなければなりません。

重要なポイントのまとめ

• WCAG 2.2 は 9 つの新しい達成基準を追加し、1 つの時代遅れのルール（4.1.1 Parsing）を削除しました。2.1 と完全な後方互換性があるため、これまでのコンプライアンス対応が無駄になることはありません — 新しい部分を上乗せするだけで済みます。
• レベル AA 準拠のためには、6 つの特定の新基準に注力しましょう: Focus Not Obscured（2.4.11 と 2.4.12）、Target Size Minimum（2.5.8）、Consistent Help（3.2.6）、Redundant Entry（3.3.7）、Accessible Authentication（3.3.8）。これらが、多くの組織にとって法的に重要な基準です。
• 規制による採用は加速しています。英国の公共部門はすでに WCAG 2.2 を施行しており、EU は European Accessibility Act の下でこれへの移行を進めています。米国の裁判所もこれを引用するケースが増えています。自分の法域で正式な義務化が行われるのを待ってから動くべきではありません。
• 自動ツールが検出できるのは WCAG 2.2 の問題のおよそ 40% に過ぎません — 真の準拠を達成するには、手動テスト、キーボードのみのナビゲーション確認、実ユーザーによるテストが不可欠であり、特に認証や認知アクセシビリティに関する新基準において重要です。
• 最も一般的な「すぐに取り組める改善」は、フォーカスされた要素を隠してしまう固定ヘッダーの修正、小さなタップターゲットの拡大、そしてログイン／認証フローの監査（CAPTCHA への依存の有無）です。これらの変更は、多くの場合、工数が比較的少なく効果が大きいため、WCAG 2.2 是正スプリントの良い出発点となります。