アクセシビリティ監査とは｜WCAG 2.2に基づく試験・報告・改善方法

ウェブサイトやアプリケーションが一般的なマウス操作で利用できても、すべての利用者が同じように目的を達成できるとは限りません。キーボードだけではメニューを開けない、読み上げソフトでは入力欄の目的が分からない、文字を拡大すると申込みボタンが画面外へ隠れる、色の違いだけでエラーを示しているといった問題があれば、一部の利用者は情報を理解できず、手続を完了できません。画面の一部が読みにくいという軽微な問題に見えても、ログイン、購入、予約、申請などの主要経路を完全に遮断する場合があります。

アクセシビリティ監査とは、ウェブサイト、アプリケーション、文書などが、多様な身体・感覚・認知・操作条件を持つ利用者にとって、知覚可能、操作可能、理解可能であり、支援技術を含む環境で堅牢に動作するかを評価する活動です。WCAG 2.2は、これら四つの原則の下に達成基準を整理したウェブアクセシビリティの国際的な技術標準です。WCAG 2.2は2023年10月5日にW3C勧告として公開され、フォーカスが隠れないこと、ドラッグ操作の代替、操作対象の大きさ、認証支援などに関する達成基準が追加されました。

ただし、監査は達成基準へチェックを付けるだけでは完了しません。自動検査で問題が検出されなくても、利用者がキーボードで注文を完了できない、読み上げ順序が意味を成さない、エラー後に修正箇所を見つけられない場合があります。W3Cは、簡易チェックや自動評価ツールだけでは包括的な適合性を判断できず、より詳細な評価が必要であると説明しています。監査では、自動検査、手動操作、支援技術試験、障害のある利用者を含む調査を組み合わせ、基準への適合と実際の利用可能性を別々に確認します。

1. アクセシビリティ監査とは

アクセシビリティ監査では、単一ページのHTMLだけでなく、利用者が目的を達成するまでの情報、操作、状態変化を評価します。デザイン、コード、文章、入力規則、外部部品を一つの利用経路として確認することが重要です。

1.1 多様な利用条件で目的を達成できるか確認する

アクセシビリティ監査とは、視覚、聴覚、身体、発話、認知などに関する障害や、一時的・状況的な制約がある利用者でも、必要な情報を取得し、操作を完了できるかを確認する活動です。文字を読む、移動する、入力する、結果を理解するという経路を分解し、どこに障壁があるかを特定します。

監査の中心となる問いは、「画面が表示されるか」ではなく、「目的を最後まで達成できるか」です。ログイン画面なら、入力欄の理解、認証情報の入力、エラー修正、成功通知までを対象にします。購入なら、商品選択、カート、住所、支払い、確認、完了までを一つの経路として評価します。

1.2 WCAGへの適合と実用性を分ける

WCAGは、監査項目と合否条件を共通化するための重要な基準です。一方、達成基準への適合だけで、特定の利用者が効率的に目的を達成できることを完全に保証するわけではありません。基準上の要件を満たしていても、説明が複雑、操作回数が過剰、重要情報を見つけにくい場合があります。

監査報告書では、WCAG達成基準への不適合と、アクセシブル・ユーザビリティ上の改善点を分けます。W3Cも、障害のある利用者を評価へ参加させることで、基準検査だけでは見つからない一般的な利用上の問題も発見できると説明しています。

1.3 デザイン・実装・内容を横断する

アクセシビリティ問題は、フロントエンドコードだけで発生するものではありません。薄い文字色はデザイン、分かりにくいリンク名は文章、関連付けられていない入力欄は実装、厳しすぎる入力形式は業務規則の問題です。

監査では、問題を発見した画面だけでなく、原因となるデザイン部品、文章規則、共通テンプレート、外部ライブラリーまで追跡します。共通部品の誤りを個別ページだけで修正すると、別ページに同じ問題が残ります。

1.4 正常状態と例外状態を確認する

最初の表示がアクセシブルでも、エラー、読み込み、空結果、権限不足、通信失敗などの状態で情報が伝わらない場合があります。フォーム送信後に赤い枠だけが付く、非同期更新が読み上げられない、読み込み中にフォーカスが失われるといった問題は、通常画面だけの確認では見つかりません。

監査では、正常、処理中、成功、警告、失敗、ゼロ件、期限切れなどを再現します。状態変化が視覚だけでなく、名前、説明、ステータスメッセージとして支援技術へ伝わるかを確認します。

1.5 継続的な品質管理として評価する

公開時に監査を通過したサービスも、新機能、コンテンツ更新、外部部品、デザイン変更によって問題が再発します。アクセシビリティを公開直前の検査として扱うと、修正費用が高くなり、重大な障壁が長期間残ります。

GOV.UKの指針では、アクセシビリティを開発の最後に追加するのではなく、設計、開発、試験の各段階で考慮し、公開後も新機能の試験や障害のある利用者との調査を継続することが推奨されています。

2. アクセシビリティ監査が重要な理由

アクセシビリティ問題は、特定の利用者だけに影響する特殊な不具合ではありません。端末、環境、一時的なけが、加齢、通信条件などによって、多くの利用者が同様の障壁を経験します。

