2023年10月5日付けでWCAG (Web Content Accessibility Guidelines) の最新バージョンである、「Web Content Accessibility Guidelines (WCAG) 2.2」がW3Cより正式に勧告されました。2018年6月に「WCAG 2.1」が勧告されて以来のアップデートになります。

今回の改定による、各適合レベルごとの達成基準数の変動（WCAG 2.1 → WCAG 2.2）は下記の通りです。トータルでは9つの達成基準が新たに追加されています。

  • 適合レベル A： 30 → 31（+2 / 同時に達成基準 4.1.1が廃止されたので ±1）
  • 適合レベル AA： 20 → 24（+4）
  • 適合レベル AAA： 28 → 31（+3）

勧告から少し時間が空いてしまいましたが、過去にWCAG 2.1が勧告された際にも同様のコラムを書かせていただいたこともあり、今回、WCAG 2.2に関しても、新たに追加された達成基準について、簡単にではありますが解説をしてみたいと思います。

WCAG 2.2で追加された達成基準

まずはWCAG 2.2で新たに追加された達成基準を確認してみましょう（達成基準の日本語訳は弊社によるもの）。前述の通り、9つの達成基準が追加されています。

追加された各達成基準に関する解説

簡単にですが、各項目をWCAG 2.1の原文とあわせて解説していきます。

2.4.11 Focus Not Obscured (Minimum) (AA) - 隠されないフォーカス（最低限）

原文：
When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.

この達成基準の主な目的は、キーボードのユーザーがウェブサイトを操作する際に、現在フォーカスしている要素が見えるようにし、それによってユーザーが容易に操作できるようにすることです。フォーカスが「隠されない」ことを保証することで、すべてのユーザーがウェブサイトをより簡単に使用できるようになります。

具体的にはフォーカスが可視化されていること、さらに、その可視化されたフォーカスが、他のコンテンツ（例えば画面の上部や下部に固定されることで他の要素に覆い被さるように表示されるヘッダやフッタのようなものや、ポップアップ、オーバーレイなど）によって隠されていないことが求められますが、最低限、フォーカスの一部でも表示されていればこの達成基準は満たすことができます。

2.4.12 Focus Not Obscured (Enhanced) (AAA) - 隠されないフォーカス（高度）

原文：
When a user interface component receives keyboard focus, no part of the component is hidden by author-created content.

前述した「達成基準 2.4.11 隠されないフォーカス（最低限）」をより強化した達成基準です。可視化されたフォーカスが、他のコンテンツによって、一部分すら隠されることなく、完全に表示されることが求められます。

2.4.13 Focus Appearance (AAA) - フォーカスの外観

原文：
When the keyboard focus indicator is visible, an area of the focus indicator meets all the following:

  • is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component or sub-component, and
  • has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states.

Exceptions:

  • The focus indicator is determined by the user agent and cannot be adjusted by the author, or
  • The focus indicator and the indicator's background color are not modified by the author.

この達成基準の主な目的は、キーボードのユーザーがウェブサイトを操作する際に、現在フォーカスしている要素を視覚的に確認しやすくし、それによってユーザーが容易に操作できるようにすることです。具体的には、フォーカスインジケータに対して、下記の要件が求められています。

  • フォーカスインジケータは、フォーカスされた要素の周りに最低でも2CSSピクセルのサイズで表示される
  • フォーカスインジケータは、少なくとも3:1のコントラスト比を持つ

この達成基準を満たそうとした場合、一般的なブラウザソフトが標準で提供するフォーカスインジケータでは不十分になる場合があります。ウェブサイト制作者は、事前にフォーカスインジケータについてもデザインや実装ルールを定めておく必要があるでしょう。

2.5.7 Dragging Movements (AA) - ドラッグ動作

原文：
All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author.

ドラッグ操作を必要とする機能は、ドラッグ操作が不可欠な場合、あるいはその機能がユーザーエージェントによって決定されており、ウェブサイト制作者側では変更できない場合を除いて、シングルポインターを使用してドラッグなしで操作できる必要があるとする達成基準です。

この達成基準の目的は、特定の操作（マウスによるドラッグ操作）に依存しない、別の操作方法を提供することで、ユーザーがウェブサイトを操作できなくなることを防ぎます。

2.5.8 Target Size (Minimum) (AA) - ターゲットサイズ（最低限）

