【ITニュース解説】EN 301 549 is about to move to WCAG 2.2. Six criteria, one date, and one requirement that disappears.

欧州連合（EU）では、ウェブサイトやソフトウェアのアクセシビリティに関する主要な標準規格が大きな転換期を迎えている。現在、多くのシステムやサービスが準拠しているのはEN 301 549 V3.2.1という標準で、これはWCAG 2.1（Web Content Accessibility Guidelines 2.1）という国際的なガイドラインを採用している。しかし、この標準はまもなく、より新しいWCAG 2.2に基づいたバージョンV4.1.1へと移行する予定だ。システムエンジニアを目指す皆さんは、この変化が将来のシステム開発にどのような影響を与えるかを理解しておくことが不可欠である。

この新しい標準が法的な義務となる時期には特別な注意が必要だ。標準規格は、それが技術的な団体によって「公表」されただけでは法的効力を持たず、欧州官報（Official Journal）に「引用」されて初めて法的な義務となる。ETSIなどの標準化団体はV4.1.1を2026年9月2日に公表したが、EUの法律としてこれが効力を持つのは、欧州委員会が官報に引用した後だ。現在の暫定的な見込みでは、官報への引用は2026年11月末から12月中旬とされているが、過去の例では、このような日付は数週間から数ヶ月ずれ込むことが頻繁にあった。例えば、以前のV3.2.1は公表から約5ヶ月後に引用されているため、この日付が2027年までずれ込む可能性も十分に考えられる。この官報引用がなされるまでは、現在のV3.2.1、すなわちWCAG 2.1が法的な基準であり、WCAG 2.2の基準は現時点では「推奨される良い実践」であって法的義務ではない。もしWCAG 2.2への対応が今すぐ法的要件だと主張する人がいれば、それは事実と異なるため注意が必要だ。しかし、将来的に義務となる変更を完全に無視することも、後で修正作業が二度手間になるリスクがあるため、慎重な対応が求められる。

それでは、新しい標準によって具体的に何が変わるのかを見ていこう。主にウェブ、非ウェブ文書、ソフトウェアに関する条項（Clause 9, 10, 11）がWCAG 2.1からWCAG 2.2のレベルAAに移行する。この移行に伴い、特にClause 9では、レベルAとAAで新たに6つの成功基準が追加される。

一つ目は「3.2.6 Consistent Help (Level A)」だ。これは、ウェブサイト上で提供されるヘルプ機能（例えば連絡先情報、チャットウィジェット、ヘルプリンクなど）が、異なるページ間でも一貫した相対的な位置に表示されるべきだという基準である。多くのサイトでは固定ヘッダーなどを活用して既にこの要件を満たしているが、一部のページでヘルプ機能の表示位置が変わるようなサイトは修正が必要となる可能性がある。

二つ目は「3.3.7 Redundant Entry (Level A)」である。この基準は、ユーザーが多段階のプロセスの中で、一度入力した情報を再度求められることがないようにすることを求める。例えば、購入手続きで一度住所を入力した場合、その後のステップでは住所が自動的に事前入力されるか、選択肢として提供されるべきである。これは、オンラインフォームや登録プロセスでのユーザー体験向上に直結する。

三つ目は「2.4.11 Focus Not Obscured, Minimum (Level AA)」だ。この基準は、キーボード操作でフォーカスが当たった要素が、画面上の固定ヘッダー、クッキー同意バー、フローティングチャットバブルといった他の要素によって完全に隠されてはならないことを定めている。現代のウェブサイトでは固定要素が多用されるため、多くのサイトでこの基準が満たされていない可能性がある。開発者は、キーボードでサイトを操作し、フォーカスが見えなくなる箇所がないかを確認する必要がある。

四つ目は「2.5.7 Dragging Movements (Level AA)」だ。この基準は、ドラッグ操作によって実行できる機能は、ドラッグではない単一のポインタ操作（例えばクリックやボタン操作）でも実行可能であるべきだと規定している。スライダー、カンバンボード、要素の並べ替えリスト、地図のパン操作などがこれに該当し、これらの機能にはクリックで操作できる代替手段や、専用のコントロールを提供する必要がある。

五つ目は「2.5.8 Target Size, Minimum (Level AA)」である。これは、操作可能なターゲット要素（ボタンやリンクなど）が、少なくとも24x24 CSSピクセルのサイズを持つべきだという基準である。ただし、テキスト中のインラインリンクや、周囲に十分な間隔が確保されているターゲットには例外が適用される。これはWCAG 2.1のレベルAAAで規定されていた44ピクセルの基準とは異なり、レベルAAとして新たに導入されるものであり、将来的に重要となる数値は24ピクセルである。