2.1 主要なサービスからの排除を防ぐ

行政手続、金融、医療、教育、採用などがオンライン中心になるほど、操作できない画面はサービス自体を利用できない状態につながります。ボタン一つへ到達できないことが、申請や予約全体の失敗になる場合があります。

監査では問題数ではなく、影響する経路と代替手段を確認します。主要手続を完全に遮断する問題は、発生人数が少なく見えても最優先で修正します。

2.2 一般的な品質問題も発見できる

明確な見出し、入力ラベル、キーボード操作、分かりやすいエラーは、障害のない利用者にも有益です。アクセシビリティ監査によって、曖昧な操作名、複雑な入力、予測不能な画面変化など、一般的な利用しやすさの問題も見つかります。

W3Cは、障害のある利用者を評価へ含めることで、障害のない利用者にも影響する一般的なユーザビリティ問題が発見されることが多いと説明しています。

2.3 自動検査では見つからない問題を発見する

自動ツールは、ラベルの欠落、明確なコントラスト不足、重複IDなどを効率的に発見できます。しかし、代替テキストが画像の目的を正しく説明しているか、キーボード順序が自然か、読み上げ内容が理解できるかは、人の判断が必要です。

W3Cは、評価ツールが検査できる範囲はツールごとに異なり、アクセシビリティ評価を支援するものであって、ツール単体で包括的な評価を完成させるものではないとしています。

2.4 手戻りと修正費用を減らす

画面設計段階でコントラスト、見出し、フォーカス順序を確認すれば、実装後に構造を作り直すより修正しやすくなります。共通部品へアクセシビリティ要件を組み込めば、新しい画面でも同じ品質を再利用できます。

監査結果を公開直前の欠陥一覧として扱わず、設計規則、部品、受入条件へ戻します。特にダイアログ、タブ、メニューなどの複雑な部品は、各チームが個別に再実装するより、検証済み部品を共有する方が再発を減らせます。

2.5 品質の説明責任を支える

アクセシビリティ対応を行ったと説明するには、対象範囲、使用基準、試験環境、発見事項、未解決問題を記録する必要があります。自動ツールの得点だけでは、どの利用経路と支援技術を確認したかを説明できません。

W3Cは、一貫した評価報告形式が、評価の比較と結果の理解に役立つと説明し、評価報告書のテンプレートや適合性評価方法を提供しています。

3. 類似する評価との違い

アクセシビリティ監査は、自動スキャン、ユーザビリティ試験、コードレビュー、適合性評価、法的レビューと関連します。しかし、目的と証拠が異なるため、どれか一つだけで代用することはできません。

3.1 自動アクセシビリティ検査との違い

自動検査は、機械的に判定できる問題を多数のページから素早く発見します。アクセシビリティ監査では、その結果に加えて、キーボード操作、読み上げ、意味、利用経路を人が評価します。

自動検査で問題がゼロでも、すべての画像に不適切な同じ代替テキストが設定されている、ダイアログからフォーカスが外へ出るといった問題は残り得ます。W3Cの簡易評価も、通過したページに重大な障壁が残る可能性を明記しています。

3.2 ユーザビリティ試験との違い

ユーザビリティ試験では、対象利用者が効率的に目的を達成できるかを観察します。アクセシビリティ監査では、WCAG達成基準への適合性と、支援技術での技術的動作も確認します。

障害のある利用者が手続を完了できても、別の障害や支援技術へ影響する基準違反が残る場合があります。反対に、技術基準へ適合していても、文章や経路が複雑で目的を達成しにくいことがあります。

3.3 コードレビューとの違い

コードレビューでは、HTML構造、ARIA属性、イベント処理、スタイルなどを確認できます。アクセシビリティ監査では、実際にブラウザーで生成された状態と、利用者が操作した結果を評価します。

コード上では正しいラベルを設定していても、描画後に別処理が属性を上書きすることがあります。共通部品が正しくても、ページ側の使用方法によって見出し階層やフォーカス順序が崩れる場合もあります。

3.4 WCAG適合性評価との違い

WCAG適合性評価は、定義された範囲が対象レベルの達成基準へ適合するかを、一定の方法で判断します。一般的なアクセシビリティ監査は、適合性に加えて、利用しやすさ、運用、改善優先順位を扱う場合があります。

W3CのUnderstanding文書は各基準の意図と実装方法を理解するための参考資料ですが、規範的なWCAG本文そのものではありません。合否判断では、対象版の規範的な要件と監査範囲を明示します。

3.5 法令・契約レビューとの違い

法令・契約レビューでは、対象地域や契約上求められる基準、期限、文書、例外などを確認します。アクセシビリティ監査は、技術と利用体験を評価するものであり、法律上の適合性を自動的に確定するものではありません。

必要な基準や法的義務は、地域、組織種別、サービス内容によって異なります。監査報告書では技術的な結果を明確にし、法的判断が必要な部分は専門担当者へ分けます。

4. 監査範囲と試験対象を決める

