Webアクセシビリティチェックリスト: 現場のデザイナーのためのWCAG 2.2

ほとんどのWebアクセシビリティチェックリストは、デザイナーには役に立たない。WCAGの達成基準番号順に並んでいるからだ。それは弁護士が仕様を読む方法であって、誰もそうやってソフトウェアを作らない。

デザイナーは基準1.4.3を考えながらFigmaを開くわけじゃない。Figmaを開いてテキストの色を選ぶ。使えるチェックリストは、デザイナーが実際に判断を下す場所に合わせて作られている。つまり3つの別々のリストが必要だ。デザインファイル用、ブラウザ用、そしてリリース後用。それ以外の整理方法では、必ずスキップされる。

WCAG 2.2が実際に求めていること

WCAG 2.2は2026年時点の現行グローバル標準であり、WCAG 2.1に9つの新しい達成基準を追加している。主にモバイル、タッチターゲット、認知負荷、認証に焦点を当てたものだ。

デザイナーが気にすべき9つの新基準はシンプルだ。フォーカスの見た目がより厳格になった（2.4.11、2.4.13）。ドラッグ操作にはドラッグ以外の代替手段が必要になった（2.5.7）。タッチターゲットの最小サイズは、十分な余白がない限りCSSピクセルで24×24が必要（2.5.8）。ページ間でヘルプの配置を一貫させることが必要（3.2.6）。フォームは同じ情報を不必要に2度聞いてはいけない（3.3.7）。認証はパスワードを記憶するような認知テストに代替手段なしに頼ってはいけない（3.3.8、3.3.9）。

AAレベルは、EUの欧州アクセシビリティ法、米国のSection 508、英国の公共機関アクセシビリティ規制など、世界のほとんどのアクセシビリティ法で義務付けられているレベルだ。AAAはより厳格で、主に政府、医療、教育向けに設けられている。

WCAGのセクション番号で整理されたチェックリストは仕様書だ。作業が発生する場所で整理されたチェックリストは道具だ。

機能する唯一のチェックリスト形式

アクセシビリティが決定される場所は3つある。デザインファイル。ブラウザでのビルド済みインターフェース。そしてリリース後のプロダクションサイト。

アクセシビリティの失敗の約70%はFigmaで下された判断によるもので、20%は実装時に生まれ、残りの10%はリリース後にコンテンツ変更、サードパーティの埋め込み、ユーザー生成コンテンツを通じて漏れ込む。この3つのフェーズに対応していないチェックリストは、デザイナーに仕様書の言葉をワークフローの言葉に翻訳させることを強いる。そしてその翻訳の過程でチェック項目がスキップされる。

この記事の残りは、順番通りに並んだ3つのリストだ。順番通りに実行すること。デザインフェーズのチェックで失敗したものは、ビルドフェーズに到達してはいけない。ビルドフェーズで失敗したものはリリースしてはいけない。

デザインフェーズのチェックリスト（Figmaでチェックすること）

アクセシビリティの失敗の約70%はデザインファイルでの判断によるもので、つまりそこで修正するコストが最も低い。

デザインファイルはWCAG 2.2の新しいモバイル基準を確認する場所でもある。2.5.8に失敗するタップターゲットは、ほぼ例外なくデザイナーがデスクトップのピクセルで考えていて、ターゲットがパディングのない16ピクセルのアイコンになっているからだ。

コントラストについてより深く掘り下げたい場合は、コントラストルールとAPCAを参照。デザインフェーズのカラー作業こそが、ほとんどのサイトが一行もコードを書く前に審査を失敗する場所だ。

ビルドフェーズのチェックリスト（ブラウザでチェックすること）

ブラウザはアクセシビリティの判断が証明されるか、あるいは露わになる場所だ。本物の支援技術が初めてあなたの作業に触れる場所だからだ。

自動化ツールはこのうち約30%を検出できる。残りはTabキーを押してスクリーンリーダーに耳を傾ける人間が必要だ。どちらも重要で、どちらもお互いの代わりにはならない。

2026年時点での最適なブラウザステージのツールスタックはシンプルだ。自動スキャン用のaxe DevTools、ページレベル監査用のLighthouse、手動チェック用の本物のスクリーンリーダー。3つのツール、1ページ10分、本物の監査が指摘するほぼすべてを検出できる。

リリース後のチェックリスト（プロダクションで確認すること）

アクセシビリティはリリースで終わらない。コンテンツ、サードパーティの埋め込み、ユーザー生成コンテンツはすべて、デザイナーが承認した後にリリースされるからだ。

リリース後のリストこそほとんどのチームが失敗する場所だ。デザインはアクセシブルにリリースされた。CMSの著者がタグなしのPDF、自動再生動画、ランチャーのコントラスト比が2:1のチャットウィジェットで埋め尽くす。アクセシビリティはシステムの特性であり、リリースのマイルストーンではない。

3ヶ月の改修サイクルなしにWCAG 2.2をパスするサイトが必要ですか？BrainyはFigmaの最初のフレームからアクセシブルなデザインを提供します。

デザイナーのよくあるミスとWCAG基準の対応マップ

すべてのアクセシビリティ監査の指摘は特定のWCAG達成基準にたどり着く。そしてほとんどのデザイナーは同じ5つの基準に対して同じ5つのミスを犯している。