六つ目は「3.3.8 Accessible Authentication, Minimum (Level AA)」だ。この基準は、ログインなどの認証プロセスにおいて、認知機能テスト（例えばパズルの解答、画像からのコード転記、記憶力テストなど）を必須とする場合に、必ず代替手段を提供する必要があるというものだ。また、ワンタイムコードの入力フィールドでコピー＆ペーストをブロックしたり、パスワードマネージャーの使用を妨げたりしてはならない。この基準は、自動化を意図的に妨害する認証システムが、支援技術の利用も妨害することにつながるという問題に対処する重要な変更点だ。

一方で、新しいWCAG 2.2では廃止される要件も存在する。「4.1.1 Parsing」という基準は、WCAG 2.2では適用外となる。これは、重複するID属性や閉じられていないタグといった構文エラーが、それ自体では適合失敗とはみなされなくなることを意味する。現代のブラウザはこれらのエラーから予測可能に回復するため、この基準が実質的な障壁とならなくなったためである。しかし、現在のV3.2.1はWCAG 2.1を基にしているため、官報に新しい標準が引用されるまでは、重複IDは適合失敗とみなされることを忘れてはならない。この廃止は、開発者の負担を軽減する唯一の変更点であり、不要な修正作業に時間を費やさないためにも知っておくべきポイントだ。

さらに、あまり注目されないが重要な変更点が二つある。一つは「Clause 6」が大幅に拡大されることだ。これはリアルタイムコミュニケーションに関する要件で、これまでの双方向音声だけでなく、リアルタイムの双方向通信全般（音声、リアルタイムテキスト、ビデオを含むトータル会話）に範囲が広がる。もし製品に電話、メッセージング、サポートチャット機能が含まれる場合、WCAGの要件とは別にこのClause 6を詳細に確認する必要がある。もう一つは、新しい「Annexes ZAおよびZB」が追加されることだ。これらの付録は、技術的な条項と欧州アクセシビリティ法（EAA）およびWebアクセシビリティ指令の実際の条文との間の対応関係を明示するものであり、V3.2.1にはこのような明確なマッピングがなかったため、EAAへの適合性を証明するのが複雑だった。V4.1.1ではこの対応関係が明確化されることで、適合性に関するドキュメント作成や議論が格段に容易になるだろう。

このような変化を前に、現時点でシステムエンジニアとして何をすべきか。まず、WCAG 2.2への対応を現在の法的な義務として扱うべきではない。官報に引用されていない以上、それに先行して予算を投入しても法的な義務を果たしていることにはならないからだ。しかし、完全に無視することも避けるべきである。新しい6つの基準は、年明けに法的な義務となる可能性が高く、特に「Focus Not Obscured」と「Dragging Movements」の二つは、デザイン変更が必要になることが多いため、既存のコンポーネントを修正する際に同時に対応する方が、後で緊急対応するよりもコストを抑えられる場合が多い。

重要なのは、現在の標準（V3.2.1）に対する不適合点と、新しい標準（V4.1.1）が適用された場合に新たに追加で発生する不適合点を明確に区別して評価することだ。前者は現在の法令遵守義務であり、後者は今後のロードマップ項目である。これらを一緒にして一つの「問題点」として報告することは、必要以上に問題を大きく見せ、無用なパニックを引き起こす原因となる。Curbcutのようなツールは、この区別を明確にして結果を報告し、WCAG 2.2の基準は「現在義務ではない」と明示するため、有効活用できる。これらのツールはMITライセンスで提供され、ローカルで実行されるため、プライバシーの懸念も少ない。新しい標準が官報に引用された際には、マッピングが自動的に更新され、基準の分類も切り替わるため、手動管理よりもソフトウェアによる管理が効率的だ。

最後に、自動テストの限界について理解しておく必要がある。アクセシビリティの障壁の約3分の1しか自動テストでは検出できないとされている。特に今回の新しい基準のいくつかは、機械では完全にテストすることが難しい。「Consistent Help」や「Redundant Entry」は、プロセス全体の流れに対する判断が必要であり、「Accessible Authentication」は、実際にパスワードマネージャーやスクリーンリーダーを使ってログインを試すことでしか確認できない。Curbcutのようなツールは、評価できなかった項目を黙って省略するのではなく、明示的に表示するため、誤った「合格」を避けることができる。アクセシビリティの評価は自動スキャナーから始まるが、そこで終わるものではないことを常に念頭に置くべきだ。

この解説は2026年9月2日に公表されたEN 301 549 V4.1.1および2026年9月時点でのETSIによる官報引用スケジュールに基づいている。特に引用日はまだ変更される可能性があることを理解しておきたい。この情報は法的助言ではない。