すべてのページと状態を同じ深さで確認することは現実的でない場合があります。主要経路、共通部品、高リスク機能を基に、代表性のある試験範囲を作ります。

4.1 主要な利用経路を特定する

登録、ログイン、検索、購入、予約、申請、支払い、問い合わせなど、利用者がサービス価値を得る経路を選びます。閲覧数だけでなく、利用できない場合の影響を考慮します。

各経路について、開始、入力、中断、エラー、完了、再開を含めます。ログイン済み利用者だけでなく、初回利用者、権限不足、期限切れなども必要に応じて対象とします。

4.2 共通テンプレートと部品を選ぶ

ヘッダー、ナビゲーション、検索、ダイアログ、タブ、日付入力、表など、複数ページで使う部品を監査します。共通部品の問題は影響範囲が広いため、個別ページより高い優先度になることがあります。

WAI-ARIA Authoring Practices Guideは、ダイアログ、タブ、アコーディオン、ボタンなどの一般的なウィジェットについて、役割、状態、キーボード操作の設計例を提供しています。独自部品を監査する際の参考になりますが、実装例をコピーするだけでなく、利用環境で試験する必要があります。

4.3 代表的なコンテンツ形式を含める

記事、表、グラフ、動画、PDF、画像、フォームなど、異なる形式を選びます。同じテンプレートでも、編集者が設定した見出しや代替テキストによって品質が変わります。

利用頻度が高い形式と、問題が起きた場合の影響が大きい形式を含めます。自動生成コンテンツは、正常データだけでなく、長い文字列、空値、多言語などの状態も確認します。

4.4 端末・ブラウザー・支援技術を決める

対象利用者の実際の環境を基に、デスクトップ、モバイル、ブラウザー、読み上げソフト、画面拡大、音声操作などの組み合わせを選びます。すべての組み合わせを均等に試験するのではなく、主要環境とリスクの高い機能へ重点を置きます。

GOV.UKは、読み上げソフト、音声認識、画面拡大など、利用者が依存する支援技術でサービスが機能することを確認するよう案内しています。

4.5 対象外と監査限界を記録する

未確認のページ、言語、端末、支援技術、外部サービスを記録します。標本監査の結果を、確認していない全ページへ無条件に適用してはいけません。

GOV.UKの監査指針でも、監査前にどのページや機能を対象にするかを決め、利用経路と代表的なページを監査依頼へ含めることが重要とされています。

5. ページ構造・意味・コンテンツを監査する

意味のあるHTML構造は、読み上げソフトによる移動、検索、音声操作、保守を支えます。見た目だけを整えた画面では、要素同士の関係が支援技術へ伝わりません。

5.1 ページタイトルと主題を確認する

各ページには、内容や手続段階を識別できるタイトルが必要です。「入力」「確認」のような一般的なタイトルだけでは、複数タブや履歴から目的のページを見つけにくくなります。

エラー後や手続段階では、「入力内容に問題があります―申込み」のように、重要な状態をページタイトルへ含める方法もあります。ページ内の主見出しとタイトルが大きく矛盾しないようにします。

5.2 見出し階層を確認する

見出しは、文字を大きくするためではなく、内容の階層を示すために使用します。読み上げソフト利用者は、見出し一覧から目的の区分へ移動することがあります。

見出しレベルを機械的に連番にするだけでなく、親子関係が内容構造と一致するかを確認します。見出しのように見える文章が単なるdivになっている状態や、空の見出しを避けます。

5.3 ランドマークとスキップ手段を確認する

ヘッダー、ナビゲーション、主内容、補足、フッターを意味のある要素やランドマークで表します。繰り返しナビゲーションを飛ばして主内容へ移動できるスキップリンクも確認します。

複数のナビゲーションや補足領域がある場合は、名前を付けて区別します。ランドマークを過剰に追加して移動候補を増やしすぎないようにします。

スキップリンクとランドマークの例

<a class="skip-link" href="#main-content">  本文へ移動 </a> <header>  <a href="/" aria-label="ホーム">    サービス名  </a> </header> <nav aria-label="主要ナビゲーション">  <ul>    <li><a href="/products">商品</a></li>    <li><a href="/support">サポート</a></li>  </ul> </nav> <main id="main-content" tabindex="-1">  <h1>注文内容の確認</h1>  <!-- ページの主要内容 --> </main> <footer>  <!-- 共通フッター --> </footer>

5.4 リンクとボタンの目的を確認する

リンクは別の場所へ移動し、ボタンは現在の画面で処理を実行するという標準的な役割を優先します。「こちら」「詳細」のような名前だけでは、リンク一覧から目的を判断できません。

ボタン名は、押した後に起こる結果を説明します。「送信」より「申込みを確定する」、「はい」より「注文を取り消す」の方が文脈を理解しやすくなります。WAI-ARIA APGは、ボタンを処理の実行、リンクを資源への参照として区別しています。

5.5 文章と指示の分かりやすさを確認する

アクセシビリティ監査では、技術構造だけでなく、説明、専門用語、日付、エラー文も確認します。操作を「右の緑ボタンを押す」のように位置や色だけで説明すると、画面構成や利用条件によって意味が失われます。

