WCAG 2.2で何が変わったのか｜追加された達成基準を実務で読むWebアクセシビリティ入門
前回は、WCAG 2.2がどのような位置づけのガイドラインなのか、そしてなぜ今Webアクセシビリティに向き合う必要があるのかを整理いたしました。第2回では、いよいよWCAG 2.2で何が変わったのかを、実務の視点からやさしく見てまいります。規格の更新と聞くと、大きくルールが変わったように感じられるかもしれませんが、実際にはWCAG 2.2はWCAG 2.1を土台にしながら、現場でつまずきやすい部分をより具体的に補強したものです。そのため、「以前の理解がすべて無駄になる」というより、「これまでの取り組みを、より利用者に近い形へ整えていく」ためのアップデートとして捉えるのが自然です。
この記事でわかること
- WCAG 2.2がWCAG 2.1からどう変わったのか
- 追加された9つの達成基準の要点
- 削除された達成基準の考え方
- 実務で特に優先して見直したいポイント
- UUUウェブアクセシビリティサービスと相性のよい領域、そうでない領域
WCAG 2.2では、WCAG 2.1に対して9つの達成基準が追加され、1つの達成基準が廃止扱いになりました。基本構造そのものは変わっておらず、「知覚可能」「操作可能」「理解可能」「堅牢」という4原則の枠組みもそのままです。つまり、見出し構造、代替テキスト、キーボード操作、コントラスト、フォームのラベル付けといった従来から大切だった事項は引き続き重要です。そのうえで、今回の追加は、主にフォーカスの見えやすさ、ドラッグに頼らない操作、入力のしやすさ、認証時の負担軽減、タッチ操作のしやすさなど、より日常的なUIの使い勝手に踏み込んでいる点が特徴です。言い換えると、WCAG 2.2は「見えるかどうか」だけでなく、「迷わず操作できるか」「負担なく完了できるか」に、いっそう目を向けた版だと理解するとわかりやすいでしょう。
まず大きな前提として押さえておきたいのは、WCAG 2.2が新しく追加した達成基準の多くは、いわゆる“高度な未来の話”ではなく、今の企業サイトやサービスサイト、採用サイト、自治体サイト、EC、会員登録画面などで現実に起きている課題に直結していることです。たとえば、ボタンを押したときに固定ヘッダーがフォーカス位置を隠してしまう、スマートフォンで小さなボタンが押しにくい、ドラッグ操作を前提にしたUIが使いづらい、ログイン時に毎回複雑な認証を求められて負担が大きい、といった場面は、多くの読者にとっても心当たりがあるのではないでしょうか。WCAG 2.2は、そのような“よくある不便”を見逃さず、より具体的に改善へつなげるための基準を示しています。
WCAG 2.2で追加された9つの達成基準
ここからは、追加された9つの達成基準を実務目線で整理してまいります。すべてを一度に暗記する必要はありません。まずは「どんな困りごとに対応する基準なのか」をつかむことが大切です。
2.4.11 Focus Not Obscured (Minimum)
この達成基準は、キーボード操作などで移動したフォーカスが、完全に隠れてしまわないことを求めるものです。たとえば、画面上部に固定ヘッダーや追従メニューがあり、Tabキーで移動するとフォーカスされたボタンやリンクがその下に潜って見えなくなることがあります。利用者は今どこにいるのかわからず、操作を続けるのが難しくなります。実務では、固定ヘッダーの高さを考慮したスクロール制御や、フォーカス時の見え方の確認が重要になります。とくに、フォーム、モーダル、アコーディオン、ナビゲーションなど、キーボード操作が多い場所では見落としやすいポイントです。
2.4.12 Focus Not Obscured (Enhanced)
こちらは、より強い条件として、フォーカス対象が他のコンテンツによって隠されないことを求めています。2.4.11が「最低限、完全には隠れない」ことを求めるのに対し、2.4.12では、見えることそのものをよりしっかり担保します。実務上は、特にAAまでの対応を基本とするケースが多いため、まずは2.4.11を優先して押さえることが現実的ですが、設計段階から「フォーカスが重なり物に隠れないUI」にしておくと、結果として利用体験全体の質も高まりやすくなります。
2.4.13 Focus Appearance
この達成基準は、フォーカスインジケーター、つまり「今どこにいるか」を示す視覚的な表示が、十分に見えることを求めています。最近のWeb制作では、デザイン上の理由でアウトラインを消してしまう例がまだ見られますが、それではキーボード利用者が現在位置を把握しにくくなります。しかも、薄い線や背景に埋もれる色では、表示されていても実質的には見えないことがあります。実務では、フォーカス時の枠線、背景変化、下線、太さ、コントラストを丁寧に設計することが重要です。デザインとアクセシビリティは対立するものではなく、見えるフォーカスは安心感や操作のしやすさにもつながります。
2.5.7 Dragging Movements
この達成基準は、ドラッグ操作だけを前提にしないことを求めています。たとえば、スライダーをドラッグしなければ値が変更できない、地図上のピンをドラッグしないと場所を選べない、並び替えがドラッグ&ドロップにしか対応していない、といったUIは、一部の利用者にとって大きな負担になります。手指の細かな操作が難しい方、支援技術を使っている方、キーボード主体で操作する方にとっては、そもそも完了できない場合もあります。実務では、ボタンによる代替操作、数値入力、選択肢方式、キーボード操作のサポートなどを用意することが考えられます。ドラッグは便利な操作ですが、それだけに頼らないことが大切です。
2.5.8 Target Size (Minimum)
この達成基準は、タッチやポインタで操作する対象の大きさに最低限の配慮を求めるものです。スマートフォンで小さなリンクやアイコンが密集していると、押し間違いが起こりやすくなります。これは障害の有無にかかわらず、多くの利用者が経験する不便です。とくに高齢の方、片手操作中の方、移動中に操作している方には影響が大きくなります。実務では、ボタンやリンクの表示サイズだけでなく、実際にタップ可能な領域が確保されているかを確認する必要があります。小さな閉じるボタン、ページャーの数字、カードUIの一部だけがクリック対象になっている設計などは、見直し候補になりやすいです。
3.2.6 Consistent Help
この達成基準は、複数ページにまたがって提供されるヘルプ機能の位置や見つけやすさに一貫性を持たせることを求めています。たとえば、問い合わせ先、チャットサポート、FAQへの導線、ヘルプボタンなどが、ページごとに場所が変わると、利用者は必要な支援にたどり着きにくくなります。特に、手続きや申し込み、会員登録のように不安が生まれやすい場面では、ヘルプ導線の一貫性が利用継続に大きく影響します。実務では、ページテンプレート単位でヘルプ導線を統一する、主要導線を同じ場所に配置する、文言を揃える、といった基本が有効です。地味に見えるものの、ユーザー体験の安定感を支える大切な項目です。
3.3.7 Redundant Entry
この達成基準は、同じプロセスの中で一度入力した情報を、原則として繰り返し入力させないことを求めています。たとえば、申し込みフォームの前半で入力した氏名や住所を、確認や別ステップで再度すべて打ち直させるような設計は、負担が大きく、入力ミスも増えやすくなります。認知面や記憶面に負担がかかるだけでなく、単純に時間もかかります。実務では、前ステップの入力内容を引き継ぐ、自動補完を適切に使う、確認画面では修正しやすくするなどの工夫が考えられます。ユーザーに余計な作業をさせないという意味で、アクセシビリティとUXが非常に重なりやすい達成基準です。
3.3.8 Accessible Authentication (Minimum)
この達成基準は、認証の場面で、利用者に過度な認知機能テストを求めないことを求めています。たとえば、複雑な文字列を記憶して入力させる、画像の中から特定のものを選ばせる、パズルのようなCAPTCHAを解かせるなどの方法は、一部の利用者にとって大きな壁になります。もちろんセキュリティは大切ですが、セキュリティ対策が利用不能につながってしまっては本末転倒です。実務では、パスワードマネージャーの利用を妨げない、コピー&ペーストを不必要に禁止しない、代替手段を用意する、ワンタイムリンクや多要素認証の設計を見直すなどが検討対象になります。ログインや会員登録を扱うサイトでは、とても重要な観点です。
3.3.9 Accessible Authentication (Enhanced)
こちらは、認証に関するさらに強い条件です。利用者が認知的な負担をできるだけ避けながら認証できることを、より高い水準で求めています。AAAレベルのため、すべての現場で必須となるわけではありませんが、認証や本人確認が中心となるサービスでは、設計の方向性として十分参考になります。利用者の安全と使いやすさの両立を考えるうえで、単なる達成基準の番号以上に大切なテーマと言えるでしょう。
廃止扱いになった4.1.1 Parsingはどう考えればよいか
WCAG 2.2では、4.1.1 Parsingが廃止扱いとなりました。これだけを見ると、「HTMLの正しさはもう気にしなくてよいのかしら」と思われるかもしれませんが、そうではありません。Parsingが外れた背景には、現在のブラウザや支援技術の進化があり、以前ほど形式的な文法チェックだけでアクセシビリティを判断する意味が大きくなくなったという事情があります。しかし、HTMLの構造が崩れてよいという意味ではありません。見出し、ラベル、ボタン、リンク、ランドマーク、フォーム要素などが適切に実装されていることは、依然として非常に重要です。つまり、「構文のための構文」ではなく、「利用者に正しく伝わる実装」であるかどうかを、より実践的に見る方向へ比重が移ったと考えるとよいでしょう。
実務で優先して見直したいポイント
ここまで見ると、WCAG 2.2は新しい項目がいくつも増えていて大変そうに感じるかもしれません。けれど、現場での優先順位はある程度整理できます。まず取り組みやすく、かつ影響が大きいのは、フォーカス関連、タップ対象サイズ、フォームや認証の設計です。これらは、既存サイトでも比較的問題が見つけやすく、改善の効果も利用者に伝わりやすい領域です。たとえば、キーボードで主要導線を操作してみる、スマートフォン実機でボタンの押しやすさを試す、ログインや問い合わせフォームで無駄な再入力がないかを見る、といった確認だけでも、多くの課題が浮かび上がります。
具体例として、採用エントリーフォームを考えてみましょう。氏名、住所、電話番号、メールアドレスを入力したあと、確認ページで修正がしにくい、戻ると入力内容が消える、必須項目が色だけで示されている、送信ボタンの位置にフォーカスが当たっても固定ヘッダーに隠れる、スマートフォンではチェックボックスが小さく押しづらい。このような状態であれば、WCAG 2.2の追加項目がちょうど改善の道しるべになります。規格は抽象的に見えても、実際にはこのような具体的な不便を減らすためのものなのです。
UUUウェブアクセシビリティサービスとの親和性はどこにあるのか
ここで、連載テーマでもあるUUUウェブアクセシビリティサービスとの親和性にも触れておきます。UUUのように、文字サイズ変更、コントラスト調整、行間や文字間隔の調整、アニメーション停止、音声読み上げ、翻訳、ふりがな表示といった閲覧補助機能を提供するサービスは、利用者が自分に合った閲覧環境へ近づけるという意味で、アクセシビリティの入口として相性がよいです。特に、今すぐ全面改修が難しい組織にとっては、利用者配慮を可視化しやすい点も魅力でしょう。
一方で、今回ご紹介した追加達成基準の多くは、ツールの導入だけでは十分に満たせません。たとえば、フォーカスが固定ヘッダーに隠れる問題はページ実装の調整が必要ですし、ドラッグ操作しかできないUIには代替操作の設計が必要です。ターゲットサイズの問題も、実際のボタンやリンクの設計を変えなければ解決しません。認証のしやすさや再入力の削減も、フォームやシステム設計の見直しが前提になります。つまり、UUUのようなサービスは閲覧支援の面で親和性が高い一方、WCAG 2.2で追加された実装・操作面の要求については、コンテンツやUIそのものの改善が欠かせません。この違いを理解しておくと、ツール活用と本質改善を無理なく両立しやすくなります。
第2回のまとめ
WCAG 2.2は、WCAG 2.1を大きく塗り替えるものではなく、現代のWeb利用環境に合わせて、より実務的な使いやすさを補強したガイドラインです。追加された9つの達成基準は、フォーカスの見えやすさ、ドラッグに頼らない操作、タップしやすさ、ヘルプ導線の一貫性、再入力の削減、認証時の負担軽減といった、実際の利用体験に深く関わるテーマばかりでした。つまり、今回のアップデートは、アクセシビリティを“特別な配慮”ではなく“迷わず使えるUIの基本”として捉え直すきっかけにもなります。
実務では、まず既存サイトの主要導線を見渡し、キーボード操作、スマートフォン操作、フォーム入力、ログインや認証といった重要場面から確認していくのがおすすめです。そして、UUUウェブアクセシビリティサービスのような支援策は、閲覧補助の面で価値がある一方、WCAG 2.2の新しい要求の多くは、元の設計や実装を丁寧に見直すことで初めて応えられることも、忘れずに押さえておきたいところです。次回は、フォームはなぜ使いにくくなるのかをテーマに、入力支援とエラー設計の基本を、さらに具体的な画面イメージとともに整理してまいります。