原文：
The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where:

  • Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target;
  • Equivalent: The function can be achieved through a different control on the same page that meets this criterion;
  • Inline: The target is in a sentence or its size is otherwise constrained by the line-height of non-target text;
  • User agent control: The size of the target is determined by the user agent and is not modified by the author;
  • Essential: A particular presentation of the target is essential or is legally required for the information being conveyed.

ポインタ入力のターゲットとなる要素のサイズは、例外を除き、少なくとも24×24 CSSピクセル以上であることを求める達成基準です。ポインタ入力のターゲットとなる要素とは、例えばボタンや入力欄、チェックボックスといった、ユーザーがマウスポインタで操作する要素のことです。

ただし、その要素自体は、最低サイズを満たさない場合でも、下記に該当する場合は例外が認められます。

  • 他のターゲットとなる要素との間隔が確保されている場合（具体的には「直径 24 CSSピクセルの円が、それぞれのターゲット要素の中心点を中心として描かれているとした場合、その円が別のターゲットやサイズ不足の別のターゲットの円と交差しないように配置されている）
  • 同等の機能がこの達成基準を満たす、同じページ上の別の入力コントロールで実現できている場合
  • ターゲットとなる要素が本文内にあるテキストリンクの場合、あるいは、そのサイズがターゲット要素以外のテキストの、行の高さによって制約されている場合
  • ターゲットとなる要素のサイズがユーザーエージェントによって決定され、ウェブサイト制作者によって変更できない場合
  • 伝達される情報にとって、ターゲットとなる要素には特定の表示が必須であったり、法的に要求されている場合（要するにそのサイズであることが必須だという場合）

3.2.6 Consistent Help (A) - 一貫したヘルプ （A）

原文：
If a Web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple Web pages within a set of Web pages, they occur in the same order relative to other page content, unless a change is initiated by the user:

  • Human contact details;
  • Human contact mechanism;
  • Self-help option;
  • A fully automated contact mechanism.

ウェブサイト上で下記のようなヘルプ機能が提供される場合は、同一ウェブサイト上のどのページにおいても、一貫した表示（例えば表示する場所やラベル、見た目などを統一する）を行うことを求めた達成基準です。これにより、ユーザーがヘルプ機能を見つけやすくします。

達成基準で挙げられているヘルプ機能としては下記があります。

  • 対人の連絡先情報： ユーザーが直接連絡を取ることができる人間の連絡先（問い合わせ先メールアドレスや電話番号など）
  • 対人への連絡メカニズム： ユーザーが人間と直接連絡を取るための方法やシステム（問い合わせフォームやヘルプチャットなど）
  • 自己支援オプション： ユーザーが自分自身で問題を解決できるようにするためのツールや情報（FAQや操作方法の解説ページなど）
  • 完全自動の連絡メカニズム： 人間の介入なしに問題を解決できるようにする自動システムやツール（AIチャットなど）

3.3.7 Redundant Entry (A) - 冗長な入力 （A）

原文：
Information previously entered by or provided to the user that is required to be entered again in the same process is either:

  • auto-populated, or
  • available for the user to select.

Except when:

  • re-entering the information is essential,
  • the information is required to ensure the security of the content, or
  • previously entered information is no longer valid.

同一プロセス内でユーザーによって以前に入力または提供された情報が再度入力を求められる場合、その情報が自動入力されるか、ユーザーが選択できるようにすることを求める達成基準です。

入力のために記憶する必要のある情報は、認知や記憶することが困難なユーザーにとって大きな障壁となりますが、この負担を軽減することが目的です。

例えば、オンラインの購入プロセスにおいて、ユーザーが配送先住所を入力した後、請求先住所が同じである場合には、簡単な操作で、その情報が自動的に請求先住所フィールドに反映されるような実装や、ユーザーがドロップダウンメニューやリストから選択することで、以前に入力した情報を再利用できるようにするような実装が考えられます。

ただし、ユーザーによる情報の再入力が不可欠な場合、コンテンツのセキュリティを確保するために必要な場合、または以前に入力された情報が、もはや有効でない場合は例外とします。

3.3.8 Accessible Authentication (Minimum) (AA) - アクセシブルな認証（最低限）

原文：
A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:

Alternative
Another authentication method that does not rely on a cognitive function test.
Mechanism
A mechanism is available to assist the user in completing the cognitive function test.
Object Recognition
The cognitive function test is to recognize objects.
Personal Content
The cognitive function test is to identify non-text content the user provided to the Web site.

ログインなど、認証プロセスの任意のステップにおいて、認知機能テスト（パスワードの記憶、テキストの転写や計算の実行、あるいはパズルの解決など）に依存した認証方法を求めないという達成基準です。このような作業は、認知や記憶することが困難なユーザーに非常に大きな負担、または不可能な負担を課す場合があります。

認知機能テストに依存しない認証方法としては、例えば、生体認証（指紋や顔認証など）やセキュリティキーによる認証、電子メールやSMSに対して、ワンタイムのログイン用コード、あるいはリンクを送信する方法などが挙げられますので、そのような認証方法のみが使用されている、もしくは代替手段として提供されている場合はこの達成基準を満たすことができます。

一方で、ごく一般的な、ユーザー名、パスワード、あるいは二要素認証システムからの認証コードなどを入力させる（認知機能テストに依存するとされる）ログインフォームなどであっても、ブラウザソフトや、サードパーティ製のパスワードマネージャーから各情報を自動入力（オートフィル）できたり、コピー・アンド・ペーストで入力できる場合、あるいは、二要素認証アプリからコピーした認証コードをペースト入力できる（つまり、それらを覚えたり、書き写したりする必要がない）ような場合は、この達成基準を満たすことができます。

これらは、「ユーザーが認知機能テストを完了するのを補助する機能が提供されている」と見なされるからですが、上記以外でも、ユーザーが認知機能テストを完了するのを補助する機能が提供されていると解釈できる場合は、この達成基準を満たせます。

なお、この達成基準においては、オブジェクト（例えば画像や動画、音声など）の認識、あるいはユーザーによって提供されたテキスト以外のコンテンツの認識を、認知機能テストを代替する認証方法として認めていますが、後述する「達成基準 3.3.9 アクセシブルな認証（高度）」においては、このような認証方法は認められません。

3.3.9 Accessible Authentication (Enhanced) (AAA) - アクセシブルな認証（高度）

原文：
A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:

Alternative
Another authentication method that does not rely on a cognitive function test.
Mechanism
A mechanism is available to assist the user in completing the cognitive function test.

達成基準の内容としては前述した「達成基準 3.3.8 アクセシブルな認証（最低限）」と同様ですが、この達成基準においては、認知機能テストに依存しない認証方法が代替手段として提供されている、もしくは、ユーザーが認知機能テストを完了するのを補助する機能が提供されている場合のみ、達成基準を満たすことができます。

ポイントとして、WCAG 2.2 では、WCAG 2.0 から存在する「達成基準 2.4.7 フォーカスの可視化」をさらに進め、その表示方法やコントラスト比などについても達成基準が設定されていますが、キーボードフォーカスの可視化は、普段、マウスしか使用していないウェブサイト制作者が見落としがちな部分です。

実際に弊社でアクセシビリティ試験を実施していても、多くのウェブサイトでフォーカスインジケータが非表示になっているケースも多く、デザインプロセスや実装ガイドラインの策定時において、明確にルール化しておくことをお勧めする部分でもあります。是非、WCAG 2.2で追加された達成基準も参考に、デザインガイドラインや実装ルールを再確認してみてください。

また、「達成基準 3.3.8 アクセシブルな認証（最低限）」、「達成基準 3.3.9 アクセシブルな認証（高度）」が該当しますが、いまだに、パスワード入力欄をコピー・アンド・ペースト禁止にするような間違った実装が多くのウェブサイトで見うけられます。

この機会に、このような実装がいかにユーザーに負担を強い、かつ場合によっては複雑で覚えにくいパスワードを設定することを忌避させ、結果としてアクセシビリティだけでなく、セキュリティも低下させている可能性を、改めて認識する必要があるのではないかと考えます。

弊社では、「Webアクセシビリティ対応（適合・準拠）サービス」「Webアクセシビリティ チェック（評価）サービス」「Webアクセシビリティコンサルティング」などの、Webアクセシビリティ関連サービスを提供しています。

これら各サービスにおける「WCAG 2.1」や「WCAG 2.2」への対応についてもご相談いただけますので、お気軽にご連絡ください。


関連する記事