短い文、具体的な動詞、予測可能な用語を使用します。同じ機能へ複数の名前を使わず、重要な条件は操作前に説明します。

6. キーボード・フォーカス・ナビゲーションを監査する

ポインターを使用できない利用者は、キーボード、スイッチ、音声操作などで画面を移動します。クリックできるだけでは十分ではなく、到達、認識、実行、復帰が必要です。

6.1 キーボードだけで全機能を操作する

Tab、Shift+Tab、Enter、Space、矢印、Escapeなどを使い、主要経路を操作します。マウスを使わず、メニュー、ダイアログ、入力、候補選択、ファイル操作を完了できるかを確認します。

WCAG 2.2は、原則としてすべての機能をキーボードインターフェースから操作でき、フォーカスが閉じ込められないことを求めています。

6.2 フォーカス順序を確認する

フォーカスは、視覚的・意味的な読み順に沿って移動する必要があります。CSSで要素の位置だけを入れ替えたり、正のtabindexで順序を強制したりすると、画面とキーボード順序が一致しない場合があります。

非表示要素や無効な操作へフォーカスが移らないことも確認します。動的に項目を追加した場合は、利用者の現在位置を失わないようにします。

6.3 フォーカス表示を確認する

現在どの要素を操作しようとしているかを視覚的に確認できなければ、キーボード利用者は画面内で迷います。ブラウザー既定の輪郭を無条件に消さず、背景や状態に対して見える表示を用意します。

WCAG 2.2の「フォーカスの可視化」はレベルAAであり、フォーカス表示が見えることを求めます。レベルAAAの「フォーカスの外観」は、表示領域とコントラストについて、より具体的な基準を示します。

6.4 フォーカスが固定要素に隠れないか確認する

固定ヘッダー、クッキー通知、チャット部品などがフォーカス要素を覆うと、利用者は現在位置を確認できません。ページ下部や拡大時も試験します。

WCAG 2.2で追加された「フォーカスが隠されないこと（最低限）」は、キーボードフォーカスを受けた要素が作成者のコンテンツによって完全に隠されないことを求めています。

6.5 ダイアログのフォーカス管理を確認する

モーダルを開いたらフォーカスをダイアログ内の適切な位置へ移し、開いている間は背景へ操作が移らないようにします。閉じた後は、原則としてダイアログを開いた操作へ戻します。

WAI-ARIA APGのモーダルダイアログパターンでは、背景を操作不能にし、TabとShift+Tabをダイアログ内で循環させ、Escapeで閉じる一般的なキーボード動作が示されています。

7. フォーム・エラー・認証を監査する

フォームは、アクセシビリティ障壁が業務失敗へ直結しやすい領域です。ラベル、説明、入力形式、エラー、成功、認証を一つの流れとして確認します。

7.1 入力欄へ適切なラベルを関連付ける

各入力欄には、目的を説明するラベルをプログラム上も関連付けます。プレースホルダーは入力後に消えるため、ラベルの代わりに使用しません。

W3Cのフォームチュートリアルは、ラベルが入力部品の目的を説明し、labelと入力欄を明示的に関連付ける方法を示しています。

7.2 入力前に条件を説明する

必須・任意、入力形式、文字数、必要書類などは、エラーが発生する前に説明します。ラベルだけでは足りない補足は、aria-describedbyなどで入力欄へ関連付けます。

W3Cは、フォーム全体と個別部品について、必須状態、データ形式、関連情報を事前に説明するよう案内しています。

7.3 関連する選択肢をグループ化する

ラジオボタンやチェックボックスは、個別ラベルだけでなく、質問や選択肢のまとまりを伝える必要があります。fieldsetとlegendを使い、何について選択しているかを明確にします。

W3Cは、関連するフォーム部品をグループ化することで、利用者が小さなまとまりとして理解しやすくなると説明しています。

7.4 エラーの場所・内容・修正方法を示す

エラーを色だけで示さず、どの項目にどの問題があり、どう修正すべきかを文章で説明します。送信後にはエラー概要を表示し、各問題項目へ移動できるようにします。

入力済みの正常な値を消さず、エラー項目へフォーカスまたは移動できるようにします。W3Cは、インラインのフィードバックとフォーム全体のフィードバックを組み合わせ、成功・失敗の結果を利用者へ伝えるよう案内しています。

エラー概要と入力欄の例

<div  id="error-summary"  role="alert"  tabindex="-1" >  <h2>入力内容を確認してください</h2>  <ul>    <li>      <a href="#email">        メールアドレスを正しい形式で入力してください      </a>    </li>  </ul> </div> <div>  <label for="email">    メールアドレス  </label>  <p id="email-hint">    受付結果を受信できるアドレスを入力してください。  </p>  <p id="email-error">    例：[email protected] の形式で入力してください。  </p>  <input    id="email"    name="email"    type="email"    autocomplete="email"    aria-invalid="true"    aria-describedby="email-hint email-error"  > </div>

7.5 認証が記憶や転記だけに依存しないか確認する

