AIが作った画面は操作できるか。アクセシビリティを確かめる

AIが作った画面を画像で比べると、配置、色、余白、文言の差には気づけます。しかし、その画像からは、Tabキーでボタンへ移れるか、現在位置が見えるか、送信後のエラーが読み上げられるかは判定できません。見た目が仕様どおりでも、操作の途中で止まる余地が残ります。

そこで画像差分や目視確認から操作受入を切り分け、キーボード操作時の状態遷移、見えるフォーカス、支援技術によるエラー通知を扱います。この分け方はW3C所定の分類ではなく、一般原則を自社の受入作業へ落とすための提案です。公式要件と自社の確認手順を混同しないよう、台帳には「根拠」と「今回の操作条件」を別欄で残します。

AIに実装もテストコードも作らせる場合でも、受入条件まで生成結果へ委ねないことが重要です。AI駆動開発の開発フロー｜レビュー・テスト・CIで人の判断を残すで扱うマージ条件のうち、利用者が実際に操作できることを確かめる工程として位置づけると、担当者と実施時点を決めやすくなります。

2026年9月21日時点で確認した[WCAG 2.2 達成基準2.1.1の解説](https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html)は、移動経路そのものに依存する入力が本質的に必要な場合を除き、コンテンツのすべての機能をキーボードインターフェースから操作できることを求めています。個々のキー入力に特定のタイミングを要求しないことも基準に含まれます。「マウスを使わずページを開けた」という事実だけでは足りず、目的の機能を完了できたかを見る根拠になります。

同日確認した[WCAG 2.2 達成基準2.4.7の解説](https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html)は、キーボード操作可能なインターフェースに、キーボードフォーカスの表示が見える操作モードを求めています。解説では、表示されたフォーカスを時間制限で消してはならないとされています。操作できても、どこを操作しているか見失うなら、別の問題として残す必要があります。

