会員登録画面を作成したと仮定しましょう。メールアドレスとパスワードを入力し、利用規約に同意してから登録ボタンを押す画面です。マウスで操作すると問題がないように見えます。しかし、キーボードで利用規約を開いたときに閉じるボタンへ移動できなければ、登録を完了するのは困難です。入力エラーを赤い枠線だけで示していると、色を区別しにくい人には、何を修正すればよいのか分かりにくくなります。
この例は、特定のサービスを検査した結果ではなく、アクセシビリティを説明するための仮想的な状況です。ウェブアクセシビリティを学ぶ出発点は、このような状況でユーザーが情報を得て、必要な作業を完了できるかを確認することです。基準を理解すれば問題が生じた理由を説明でき、評価方法を設計すれば修正結果も確認できます。
このシリーズでは、その過程をWCAGとAIを併用しながら学びます。各基準が保護しようとしているユーザーのニーズを説明し、実装例を分析したうえで、評価に必要な資料とプロンプトを提供します。最初の記事では、学習全体の流れと評価を始める方法を整理します。
ユーザーが情報を得て機能を利用できるように設計する
W3Cのウェブアクセシビリティの紹介では、障害のある人がウェブの情報を知覚し、理解し、ナビゲーションし、操作できるように、ウェブサイトやツールを設計することを説明しています。視覚や聴覚だけでなく、身体、認知、学習などに関わる多様なアクセスニーズを含みます。W3Cのウェブアクセシビリティの紹介
ユーザーは同じ画面を異なる方法で利用します。スクリーンリーダーで見出しや入力項目をたどることもあれば、画面を拡大して一部の領域だけを見ることもあります。マウスの代わりにキーボードや別の入力装置を使ったり、動画の音声を字幕で理解したりすることもあります。設計と実装は、こうした利用方法でも情報と機能を伝えなければなりません。
手をけがしてマウスを使いにくい状況や、音を聞くことができない環境でも、アクセシビリティに配慮した機能は役立ちます。ただし、こうした付加的な利点だけでアクセシビリティを説明すると、障害のある人がサービスを利用するために必要な条件が曖昧になります。このシリーズでは、ユーザーのアクセスニーズと、実際に行おうとしている作業を判断の基準にします。
先ほどの会員登録画面では、案内を読み、項目の用途を理解し、利用規約を確認し、エラーを修正して登録を完了する過程が評価対象です。利用規約のポップアップが開くことを確認するだけでは不十分です。ポップアップ内に移動し、内容を確認し、閉じた後に入力を続けられるかも確認する必要があります。
WCAGを実装と評価の共通基準として読む
WCAGはWeb Content Accessibility Guidelinesの略です。このシリーズでは、W3C勧告標準であるWCAG 2.2を基準とします。アクセシビリティを意味するa11yは、accessibilityの最初の文字aと最後の文字yの間にある11文字を数字で省略した表記です。
WCAGの四つの原則を知っておくと、個々の項目を読む際に、その要件が必要な理由を理解しやすくなります。以下の質問と会員登録画面の例は、各原則を実務に結び付けるための説明です。W3Cのアクセシビリティの原則
| 原則 | 設計時に確認する質問 | 会員登録画面で確認する例 |
|---|---|---|
| 知覚可能 — Perceivable | 必要な情報を、ユーザーが知覚できる形で提供しているか？ | エラーの内容を、色とともにテキストでも提供しているか？ |
| 操作可能 — Operable | ユーザーの入力方法で機能を操作できるか？ | キーボードで利用規約を開いて閉じた後、登録を続けられるか？ |
| 理解可能 — Understandable | 情報と操作方法を理解し、結果を予測できるか？ | パスワードの条件とエラーの修正方法が具体的か？ |
| 堅牢 — Robust | ブラウザーと支援技術が要素の意味と状態を解釈できるか？ | 入力項目の名前とエラー状態がプログラムによって伝えられるか？ |
各原則の下にはガイドラインと達成基準があります。例えば1.1.1は、非テキストコンテンツの代替テキストに関する達成基準です。実際の判定では、適用条件と例外を読む必要があります。Understanding文書は趣旨や事例を説明し、Techniques文書は実装方法を参照するのに役立ちます。基準を満たす実装が、特定の一つの例に限定されるわけではありません。WCAG 2.2標準
達成基準にはA、AA、AAAのレベルが指定されています。AAへの適合にはAとAAの要件をともに満たす必要があり、AAAへの適合には三つのレベルすべての要件が含まれます。レベルを実装の難易度や問題の重大度の順位として解釈すると、優先順位を誤って設定するおそれがあります。W3Cは、すべてのサイトにAAAの全要件を満たすことを一般的な方針として求めることは推奨していません。一部のコンテンツでは、すべてのAAA達成基準を満たすことができないためです。W3Cの適合性の解説
WCAG 2.2の有効な達成基準は86個です。Aが31個、AAが24個、AAAが31個で、このシリーズではそれぞれを一つの記事と一つのプロンプトで扱う予定です。WCAG 2.2で削除された4.1.1 Parsingは、現在の評価項目には含めません。WCAG 2.2標準、WCAG 2.2の変更点
初めて評価を設計する場合は、WCAG 2.2 AAを作業目標の初案とし、サービスの利用者やコンテンツに必要な追加基準を検討する方法を提案します。これは、このシリーズの実務上の提案です。特定のプロジェクトの目標レベルを、この記事だけで確定することはできません。
画面の状態と完全な利用過程を評価範囲に含める
会員登録ページには、一つのURLでも複数の状態があります。初めて訪れた状態、パスワードの条件が表示された状態、利用規約のポップアップが開いた状態、エラーが発生した状態、登録が完了した状態は、それぞれ異なります。モバイル画面や拡大した画面では、レイアウトも変わることがあります。
そのため、評価時にはURLとともに、状態、操作手順、実行環境を記録する必要があります。最初に表示される画面を検査した結果は、その時点で確認した範囲についての結果です。ログイン後の画面やエラー処理まで確認したと解釈することはできません。
WCAGの適合要件も、ページ全体と完全なプロセスを対象にしています。複数のページにわたる会員登録や購入の過程では、その過程に必要なページが目標レベルを満たす必要があります。一部の要素の検査結果を合算したスコアだけで、その過程の適合性を宣言することはできません。WCAGの適合要件
サイトが大規模であれば、代表的なページと状態を選んで評価できます。W3CのWCAG-EM 2.0は、範囲の定義、対象の探索、代表サンプルの選定、評価、結果報告の手順を説明しています。サンプル評価の範囲と、サイト全体についての主張は、区別して記録する必要があります。WCAG-EM 2.0評価方法論
会員登録画面から始めるなら、次のように状態を分けることができます。以下の表は評価計画の例であり、実際の問題を発見したという意味ではありません。
| 状態 | 確認したい内容 | 準備する証拠の例 |
|---|---|---|
| 初回訪問 | 入力項目の用途と条件を見つけられるか？ | レンダリングされたDOM、画面、アクセシビリティツリー |
| 利用規約のポップアップが開いている | ポップアップを操作し、入力画面に戻れるか？ | キーボード操作の手順、フォーカスの記録、状態別の画面 |
| 不正なメールアドレスを送信 | エラーのある項目と修正方法が分かるか？ | エラー状態のDOM、案内文、支援技術の出力 |
| 入力を修正して再送信 | エラーが解消され、次の段階へ進むか？ | 修正前後の状態と操作記録 |
| 登録完了 | 処理結果を知覚できるか？ | 完了画面、状態変化の記録、必要な支援技術の出力 |
主要な利用過程から始める理由は、問題が作業の完了に及ぼす影響を説明しやすいためです。最初に選んだ過程を評価した後、他の機能や共通コンポーネントへ範囲を広げます。この過程の評価に合格したことを、サイト全体の評価完了として記録しないようにします。
マルチモーダルAIで意味と動作の評価範囲を広げる
アクセシビリティツールは、定められたルールで素早く確認できる問題を検出します。検査範囲と結果の意味は、ツールに実装されたルール、入力資料、実行した状態によって変わります。W3Cは、評価ツールだけですべてのアクセシビリティの側面を自動判定することはできず、結果が不正確な場合もあると説明しています。アクセシビリティ評価ツールの役割と選び方
このシリーズでは、従来のルール検査では扱いにくかった意味や文脈、インタラクションも、AIを通じて評価する方法を探ります。テキストと画像をともに処理するマルチモーダルモデルに必要な資料を提供し、ブラウザー操作ツールを接続すると、評価に利用できる観察範囲が広がります。項目ごとに収集方法と判断手順を設計し、検証することが、このシリーズの方向性です。
代替テキストを例に挙げます。画像にalt属性があるという事実と、その内容が画像の目的を適切に伝えているという判断は異なります。同じ配送トラックの画像でも、配送案内の装飾なのか、配送状況の確認機能に移動するリンクなのかによって、必要な代替情報は変わります。W3Cの代替テキストの決定木も、画像の機能と文脈に応じて選択するよう案内しています。代替テキストの決定木
AIには、画像と代替テキストだけでなく、周囲の文章、リンクかどうか、リンク先なども提供できます。モデルが画像の見た目を描写するだけにとどまらず、その位置で必要な情報を伝えているかを検討するように、評価の質問を設計するということです。実際にどの程度正確に判断できるかは、事例を集めて検証する必要があります。
動作の評価では、収集する証拠がさらに異なります。利用規約のポップアップのスクリーンショットからは、レイアウトや一部の視覚的な状態を確認できますが、キーボードフォーカスがどこへ移動したかを確認するには、実際の操作と記録が必要です。エラーがスクリーンリーダーに伝えられるかどうかも、画面を見るだけでは確定できません。使用した支援技術の出力など、その判断に必要な観察を収集しなければなりません。
このとき、資料がないという事実と、AIが判断に失敗したという事実を区別すると、次の作業が明確になります。フォーカスの記録が提供されていなければ、収集の段階を追加します。必要な記録があるにもかかわらず判定が不安定であれば、入力の構成、基準の解釈、プロンプト、モデルの性能を検討します。このように、評価範囲を段階的に広げることができます。
数値測定と意味判断の役割も定める必要があります。例えばコントラストを評価する際は、モデルに画面を見て数値を推測させるよりも、その画面の色と計算に必要な条件をツールで確認し、測定結果を提供するほうが検証しやすくなります。エージェントは、必要な状態へ移動し、測定ツールを実行し、その結果を該当する基準に結び付けるように設計できます。
最近のAI評価研究から読み取れる可能性と条件
2025年に公開された研究、Towards Scalable Web Accessibility Audit with MLLMs as Copilotsは、ページのサンプル選定とアクセシビリティ監査にマルチモーダルモデルを活用する構造を提案しています。AIの活用を個々の画面の判定から評価の過程へ広げた研究事例です。研究原文
2026年9月に公開されたプレプリント、Agentic Web Accessibility Auditingは、基準ごとの指示を受けたエージェントがページを調査し、ツールを実行する方法を扱っています。研究者らは、11の学術プラットフォームの24ページから構成した、ページと基準の組み合わせ250件の記録で評価しました。問題が報告されたページと基準の組み合わせ78件のうち、エージェントは67件を検出し、再現率は86%でした。一方、問題ありと判定した記録が基準となる正解と一致した割合である適合率は56%でした。研究原文と評価範囲
これらの数値は、その研究条件における結果です。40の基準のエージェントを実装しましたが、問題事例が含まれていた基準は15個であり、報告書で問題として言及されていない記録を、問題のない事例と推定していました。保存されたページの動作は実際のサービスと異なる可能性があり、開発過程で評価ページに接していた点も一般化を制限します。したがって、86%をあらゆるウェブサイトでの検出率として使用することはできません。
このシリーズの評価設計では、各項目について正常事例、問題事例、境界事例を用意する方法を提案します。検出した問題の数とともに、誤検出、見逃し、判断保留、反復実行時の一貫性を確認し、結果を再現するために必要な労力も記録します。プロンプトが改善されたかどうかは、このように集めた根拠に基づいて判断する予定です。
最初の実習：一つの利用過程の評価計画を作る
最初の記事の実習では、自分のサービスでよく利用される過程を一つ選びます。資料請求、会員登録、商品検索のように、開始条件と完了条件を説明できる過程であれば構いません。URLを開けるツールが接続されているか、ログインやテスト環境が必要かも記載しておきます。URLをプロンプトに入れるだけで、すべてのモデルがページを訪問したり操作したりできるわけではありません。
次のリストのチェックは、準備内容を確認したという意味です。アクセシビリティ基準を満たしたことを示すものではありません。
- ユーザーが行おうとしていることと完了条件を記載しました。例：利用規約を確認して登録し、完了案内を知覚する。
- 開始画面と、エラー・ポップアップ・完了の各状態を整理しました。まだ確認していない状態は未確認として残しました。
- 目標とするWCAGのバージョンとレベル、ブラウザー・画面サイズ・入力方法・支援技術などの評価環境を記録しました。未決定の条件も示しました。
- 提供する資料と接続されたツールを区別しました。個人情報と認証情報を取り除き、キャプチャした時点と状態を併せて記録しました。
これらの資料を概要評価計画プロンプトに入れると、利用過程、必要な証拠、収集の順序、未確認事項を整理するよう依頼できます。まだ実行して得た資料がなければ、出力も評価計画として読む必要があります。
例えば、「エラーをスクリーンリーダーで確認する必要がある」という出力は、後続の作業です。「エラーが伝えられない」という判定には、観察した状態と実際の出力が必要です。結果を確認するときは、モデルの説明とともに、根拠が指している原資料も確認します。
評価を進めた後は、実行の有無と判定を別々に記録する方法を用います。資料収集や操作の失敗は実行状態として残し、基準についての結果は、満たしている・満たしていない・該当なし・判断保留などで記録します。未実行を「満たしている」に変更したり、適用の有無を確認していない項目を「該当なし」としたりすると、評価範囲が分かりにくくなります。
問題が確認されたら、ユーザーへの影響と再現手順を先に記載します。登録を進められない問題なのか、案内を理解しにくい問題なのか、複数の画面で繰り返される共通コンポーネントの問題なのかに応じて、修正の順序を決めることができます。改善後は同じ環境と状態で再確認し、変更によって他の動作に問題が生じていないかも確認します。
項目別の学習を再利用可能な評価過程につなげる
次の記事からは、WCAG 2.2の達成基準を一つずつ扱います。各記事は、その基準が必要となるユーザーの状況から始め、適用条件と例外、実装例を説明します。続いて、AIに提供する資料とプロンプト、出力の根拠の読み方、改善後に確認する内容をつなげます。
全体の目次は、四つの原則と基準番号に沿って探せるように構成します。最初から順番に読むことも、先ほど選んだ利用過程に関連する記事から探すこともできます。AAを作業目標とした場合はAとAAの基準を併せて検討し、AAAの記事では、サービスに追加で適用する要件を確認できます。
シリーズの最後には、項目別の評価をつなげて範囲を定め、証拠を収集し、結果を報告した後、改善を再確認するエージェントの構造を扱う予定です。プロンプトと検証方法も、事例や研究に応じて更新します。各記事では、説明用の例と実際の評価結果を区別し、検証した環境と範囲を併せて記録します。
基準に基づく評価とともに、ユーザー体験も確認する必要があります。W3Cは、障害のある利用者に評価へ参加してもらうと、基準の検査だけでは十分に明らかにならない利用上の問題を見つけるのに役立つと説明しています。そのような参加を、AIが模倣したユーザー視点の回答で代替したと記録することはできません。利用者とともに行うアクセシビリティ評価
最初の段階で準備するのは、評価する利用過程一つと、その過程を観察するための資料です。次の記事では、画像が伝える情報をどのような代替手段で提供すべきか、非テキストコンテンツの基準である1.1.1から見ていきます。
参考資料
基準と研究資料の確認日：2026年10月1日。以下の研究結果は研究者らが報告した内容であり、このシリーズのプロンプトを実行した結果ではありません。
- W3C — Introduction to Web Accessibility：アクセシビリティの対象と多様な利用方法。
- W3C — Accessibility Principles：四つの原則と主な要件。
- W3C — WCAG 2.2：達成基準と適合要件の正本。
- W3C — Understanding Conformance：レベルと適合性の解説。
- W3C — What's New in WCAG 2.2：追加された基準と4.1.1の削除。
- W3C — WCAG-EM 2.0, 2026-07-23 Group Note：評価範囲、代表サンプル、報告手順。
- W3C — Selecting Web Accessibility Evaluation Tools：ツールの検査範囲と結果の解釈。
- W3C — An alt Decision Tree：機能と文脈に応じた代替テキストの選択。
- Guほか — Towards Scalable Web Accessibility Audit with MLLMs as Copilots, 2025-11-05：マルチモーダルモデルを活用した監査支援の研究。
- Mishraほか — Agentic Web Accessibility Auditing, 2026-09-10 v2, プレプリント：基準別のエージェント、実験結果、限界。
- W3C — Involving Users in Evaluating Web Accessibility：利用者の参加と基準に基づく評価の併用。
必要な資料を添えて実行してください。
あなたは、ウェブアクセシビリティの評価計画を設計するコンサルタントです。 今回の作業の目的は、一つの利用過程の評価範囲と証拠収集計画を作成することです。 資料を実際に検討したり、操作を実行したりする前に、アクセシビリティの判定を行わないでください。 [入力 — 分かる内容だけを記入し、不明な条件は「未定」と表示] サービスの説明： 利用者が行おうとしていること： 完了条件： 対象URLとテスト環境： 目標とする基準とレベル：WCAG 2.2 / レベル未定またはA・AA・AAA 評価環境：ブラウザー、画面サイズ、拡大設定、入力方法、支援技術 既知の状態：初期・ポップアップ・エラー・完了など 提供資料：DOM、スクリーンショット、アクセシビリティツリー、操作記録、音声・動画など 接続されたツールと実際の権限：URLを開く、キーボード入力、キャプチャ、測定など 許可された操作：テストデータの使用範囲と送信が許可されているかどうか 資料ごとの識別子・収集時点・該当する状態： [作成原則] 1. 提供された事実、評価者が置いた仮定、まだ確認していない内容を区別してください。 2. URLがあるという理由で、訪問・ログイン・操作・観察を完了したと記載しないでください。 今回の依頼は計画の作成です。フォームの送信など、実際の操作を実行しないでください。 3. ユーザーが入力した目標レベルに合わせて基準を選定してください。AAにはAとAAが含まれます。 WCAG 2.2で削除された4.1.1 Parsingは、評価対象に含めないでください。 基準の原文や適用条件を確認できない場合は、「原文の確認が必要」として残してください。 4. ルール検査、意味・文脈の評価、実際の操作を、特定の基準全体の固定的な分類にしないでください。 同じ基準の中でも、検査の質問と状態によって、必要な方法と証拠が異なる場合があります。 5. スクリーンショットだけで、フォーカスの移動やスクリーンリーダーの出力を確定しないでください。 観察が不足している理由と、追加で収集する資料を説明してください。 6. 個人情報や認証情報を含む資料を提出しないよう案内してください。 [出力] A. 評価範囲：選択した利用過程、開始・完了条件、含める範囲・除外する範囲、 目標バージョン・レベル、未定の実行環境。サイト全体の評価との違いも示してください。 B. 状態と証拠の計画表： 状態ID | 進入・終了条件 | ユーザーの作業 | 候補となるWCAG基準と適用理由 | 必要な証拠・ツール | すでに提供された資料 | 追加収集 | 完了の確認方法 計画した状態と、実際に観察した状態を区別してください。 C. 推奨する実行順序：必要な状態の復元、資料収集、ルール検査と意味の評価、 操作記録の確認、検討と修正後の再評価をつなげてください。 ツールがない作業や許可範囲を超える作業は、実行の提案としてのみ残してください。 D. AI評価の検証計画：正常・問題・境界事例の構成方法、 基準となる正解の根拠を検討する手順、誤検出・見逃し・判断保留と実行失敗、 反復時の一貫性と結果の再現に必要な労力の記録方法を提案してください。 測定前に、正確さ・コスト・評価完了を主張しないでください。 E. 後続の結果記録様式： 状態・環境 | 基準・検査の質問 | 実行状態 | 判定 | 証拠IDと位置 | ユーザーへの影響 | 仮定・反証 | 修正提案 | 再評価条件 実行状態は、未実行・実行済み・失敗・ブロックに区別してください。 判定は、未評価・満たしている・満たしていない・該当なし・判断保留に区別してください。 「未評価」は判定を行っていない状態であり、「判断保留」は評価を試みたものの、 証拠や解釈が十分でない状態です。該当なしには、適用しない理由を記載してください。 F. すぐに準備する資料：計画を進めるために必要な最小限の資料と質問を、優先順位に沿って記載してください。 出力は日本語で作成してください。仮想的な問題・ユーザー体験・測定値を、実際の結果のように作り上げないでください。