複雑な文字列の暗記、画像内文字の識別、パスワードの手入力だけを要求すると、一部の利用者が認証できません。パスワード管理ツール、コピー・貼り付け、自動入力を妨げないようにします。

WCAG 2.2には認知機能テストに関する「アクセシブルな認証」の達成基準が追加され、物体認識や個人的な内容などの代替がある場合を除き、記憶や転記だけへ依存しない認証が求められています。

8. 色・コントラスト・拡大・再配置を監査する

視覚的アクセシビリティは、色の数値だけでは判断できません。文字、部品、フォーカス、拡大、狭い画面、利用者の文字間隔設定を組み合わせて確認します。

8.1 文字のコントラストを確認する

通常文字は背景に対して十分なコントラストが必要です。無効状態、補足文、入力例、エラー、ホバー状態も確認します。

WCAG 2.2のレベルAAでは、通常文字に原則4.5対1、大きな文字に3対1のコントラストが求められます。

8.2 色だけで情報を伝えない

エラーを赤、成功を緑、選択を青だけで区別すると、色を認識しにくい利用者や単色表示では意味が失われます。文字、記号、線、位置を併用します。

グラフや地図では、凡例の色だけでなく、直接ラベル、模様、形を提供します。色の違いがなくても同じ結論を取得できるかを確認します。

8.3 操作部品と状態のコントラストを確認する

入力欄の境界、チェック状態、グラフの重要線、フォーカス表示など、非テキスト要素も隣接色に対して識別できなければなりません。文字コントラストだけを測って監査を終えないようにします。

WCAGの非テキストコントラスト基準は、操作部品や意味を持つ図形について、隣接色に対する識別性を扱います。

8.4 文字拡大と再配置を確認する

ブラウザーで文字を200%へ拡大し、内容や機能が失われないかを確認します。また、幅320 CSSピクセル相当の狭い表示で、二方向のスクロールを強制されずに読めるかを試験します。

表、地図、編集画面など、二次元配置が本質的な内容には例外があり得ますが、ページ全体へ不要な横スクロールを発生させないようにします。WCAG 2.2の一覧には、文字サイズ変更と再配置の基準が含まれています。

8.5 文字間隔を変更しても崩れないか確認する

利用者が行間、段落間、文字間、単語間を広げると、固定高さの部品や短い入力欄で文字が切れる場合があります。文字の重なり、切断、ボタンからのはみ出しを確認します。

WCAGの文字間隔基準は、利用者が定められた範囲で間隔を変更した場合に、内容や機能が失われないことを求めています。

9. 画像・音声・動画・文書を監査する

非テキストコンテンツには、目的に応じた代替手段が必要です。すべての画像へ長い説明を付けるのではなく、情報、装飾、機能、複雑図表を区別します。

9.1 画像の代替テキストを確認する

情報を伝える画像には、その画像が現在の文脈で果たす目的を文章で提供します。周辺文章と同じ内容を繰り返す必要はありません。

装飾画像は支援技術から無視できるようにし、リンクやボタン内の画像は操作目的を伝えます。ファイル名や「画像」という一般的な表現だけを代替テキストにしないようにします。

9.2 複雑なグラフへ要約とデータを提供する

グラフ、組織図、工程図などは、主要な結論を文章で説明し、必要に応じてデータ表や長い説明を提供します。画像内のすべてをalt属性へ詰め込むと理解しにくくなります。

表を提供する場合は、行・列の見出しを構造化します。W3Cの表チュートリアルは、データと見出しの関係を支援技術へ伝える方法を説明しています。

9.3 動画へ字幕を提供する

話している内容や重要な音を理解するために、正確で同期した字幕を提供します。自動生成字幕を使用する場合も、固有名詞、専門用語、話者、句読点を確認します。

音声だけで伝えている重要情報は字幕へ含め、視覚だけで伝えている情報には音声解説または同等の代替を検討します。

9.4 自動再生と動く内容を確認する

自動再生音声は読み上げソフトと重なり、内容を聞き取りにくくする場合があります。自動で動くカルーセル、点滅、更新情報には、停止、一時停止、非表示の方法を提供します。

WCAGの「一時停止、停止、非表示」は、利用者の意図によらず開始し、他の内容と並行して動く・更新される情報が作業を妨げないようにすることを目的としています。

9.5 PDFやダウンロード文書を含める

ウェブ画面がアクセシブルでも、申請書、料金表、報告書がタグのないPDFや画像だけで提供されていれば、利用経路は中断します。文書のタイトル、言語、見出し、読み順、表、代替テキスト、フォーム部品を確認します。

可能であれば、主要情報や手続をHTMLでも提供します。文書を監査範囲から除外する場合は、代替形式と対応方法を記録します。

10. 動的更新・カスタム部品・ARIAを監査する

JavaScriptで作られる画面では、内容がページ再読み込みなしに変化します。見た目だけを更新しても、支援技術へ名前、役割、状態、結果が伝わらなければなりません。

10.1 まず標準HTMLを使用する

ボタンにはbutton、リンクにはa、選択には標準フォーム部品を使用します。標準要素には、キーボード操作、名前、状態などの基本的な動作が組み込まれています。