入力エラーについて、2026年9月21日時点で確認した[WAIのフォーム通知チュートリアル](https://www.w3.org/WAI/tutorials/forms/notifications/)は、通知を簡潔で明確にし、理解しやすいエラーメッセージと修正方法の簡単な指示を含めるよう案内しています。エラー一覧に対象コントロールのラベル、説明、修正方法、対象へのページ内リンクを含める方法や、入力と説明を `aria-describedby` で関連付ける例も示されています。ここまでが公式情報です。どの業務をどう動かし、誰が合否を決めるかは自社側で定めます。

操作例は、入力フォームを開き、必須項目を埋め、確認して送信し、完了状態へ到達する流れにします。必須項目を空のまま送信するか、画面が定める形式に合わない値で送信する失敗経路も同じ台帳に置きます。架空の利用者像や成功率を足す必要はありません。実際の画面に存在する開始点、操作対象、エラー条件、完了点を記載します。

台帳の一行は「場面｜操作｜期待する観察｜結果｜証跡」とします。「入力開始｜Tabで各入力と送信へ進む｜ポインターを使わず全機能へ到達し、逆方向にも移動できる｜未確認｜操作経路を記録」「送信｜必須項目を空で実行｜修正方法が分かる文言が示され、エラー箇所へ到達できる｜未確認｜読み上げ内容を記録」「修正｜案内後に値を直して再送信｜完了状態までキーボードだけで進める｜未確認｜最終状態を記録」という三行です。各行の結果は実施後に合格、不合格、保留へ更新します。項目名と並べ方は一般原則を受入作業へ落とす提案であり、原典所定の分類や義務ではありません。

合格条件の中心は、各部品の有無よりも、開始から完了まで操作がつながることです。リンク、ボタン、入力、送信、エラーからの復帰のどこか一つでもポインターが必要なら、シナリオ全体は完了していません。移動経路に依存する入力が本質的に必要な機能には公式基準上の例外があります。その機能の性質と代替操作の扱いを確認事項に残し、一般的な表だけで不合格を確定しない運用が必要です。

キーボード欄ではポインターに触れず、開始点からTabとShift+Tabなど画面が受け付けるキーボード操作でたどります。リンク、ボタン、入力、送信を実行し、エラーを発生させ、修正して完了まで戻れるかを記録します。達成基準2.1.1の一般原則を操作台帳へ落とした確認方法であり、W3C所定の試験手順ではありません。

フォーカス欄ではキーボード欄と同じ順序をたどり、「現在位置の表示が見える」「次の対象へ移るまで見え続ける」「送信による画面更新やエラー表示の後も位置を見失わない」を観察します。操作の成立とフォーカスの視認を別欄に記録すれば、「Enterで送信できたから合格」という早合点を防げます。この確認方法も達成基準2.4.7とキーボード操作の原則に基づく実務提案で、原典所定の分類や義務ではありません。

迷いやすいのは、フォーカスが一瞬見えた後に消える場合です。公式解説はフォーカス表示を時間制限で消してはならないとしているため、次の操作まで表示を追います。録画の一場面だけでは判断できません。装飾の好みは不合格理由へ広げず、観察した対象と状態変化を台帳に書き、基準に照らした結果とデザイン上の改善提案を分けます。

エラー確認では、意図的に未入力または画面が定める形式に合わない状態で送信します。修正方法が分かる文言、エラー箇所への到達、入力と個別説明の関連付け、動的に現れたメッセージの実際の読み上げを観察します。赤い枠やエラー文の表示だけでは合格にしません。WAIチュートリアルの一般原則に基づく受入例であり、原典所定の分類や義務ではありません。

同チュートリアルは、フォームより前のページ上部へエラー一覧を置き、各項目から対象コントロールへ移れる方法を示しています。動的に一覧を追加するときは、支援技術へ変更を知らせるためコンテナへ `role=alert` を設定する例もあります。また、`aria-live` を持つライブリージョンについて、`polite` は現在の読み上げを中断せず、`assertive` は現在のタスクを中断して次のフォーカス要素より先に伝える例が説明されています。属性の有無を調べた後、対象とする支援技術で、必要な時点に意図した内容が読まれるところまで操作結果に残します。

送信後に最初のエラー入力へフォーカスを移す方法もチュートリアルにあります。ただし、便利な実装例という位置づけです。エラー一覧から対象へ移る設計と、最初の入力へ移す設計のどちらを採るか確認し、その流れで修正まで到達できるかを判定します。特定の実装例を全画面の必須要件へ読み替えないことが、自社の受入条件を過不足なく保つ境界になります。

実施前に固定するのは、対象画面、開始状態、完了状態、エラーを起こす入力、確認する操作経路、使用する支援技術、担当者、結果の保存先です。ブラウザーや支援技術は、自社が受け入れ対象とする組み合わせを明記します。今回の出典は推奨製品や網羅すべき組み合わせ数を定めていないため、製品名や数を根拠なく受入条件へ足すことはできません。

判定には「合格」「不合格」に加え、前提不足を表す「保留」を用意します。読み上げが想定と異なっても、支援技術の対象環境が未定なら実装不良とは断定できません。対象環境を決め、再現操作と実際に読み上げられた内容を残してから判断します。「保留」は公式規格の判定区分ではなく、一般原則に基づく自社運用上の提案です。

AIへ修正を依頼するときは、台帳の不合格行をそのまま完了条件に使います。「アクセシビリティを改善する」という抽象語を、場面、操作、観察結果、届かなかった完了点へ置き換えて渡します。機密情報や操作権限を含むAI利用の境界は、Claude Codeのセキュリティ｜法人導入前に決める権限とデータ管理の観点と合わせ、操作受入とは別の管理項目として扱います。

公開判断では、キーボードだけで開始から完了まで進めたか、その間のフォーカスを見失わなかったか、意図的な入力エラーを支援技術で理解して修正できたかを、同じシナリオの記録で照合します。どれか一つの欄が未確認なら、スクリーンショットが一致していても操作受入は完了していません。

一般的なチェックリストを埋めても、対象業務の開始点、失敗条件、復帰、完了点が台帳につながっていなければ受入は未完了です。AIのアクセシビリティを確認する条件は、実装者がAIか人かという区別にありません。利用者の操作が途切れないことを人が再現し、根拠と結果を説明できた時点で、操作受入を完了できます。