同じ10のミスがあらゆる監査レポートの大部分を占めている。これらを修正すれば、コンサルタントがスプレッドシートを開く前にWCAG 2.2 AAへの道の80%を達成している。

アクセシビリティの基本は、優れた視覚的階層の他の部分とも繋がっている。コントラスト、ターゲットサイズ、フォーカス状態はすべて階層の判断だ。階層をうまく構築したデザインは、デフォルトでアクセシビリティチェックリストのほとんどを満たす。だからこそ、優れたカラー理論とアクセシブルなデザインの重なりはほぼ完全なのだ。

1週間を潰さずにチェックリストを実行する方法

チェックリストは実行に数日ではなく数分かかる場合にのみ役に立つ。つまりツールがほとんどの作業をこなす必要がある。

作業リズムは3回のパス、各フェーズに1回、それぞれ作業がそのフェーズに到達した時点で実施する。最後にまとめて3つ全部やるのではない。最後に1つだけやるのでもない。3つの別々のパス、それぞれコストが低く、可能な限りツールで強制する。

1. デザインパス: 1画面10分。 すべてのテキストペアにStarkまたはFigmaのコントラストチェッカーを実行し、フレームをグレースケール化して色のみの情報をテストし、すべてのタップターゲットを計測する。レビュー中ではなく、ハンドオフ前に実施すること。
2. ビルドパス: 1テンプレート10分。 axe DevToolsのスキャン、キーボードのみのナビゲーションテスト、最もよく訪れるページへのスクリーンリーダーパス1回。新しいコードがリグレッションを持ち込んでマージできないようにaxe-coreをCIに統合する。
3. リリースパス: リリースごとではなく月次で。 プロダクション上でサイト全体のaxeまたはpa11yクロール、ドキュメントライブラリのPDF監査、フォームと認証フローの手動ウォークスルー。

これは製品ごとに月半日の作業と、デザインハンドオフごとに約15分だ。それ以上かかればチームは実行をやめる。それ以下では監査が未修正のまま戻ってくる。

よくある質問

WCAG 2.2は法的に義務付けられていますか？

はい、主要市場のほとんどで義務付けられている。欧州アクセシビリティ法は2025年6月に施行され、最低限WCAG 2.1を参照し、2.2が現在の実用標準となっている。米国のSection 508はWCAG 2.0を参照しているが、調達契約では2.2を要求するものが増えている。カナダ、英国、オーストラリア、日本もWCAG 2.1または2.2に紐付いた同様の要件を持っている。これらの市場向けにリリースするなら、2.2 AAが安全な目標だ。

実際に知っておくべきWCAG 2.2の新しい基準は何ですか？

デザイナーにとって最も重要なのは4つだ。2.5.7「ドラッグ操作」はドラッグ操作にドラッグ以外の代替手段を要求する。2.5.8「ターゲットサイズ（最低限）」は十分な余白を持つCSSピクセルで少なくとも24×24のタップターゲットを要求する。2.4.11「フォーカスが隠れていない」はスクロールと固定オーバーレイを通じてフォーカスされた要素が見えたままであることを要求する。3.3.8「アクセシブル認証」は代替手段（SSO、パスキー、またはメールリンク）なしにパスワードを記憶するような認知テストを禁止する。

モバイル用に別のチェックリストが必要ですか？

不要だ。WCAG 2.2はモバイルとタッチをカバーするために明示的に書かれており、だからこそ多くの新基準（ターゲットサイズ、ドラッグ、フォーカス）がモバイルを意識している。同じ3フェーズのチェックリストがモバイルWebとレスポンシブデザインに機能する。ネイティブアプリにはプラットフォーム固有の追加ガイドライン（AppleのHIGとAndroid Accessibility）があるが、WCAGのルールは依然として適用される。

WCAG 2.2の最小タッチターゲットサイズは何ですか？

2.5.8「ターゲットサイズ（最低限）」の下では24×24 CSSピクセルが最小だが、ターゲット周囲に十分な余白がある場合やテキストのインラインにある場合は例外がある。ほとんどのデザイナーが目指すべき実用的なターゲットは48×48 CSSピクセルで、AppleとGoogleのプラットフォーム推奨に一致し、WCAGの仕様のエッジケースを避けられる。

当て推量ではなく、チェックリストをリリースに組み込め

アクセシビリティはコンプライアンスタスクではない。3つの時点で構築され、ツールで強制され、人間がチェックするデザインの特性だ。

苦労せずにアクセシブルなサイトをリリースするチームは、最高の監査担当者を持つチームではない。チェックをデザインフェーズ、ビルドフェーズ、リリースフェーズに組み込み、既知の失敗があるままどのフェーズも通過させることを拒否したチームだ。

3つのリストを実行しろ。10の一般的なミスが重なる前に捕まえろ。ブラウザステージのスキャンをCIに自動化しろ。リリース後のずれを月次で監査しろ。WCAG 2.2 AAはゴールラインであることをやめて、チームの働き方の特性になる。

今日、サイト上の1つの製品サーフェスを選べ。そのFigmaファイルに対してデザインフェーズのチェックリストを実行しろ。修正数を数えろ。その数が、これを早く実行しなかったコストだ。

当て推量ではなく、チェックリストをリリースに組み込め。

3ヶ月の改修サイクルなしにWCAG 2.2をパスするサイトが必要ですか？BrainyはFigmaの最初のフレームからアクセシブルなデザインを提供します。