# SaaS製品とウェブアプリのためのWCAG 2.2 AAチェックリスト

<https://www.fixreports.com/ja/blog/wcag-2-2-checklist-saas-web-apps>

更新日：2026-10-26

SaaS製品には、アクセシビリティを考えるべき面が2つあります。製品を売り込むマーケティングサイトと、利用者が毎日使うアプリケーションです。マーケティングサイトでは、コントラスト不足、代替テキストの欠落、ラベルのないフォームなど、ほかのウェブサイトと同じ不適合が起こります。アプリケーションには、それに加えて固有の問題があります。パスワードマネージャーを使えないログイン手順、キーボードのフォーカスを閉じ込めるダイアログ、スクリーンリーダーが気づかないシングルページアプリケーション（SPA）の画面遷移、テキストのないデータテーブルやグラフ、代替手段のないドラッグ＆ドロップ、そして警告なしに期限切れになるセッションです。このチェックリストでは、一般的なSaaS製品の構成要素ごとに、WCAG 2.2のレベルAAを確認していきます。

**要点**

- WCAG 2.2は2023年10月にW3C勧告となり、9つの達成基準が追加されました。そのうち6つがレベルAまたはAAです（[W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)）。
- アクセシブルな認証（3.3.8、AA）により、パスワードの貼り付けやパスワードマネージャーの利用ができない限り、ログインをパスワードの記憶や書き写しに頼らせることはできません（[W3C](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)）。
- 操作できるターゲットは24 × 24 CSSピクセル以上にするか、周囲に十分な間隔を確保する必要があります（2.5.8、AA）（[W3C](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)）。
- 「保存しました」や「3件の結果」のようなメッセージは、フォーカスを移動させずにスクリーンリーダーに伝わる必要があります（4.1.3、AA）（[W3C](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)）。
- 企業や公共部門の購入担当者は、アクセシビリティ適合報告書（ACR）を求めることがよくあります。ACRは通常、情報技術産業協議会（ITI）のVPATテンプレートで作成されます（[ITI](https://www.itic.org/policy/accessibility/vpat)）。

## なぜSaaSでは、パンフレット型のサイト以上にアクセシビリティが重要なのですか？

SaaS製品は何時間も使われるもので、多くの場合、それは勤務先が選んだ製品だからです。マーケティングページのバリアで失うのは訪問者1人ですが、製品のバリアは、その人が仕事をできなくなる原因になりえます。だからこそ、大口の顧客、大学、公的機関は購入前にアクセシビリティについて尋ねることが増えており、その回答はウェブサイトだけでなく、アプリケーションも対象にする必要があります。

もう1つの理由は、自動テストで見つかるのが問題の一部にすぎないことです。axe-coreのようなツールは、ラベルの欠落やコントラスト不足など、マークアップ上の不適合を見つけます。しかし、ダイアログがフォーカスを正しい場所に戻すか、グラフのデータをテキストで得られるか、ある業務の流れをキーボードだけで完了できるかは判断できません。アプリケーションには、自動チェックと手動テストの両方が必要です。

## サインアップとログインをアクセシブルにするにはどうすればよいですか？

WCAG 2.2がSaaSにとって最も重要な新しい要件を加えたのが、認証の部分です。

- **貼り付けとパスワードマネージャーを許可します（3.3.8、AA）。** パスワードやコードの入力欄への貼り付けを禁止せず、`autocomplete="username"`、`autocomplete="current-password"`、`autocomplete="one-time-code"`を使って、ブラウザやパスワードマネージャーが入力できるようにします。
- **パズルを唯一の手段にしないでください。** ゆがんだ文字の書き写しやパズルの解答を求めるCAPTCHAは、認知機能テストにあたります。代替手段を用意し、利用者の操作を必要としない確認方法を優先します（[W3C](https://www.w3.org/TR/turingtest/)）。
- **すべての入力欄にラベルを付けます（1.3.1と3.3.2、A）。** 入力欄に関連付けた、目に見える`<label>`を使います。プレースホルダーは入力を始めると消えてしまうため、ラベルにはなりません。
- **エラーをテキストで示し（3.3.1、A）、修正方法を提案します（3.3.3、AA）。** 「パスワードは12文字以上にしてください」は役に立ちますが、赤い枠線だけでは役に立ちません。
- **同じことを二度尋ねないでください（3.3.7、A）。** 複数ステップのサインアップで会社名や住所をすでに尋ねている場合は、入力し直させるのではなく、自動で入力するか、選択できるようにします。
- **ヘルプを同じ場所に置きます（3.2.6、A）。** チャット、ヘルプへのリンク、連絡先を提供する場合は、手続きのすべてのページで同じ相対的な位置に配置します。

## 不適合が最も多いのは、どのようなフォームやエラー表示のパターンですか？

アプリケーションの不適合の大半は、フォームにあります。WebAIMが2026年に100万件のトップページを調査したところ、51%でフォームラベルの欠落が見つかりました（[WebAIM](https://webaim.org/projects/million/)）。そして、アプリケーションにはトップページよりはるかに多くのフォームがあります。

- 各入力欄にプログラムで解釈できる名前を付け、ラジオボタンなどの関連するコントロールは`<fieldset>`と`<legend>`でグループ化します。
- エラーは利用者が気づく場所で伝えます。フォーム上部のエラーの概要、または最初の無効な入力欄にフォーカスを移し、概要の各項目から対応する入力欄にリンクします。
- 必須項目は、色だけでなくテキストで示します（1.4.1、A）。
- 選択肢を選んだだけで送信したり、コンテキストを変えたりしないでください（3.2.2、A）。利用者が明示的に操作するまで待ちます。

## ダイアログ、メニュー、ポップオーバーはどのように動作すべきですか？

キーボードやスクリーンリーダーへの対応が最も崩れやすいのは、独自に作ったコンポーネントです。WAI-ARIAオーサリング・プラクティス・ガイドでは、パターンごとに期待される動作を説明しています（[W3C](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)）。

- **ダイアログ**：開いたときにフォーカスをダイアログ内に移し、開いている間はTabキーの移動をダイアログ内にとどめ、Escapeキーで閉じられるようにし、閉じたら開いたコントロールにフォーカスを戻します。ネイティブの`<dialog>`要素か、`aria-modal="true"`と名前を付けた`role="dialog"`を使います。
- **キーボードトラップなし（2.1.2、A）**：どのコンポーネントからも、キーボードで抜け出せる必要があります。
- **フォーカスの可視化（2.4.7、AA）**：フォーカスが見えるようにし、固定ヘッダー、Cookieバナー、チャットウィジェットの後ろに隠れないようにします（2.4.11、AA、2.2で追加）。
- **ツールチップとポップオーバー（1.4.13、AA）**：Escapeキーで閉じられ、ポインターを重ねても消えず、閉じるまで表示され続けるようにします。
- **文字キーのショートカット（2.1.4、A）**：文字キーを押すと操作が実行される場合は、ショートカットを無効にしたり割り当てを変えたりできるようにするか、該当するコンポーネントにフォーカスがあるときだけ有効にします。

## シングルページアプリケーションのナビゲーションはどう扱えばよいですか？

シングルページアプリケーションでは、ページを読み込まずにURLが変わるため、スクリーンリーダーが何かが起きたことを伝えない場合があります。

- ルートが変わるたびにドキュメントのタイトルを更新し、各画面にわかりやすいタイトルを付けます（2.4.2、A）。
- 新しい画面のメインの見出しにフォーカスを移すか、politeのライブリージョンで変化を通知します。Next.jsなどのフレームワークには、そのためのルートアナウンサーが含まれています。
- フォーカス順序を論理的に保ちます（2.4.3、A）。項目を削除したあとは、ページの先頭に戻すのではなく、適切な隣の項目にフォーカスを移します。
- スキップリンクやランドマークなど、繰り返されるナビゲーションを飛ばす手段を用意します（2.4.1、A）。

## ダッシュボード、データテーブル、グラフをアクセシブルにするにはどうすればよいですか？

- **表**：本物の`<table>`のマークアップを使い、見出しには`<th>`と`scope`を、さらにキャプションを付けます（1.3.1、A）。`<div>`要素で組んだグリッドにはARIAのグリッドパターンを完全に実装する必要があり、正しく作るのははるかに難しくなります。
- **グラフ**：各グラフに要点を述べる代替テキストを付け、データを表としても提供します（1.1.1、A）。系列の区別を色だけに頼らず（1.4.1、A）、ラベルや模様を加えます。
- **コントラスト**：テキストには4.5:1（1.4.3、AA）、グラフの線、アイコン、入力欄の枠線には背景に対して3:1（1.4.11、AA）が必要です。ダークモードは別に確認してください。当社の[カラーコントラストチェッカー](/ja/color-contrast-checker)では、任意の色の組み合わせをテストできます。
- **ステータスメッセージ（4.1.3、AA）**：「保存しました」「アップロードが完了しました」や結果の件数には、`role="status"`またはライブリージョンを使い、スクリーンリーダーの利用者が現在の位置を失わずに聞き取れるようにします。

## WCAG 2.2の新しい達成基準は、ウェブアプリに何をもたらしますか？

| 達成基準 | レベル | アプリでの意味 |
|---|---|---|
| 2.4.11 隠されないフォーカス（最低限） | AA | 固定ツールバー、バナー、チャットウィジェットが、フォーカスされた要素を完全に覆ってはいけません |
| 2.5.7 ドラッグ動作 | AA | かんばんボードの並べ替えなど、ドラッグで行う操作には、メニューや上下ボタンなど、シングルポインターの代替手段が必要です |
| 2.5.8 ターゲットのサイズ（最低限） | AA | ボタンとリンクは24 × 24 CSSピクセル以上にするか、各ターゲットの周りに描いた24ピクセルの円がほかのターゲットと重ならない間隔を空けます |
| 3.2.6 一貫したヘルプ | A | ヘルプへのリンク、チャット、連絡先を、すべてのページで同じ相対的な位置に置きます |
| 3.3.7 冗長な入力項目 | A | 同じ手続きの中ですでに入力された情報は、自動で入力されるか、選択できるようにします |
| 3.3.8 アクセシブルな認証（最低限） | AA | 貼り付け、パスワードマネージャー、その他の方法が使えない限り、記憶や書き写しを必要としないログインにします |

WCAG 2.2では、アクセシビリティへの実質的な影響がなくなった4.1.1 構文解析も削除されました（[W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)）。

## タイムアウト、レイアウト、ズームについてはどうですか？

- **セッションのタイムアウト（2.2.1、A）**：時間制限が必要不可欠な場合や20時間を超える場合を除き、セッションが切れる前に警告し、簡単な操作で延長できるようにします。作業中の内容を保存しておけば、最悪の事態を避けられます。
- **リフロー（1.4.10、AA）**：320 CSSピクセルの幅（1280ピクセルの画面で400%に拡大した状態に相当）でも、2方向のスクロールなしにコンテンツを利用できる必要があります。データテーブルなどのコンテンツは例外です。
- **テキストの間隔（1.4.12、AA）**：行の高さや文字の間隔を広げてもテキストが切れないようにします。高さを固定したコンテナでは、よく切れてしまいます。
- **表示の向き（1.3.4、AA）**：必要不可欠な場合を除き、アプリを縦向きや横向きに固定しないでください。

## ACRとは何ですか？必要ですか？

アクセシビリティ適合報告書（ACR）は、製品が各アクセシビリティ基準をどのように満たしているかを、「サポート」「部分的にサポート」「サポートしていない」の区分と注記で記録した文書です。多くは情報技術産業協議会が公開しているVPATテンプレートで作成されます。VPATには、WCAG、米国のリハビリテーション法508条の基準、欧州規格EN 301 549に対応する版があります（[ITI](https://www.itic.org/policy/accessibility/vpat)）。

米国の連邦政府機関は508条に基づいてアクセシブルな技術を調達しなければならず（[Section508.gov](https://www.section508.gov/)）、EUの公的機関はEN 301 549を参照します。そのため、こうした顧客に販売するB2B製品は、調達の過程でACRを求められることがよくあります。既知の不備を記載した誠実なACRのほうが、完全なサポートをうたうACRよりも購入側にとって役に立ちます。ACRは、手動テストを含む製品のテストに基づいて作成すべきもので、自動スキャンだけでは記入できません。

EUの消費者に販売している場合は、オンラインでの販売方法に欧州アクセシビリティ法が適用されることもあります。その適用範囲は当社の[欧州アクセシビリティ法のガイド](/ja/blog/european-accessibility-act-online-stores)で説明しています。これは法的助言ではありません。

## SaaSのチームは、アクセシビリティをどのようにテストすべきですか？

1. **基本は自動化します。** エンドツーエンドテストとマーケティングサイトでaxe-coreなどのエンジンを実行し、新しい違反があればビルドを失敗させます。当社の[無料のアクセシビリティチェッカー](/ja/website-accessibility-checker)は、同じエンジンを任意の公開ページで実行します。
2. **キーボードでテストします。** サインアップ、レコードの作成、設定の変更などの主要な業務の流れを、Tab、Shift+Tab、Enter、Space、Escape、矢印キーだけで完了します。
3. **スクリーンリーダーでテストします。** WindowsのNVDAと、macOSおよびiOSのVoiceOverは無料です。名前、役割、状態、メッセージが読み上げられることを確認します。
4. **ズームとサイズ変更を試します。** 200%のテキストズームと、幅320ピクセルのウィンドウを確認します。
5. **デザインシステムで修正します。** 不適合の多くは共通コンポーネントから生じます。ボタンやダイアログを一度修正すれば、使われているすべての場所で修正されます。

## よくある質問

### WCAGは、ウェブアプリのログイン後の部分にも適用されますか？

WCAGは、ログインが必要なページを含むあらゆるウェブコンテンツに適用されます。特定の製品に適合が法律で義務付けられるかどうかは、法域と顧客によって異なりますが、アクセシビリティについて尋ねる購入担当者は、通常、製品全体を対象として考えています。

### オーバーレイでSaaS製品をアクセシブルにできますか？

いいえ。オーバーレイは、アプリケーションの不適合が生じている独自コンポーネントの基盤となるコードを変更しません。大手オーバーレイ事業者に対するFTCの措置については、当社の[オーバーレイに関するガイド](/ja/blog/accessibility-overlays-ftc-order)で取り上げています。

### 自動ツールでWCAGのどのくらいをチェックできますか？

一部だけです。自動ルールは、名前やラベルの欠落、コントラストの不合格を確実に見つけますが、意味のあるフォーカス順序、役に立つ代替テキスト、わかりやすいエラーメッセージなど、多くの達成基準は人が判断する必要があります。

### どのバージョンのWCAGを目標にすべきですか？

現行のバージョンはWCAG 2.2のレベルAAです。多くの法律や調達ルールはいまもWCAG 2.1 AAを参照していますが、削除された構文解析の基準を除けば、2.2 AAを満たせば2.1 AAも満たします。

### レベルAAAを満たす必要はありますか？

コンテンツによってはAAAのすべての達成基準を満たせないため、W3Cは製品全体にAAAを求めることを推奨していません。通常の目標はレベルAAです。

## 出典

- W3C：[WCAG 2.2の新機能](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)
- W3C：[ウェブコンテンツ・アクセシビリティ・ガイドライン（WCAG）2.2](https://www.w3.org/TR/WCAG22/)
- W3C：[3.3.8 アクセシブルな認証（最低限）の解説](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)
- W3C：[2.5.8 ターゲットのサイズ（最低限）の解説](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)
- W3C：[4.1.3 ステータスメッセージの解説](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)
- W3C：[ARIAオーサリング・プラクティス・ガイド：ダイアログ（モーダル）パターン](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)
- W3C：[CAPTCHAのアクセシビリティ上の問題](https://www.w3.org/TR/turingtest/)
- ITI：[Voluntary Product Accessibility Template（VPAT）](https://www.itic.org/policy/accessibility/vpat)
- GSA：[Section508.gov](https://www.section508.gov/)
- WebAIM：[The WebAIM Million (2026)](https://webaim.org/projects/million/)