ARIAは不足する意味を補うために使い、標準要素の動作を不完全に再現する目的で安易に使用しません。APGの例も、堅牢性を高めるために意味のあるHTMLを優先し、不適切なARIAを避けるよう注意しています。

10.2 名前・役割・値・状態を確認する

カスタム部品には、何の部品か、現在どの状態か、どの値かを支援技術へ伝える必要があります。開閉ボタンなら、名前に加えてaria-expandedと制御対象の関係を更新します。

見た目が切り替わってもARIA状態が古いままになっていないかを操作後に確認します。アクセシビリティツリーと実際の読み上げの両方を使用します。

10.3 ステータスメッセージを通知する

検索結果件数、保存完了、カート追加、入力エラーなどは、フォーカスを移動せずに画面へ追加されることがあります。重要な結果を適切なステータス領域として支援技術へ通知します。

すべての小さな変化を読み上げると操作を妨げるため、利用者の次の判断に必要な状態だけを通知します。WAI-ARIA APGは、通常の警告はフォーカスを動かさず通知し、作業を中断する必要がある場合は警告ダイアログを使い分ける考え方を示しています。

10.4 タブ・アコーディオン・メニューを試験する

各部品について、標準的なキー操作、フォーカス移動、選択状態、表示パネルとの関連を確認します。見た目が似ていても、タブとアコーディオンでは期待される操作が異なります。

APGは、タブ、開閉部品、ツリービュー、メニューボタンなどのパターン別に、キーボード操作とARIA関係を示しています。

10.5 アニメーション中の状態を確認する

開閉アニメーション中に、非表示内容へフォーカスが移る、読み上げ順序だけが先に変わる、操作部品が二重に存在する状態を避けます。視覚的遷移とアクセシビリティ状態の更新時点を合わせます。

利用者が動きを減らす設定を使用している場合は、不要な動きを抑えます。アニメーションを止めても内容や状態変化を理解できるようにします。

11. モバイル・タッチ・動き・時間制限を監査する

モバイルでは、小さな操作対象、端末の向き、ドラッグ、ジェスチャー、画面拡大が障壁になります。デスクトップ画面を縮小して確認するだけでは不十分です。

11.1 操作対象の大きさと間隔を確認する

小さなアイコンや隣接するリンクは、運動機能に制約がある利用者や揺れる環境で押し間違いやすくなります。表示上のアイコンだけでなく、実際に反応する領域を確認します。

WCAG 2.2にはレベルAAの「ターゲットサイズ（最低限）」が追加され、原則として操作対象を24×24 CSSピクセル以上にするか、例外条件を満たすことが求められます。

11.2 ドラッグ操作の代替を提供する

並べ替え、地図操作、スライダーなどをドラッグだけで実行させると、細かなポインター操作が難しい利用者が操作できません。移動ボタン、選択後の配置、数値入力などを提供します。

WCAG 2.2の「ドラッグ動作」は、ドラッグが本質的でない限り、ドラッグを必要としない単一ポインター操作でも同じ機能を実行できることを求めています。

11.3 画面方向を固定しない

業務上不可欠でない限り、縦向き・横向きのいずれでも利用できるようにします。端末を固定して使用する利用者は、画面を回転できない場合があります。

方向が変わった後に、内容、ボタン、ダイアログが画面外へ隠れないかを確認します。ソフトウェアキーボード表示中の入力操作も試験します。

11.4 時間制限とセッション切れを確認する

入力や理解に時間がかかる利用者が、警告なくセッションを失わないようにします。時間制限が必要な場合は、事前に通知し、延長または解除できる方法を提供します。

WCAGには、時間制限を調整可能にすることや、可能な限り時間に依存しない操作を提供する考え方があります。

11.5 複雑なポインタージェスチャーを確認する

二本指操作、経路を描く操作、ピンチなどが必要な場合、単純なタップや標準部品による代替を提供します。端末の動きや振る操作だけで機能を実行しないようにします。

代替操作は同じ画面で発見できる必要があります。ヘルプ文書だけに隠さず、関連する部品の近くへ配置します。

12. 支援技術を使った試験を行う

支援技術試験では、ツールを起動してページを読み上げるだけでなく、主要経路を実際の操作方法で完了します。試験者は使用する支援技術とブラウザーの基本操作を理解する必要があります。

12.1 読み上げソフトで構造を確認する

ページタイトル、見出し一覧、ランドマーク、リンク、フォーム部品を確認します。視覚順序を見ながら聞くのではなく、画面を見ずに情報構造を理解できるかも試験します。

操作部品では、名前、役割、状態、補足説明が適切に読み上げられるかを確認します。画像の代替テキストは、周辺文脈と合わせて意味を評価します。

12.2 読み上げソフトで主要経路を完了する

登録、購入、検索などを、読み上げソフトの標準操作で完了します。入力、候補表示、エラー、ダイアログ、完了通知を含めます。

特定のキー操作を知っている専門試験者だけが回避できる問題と、一般利用者が完了できる状態を区別します。GOV.UKは、支援技術で主要な利用経路を試験し、障害のある利用者を調査へ含めることを推奨しています。

12.3 画面拡大環境で確認する

200%から400%程度へ拡大し、重要情報を見つけられるか、固定要素が画面を過度に占有しないかを確認します。拡大利用者は一度に画面の一部しか見えないため、離れた位置のエラーや状態変化を見落とす場合があります。

フォーカスが移動した際に対象が表示領域へ入ること、ツールチップやダイアログが画面外へはみ出さないことを確認します。

12.4 音声操作で名前を確認する

音声操作では、画面上に見える名前を話して部品を操作する場合があります。視覚ラベルとアクセシブルネームが大きく異なると、表示名で操作できません。

アイコンだけのボタンには、目的が分かる表示名またはアクセシブルネームを提供します。同じ名前のボタンが多数ある場合は、必要な文脈を追加します。

12.5 障害のある利用者による評価と区別する

専門家による支援技術試験は技術的不具合を発見しますが、実際の利用者の戦略、経験、優先順位を完全には代替しません。障害のある利用者を含む調査を別途実施します。

ただし、少数の参加者による調査を、すべての障害やWCAG基準を評価した結果として扱ってはいけません。W3Cも、参加者の範囲と評価限界を報告書で明確にするよう注意しています。

13. 自動検査・手動試験・証拠を管理する

効率的な監査では、自動検査で明確な問題を先に除き、手動試験と支援技術試験へ集中します。各問題について、再現可能な証拠を残します。

13.1 HTMLと基本構造を検証する

重複ID、無効な入れ子、不完全な属性などは、支援技術による解釈へ影響する可能性があります。HTML検証だけでアクセシビリティを保証できませんが、基本的な構造問題を早期に除けます。

DWPのアクセシビリティ試験手順では、HTML検証、自動ツール、手動試験、支援技術試験の四段階を組み合わせる方法が示されています。

13.2 自動検査を複数状態で実行する

初期画面だけでなく、メニュー展開、ダイアログ表示、フォームエラー、ログイン後など、動的状態でも自動検査を実行します。非表示状態だけを検査しても、操作後に追加される問題を見つけられません。

自動テストへ組み込む場合は、問題件数だけでなく、基準、要素、ページ、初回発生版を記録します。誤検出として除外する場合も理由と再確認日を残します。

13.3 手動確認表を経路単位で作る

コントラストや代替テキストだけを項目別に確認すると、利用者が一連の手続を完了できるかを見落とします。基準別の確認表と、利用経路別の試験を組み合わせます。

各経路には、キーボード、拡大、読み上げ、エラー状態などの条件を割り当てます。誰がどの環境で確認したかを記録します。

13.4 問題を再現可能に記録する

問題報告には、ページ、利用者状態、端末、ブラウザー、支援技術、操作手順、実際の結果、期待結果、関連する達成基準を含めます。

「スクリーンリーダーで使えない」のような広い表現ではなく、「ダイアログを開いた後も背景リンクへTab移動でき、現在の操作範囲を判断できない」のように具体化します。

13.5 試験証拠の限界を記録する

自動検査通過、特定の読み上げソフトでの成功、利用者調査の結果は、それぞれ対象範囲が異なります。報告書には、何を確認した証拠かを記載します。

W3Cは、評価ツールの機能や自動判定範囲が異なるため、目的に合うツールを選び、結果を評価方法全体の一部として扱うよう案内しています。

14. 監査報告書と改善優先順位を作る

監査報告書では、問題を達成基準順に並べるだけでなく、利用者の目的、影響、範囲、修正方法を説明します。重大な経路障害を軽微な表示問題へ埋もれさせないことが重要です。

14.1 利用者への影響を中心に記載する

「ラベルがありません」だけでなく、「読み上げ利用者が二つの電話番号入力欄を区別できず、正しい情報を入力できない」のように影響を説明します。

利用者、目的、障壁、結果を一文でまとめると、技術担当者以外も優先度を理解できます。達成基準番号は根拠として併記します。

14.2 重大度と適合レベルを分ける

レベルAの問題が常にレベルAAの問題より重大とは限りません。特定の主要経路を完全に遮断する問題と、限られた画面で補足文字のコントラストが不足する問題では、利用者影響が異なります。

適合レベル、利用者影響、発生範囲、利用頻度、代替手段を別々に評価します。法令・契約上の必須対応は、製品上の優先順位と別に管理します。

14.3 共通原因と個別問題を分ける

百ページで同じボタンのコントラスト不足が見つかった場合、百件の個別修正ではなく、共通部品の一件として根本修正します。ただし、影響ページ数は重大度へ反映します。

コンテンツ入力による問題と、部品の実装問題も分けます。編集者向けガイド、入力検証、テンプレート修正など、原因に合った対策を選びます。

14.4 修正案と再試験条件を記載する

「ARIAを追加する」のような抽象的な修正案ではなく、使用する標準要素、期待するキーボード動作、フォーカス移動、読み上げ内容を記載します。

修正後にどの条件で解消を確認するかも定めます。コード差分だけでなく、実際のブラウザーと支援技術で再試験します。

14.5 暫定対応と根本対応を分ける

重大問題の根本修正に時間がかかる場合は、代替経路、有人支援、機能停止などの暫定対応を用意します。ただし、利用者へ追加負担を強いる代替手段を恒久対応としないようにします。

改善優先度を計算する例

from __future__ import annotations from dataclasses import dataclass @dataclass(frozen=True) class AccessibilityIssue:    name: str    journey_impact: int    affected_scope: int    workaround_difficulty: int    information_criticality: int    frequency: int def priority_score(    issue: AccessibilityIssue, ) -> float:    values = [        issue.journey_impact,        issue.affected_scope,        issue.workaround_difficulty,        issue.information_criticality,        issue.frequency,    ]    if any(value < 1 or value > 5 for value in values):        raise ValueError(            "各評価は1から5で指定してください"        )    return (        issue.journey_impact * 0.30        + issue.affected_scope * 0.20        + issue.workaround_difficulty * 0.20        + issue.information_criticality * 0.20        + issue.frequency * 0.10    ) issue = AccessibilityIssue(    name="キーボードで支払いダイアログを閉じられない",    journey_impact=5,    affected_scope=4,    workaround_difficulty=5,    information_criticality=5,    frequency=5, ) print(    f"改善優先度: {priority_score(issue):.2f}" )

この点数は、改善順序を検討する補助です。主要経路を完全に遮断する問題、情報を取得できない問題、利用者へ危険を与える問題は、合計値にかかわらず緊急対応とする場合があります。

15. アクセシビリティ監査を継続運用する

アクセシビリティは、一度の監査報告書で完成するものではありません。設計、実装、コンテンツ、調達、公開後の運用へ責任と確認方法を組み込みます。

15.1 役割と所有者を明確にする

デザイン担当は色と状態、開発担当は構造と操作、コンテンツ担当は見出しと代替テキスト、商品責任者は経路と優先順位を管理します。アクセシビリティ担当者一人へすべてを任せないようにします。

問題ごとに、修正担当者、受入担当者、期限を設定します。共通部品と個別ページの所有者を分けます。

15.2 設計・開発の受入条件へ組み込む

設計レビューでフォーカス順序、状態、拡大を確認し、部品開発でキーボードと読み上げを試験します。機能の完了条件にアクセシビリティ要件を含めます。

検証済み部品を共有し、利用方法と禁止事項を文書化します。GOV.UKも、アクセシブルで応答性のある検証済みデザインシステム部品を利用することを推奨しています。

15.3 自動回帰試験を設定する

新しいコードによってラベル、コントラスト、ARIA関係などが壊れた場合に、自動検査で早期に検出します。共通部品と主要ページを継続的インテグレーションへ含めます。

ただし、自動試験の通過を監査完了と扱わず、キーボード、拡大、支援技術の定期試験を残します。

15.4 変更時と定期の再監査を行う

ナビゲーション変更、デザインシステム更新、認証変更、外部部品導入など、影響の大きい変更後に再監査します。主要経路は一定期間ごとにも確認します。

GOV.UKは、サービスへ大きな変更を加えた場合に再監査を行い、公開後もアクセシビリティ試験と利用者調査を続けるよう案内しています。

15.5 利用者の報告を改善へ戻す

アクセシビリティ問題を報告できる連絡方法を用意し、受付、調査、暫定対応、修正、連絡の流れを定めます。報告者に専門用語や達成基準番号を求めないようにします。

問い合わせを個別対応で終わらせず、同じ部品、経路、設計規則へ問題がないか分析します。再発した問題は、試験表と自動検査へ追加します。

おわりに

アクセシビリティ監査とは、ウェブページへ自動検査ツールを実行し、WCAGの項目へ印を付けるだけの活動ではありません。多様な利用条件を持つ人が、情報を知覚し、画面を操作し、内容を理解し、支援技術を使って主要な目的を完了できるかを確認する活動です。ページ構造、キーボード、フォーカス、フォーム、エラー、色、拡大、動画、動的更新、モバイル、文書を、利用経路全体として評価する必要があります。

監査では、自動検査、手動試験、支援技術試験、障害のある利用者を含む評価を組み合わせます。自動ツールは大量の明確な問題を効率的に検出できますが、代替テキストの妥当性、フォーカス順序、読み上げ内容、手続の分かりやすさまでは判断できません。反対に、一人の利用者が経路を完了できたことだけで、すべての達成基準や障害条件へ適合すると判断することもできません。それぞれの方法が確認した範囲と限界を報告書へ記録することが重要です。

最終的な目的は、監査で高い得点を得ることではなく、利用者が障壁に遭遇せず、自立して必要な情報とサービスへ到達できる状態を維持することです。重大問題を利用者影響で優先順位付けし、修正を共通部品、設計規則、コンテンツ手順、回帰試験へ戻します。アクセシビリティを公開前の一回限りの検査ではなく、設計、開発、運用、利用者フィードバックを通じた継続的な品質管理として扱うことで、再発を減らし、より多くの人が利用できるサービスへ近づけます。