フォームの確認は、mouseで一度送信できたことだけで終えません。keyboardだけで入力、選択、送信、error確認、修正、再送まで進めるかを検査します。errorが赤くなっても、どの項目がなぜ誤りで、どう直せばよいかが分からなければ、利用者は手続きを完了できません。
この記事は検査手順の設計です。対象フォームの操作やaccessibility適合試験は実施していません。下記は架空の問い合わせフォームのcaseで、WCAG全体への適合や特定製品の使いやすさを保証するものではありません。
目次
検査する一連の仕事と環境を固定する
URL、画面バージョン、browser/OS、viewport、入力条件、使用する支援技術の有無を記録します。必須入力、任意項目、select、checkbox、添付、modal、送信結果など、実際のフォームにある機能を列挙します。正常入力だけでなく、空欄、不正形式、サーバー側error、通信断も条件にします。
表は横にスクロールできます
| 段階 | keyboardで確認 | error時の確認 |
|---|---|---|
| 到達 | 入力欄へ順に移れる | focusが消えない |
| 入力 | labelと条件が分かる | 必須や形式が伝わる |
| 選択 | 選択・解除・展開ができる | 状態が分かる |
| 送信 | button等を実行できる | 二重送信しない |
| 修正 | 該当fieldへ戻れる | 入力を不必要に失わない |
W3CのKeyboard解説（新しいタブで開く）は、keyboard interfaceで機能を操作できることを説明しています。Tabで順番に動けるだけで、すべての操作が完了できると扱わないようにします。
pointerを使わず、focusと操作を追う
pageの入口からTab、Shift+Tabで移動し、現在位置を見失わないかを確認します。必要な機能へ到達し、標準的な操作で実行できるかを見ます。custom widgetでは、使うcomponentの操作規則を確認し、すべてをTabだけで操作できることを独自の一律条件にしません。
modalを開閉したとき、focusが背景へ抜けたり、閉じた後に戻る先を失ったりしないかを確認します。menu、日付picker、ファイル選択、補足説明等、mouseでは見落としにくい操作も含めます。focus trapと、modal内で意図的にfocusを管理する設計を混同しません。
errorは項目と理由を文章で対応させる
W3CのError Identification解説（新しいタブで開く）は、自動検出した入力errorについて項目を特定し、利用者へtextで説明することを示しています。色やiconだけ、あるいは「入力に誤りがあります」だけで、直す項目が分かると判断しません。
たとえばmail形式のerrorなら、対象fieldと修正に必要な条件を示します。サーバーの内部errorや秘密情報をそのまま表示する必要はありません。業務上公開できる説明と、request ID等で追う運用logを分けます。
WAIのフォーム通知tutorial（新しいタブで開く）も参照し、error一覧とfield、label/説明の関連、必要な通知方法を確認します。screen readerで認識できるかは、実際にその環境で別に検査します。ARIA属性を付けたことだけで読上げ成功とは扱いません。
修正後に、入力を保って再送できるかを見る
errorを一項目直したら、ほかの正しい入力が残るか、error表示が現在の状態へ更新されるかを確認します。表示だけ消えてサーバーで同じerrorになる場合、client/serverのvalidation条件と正規化を照合します。空欄と空白、全角、日付、境界値などは仕様に合わせて確認します。
表は横にスクロールできます
| 架空のcase | 期待すること | 切り分ける層 |
|---|---|---|
| 必須を空にして送信 | 対象と理由が分かる | label・validation・通知 |
| mail形式が不正 | 修正して再送できる | client/server条件 |
| サーバーが拒否 | 入力を保って案内 | 応答とerror表示 |
| 通信が切れる | 結果不明を明示 | 外部作成の照会 |
| 連続操作 | 重複作成を防ぐ | UI制御とサーバー一意性 |
送信中buttonを無効化するだけでは、サーバー側の二重登録対策の代わりになりません。結果を失った再送では、同じ処理IDや状態確認を含む仕組みを検討します。画面の完了messageと、実recordの作成は別の検査です。
発見した問題を再現できる形にする
問題ごとに、開始状態、keyboard操作列、期待、実際のfocus/表示/通知、入力条件、browserを記録します。画像だけでなく、どの項目で操作が止まったかを文章にします。実顧客情報をscreen captureやticketへ残さず、架空dataで再現します。
自動検査はlabelや構造の一部を見つける助けになりますが、実際の順序、理解しやすさ、復帰、業務完了をすべて判断できるとは限りません。静的検査、keyboard試験、必要な支援技術での確認を分けて結果を残します。
修正後は、同じ操作と周辺経路を再確認する
修正したfieldだけでなく、その前後のfocus、正常送信、別error、戻る・閉じる・再送を確認します。CSS変更でfocusを見えなくしたり、error通知を追加して同じ内容を何度も読ませたりしていないかも見ます。
完了記録には、検査したURL/版/環境、通過したcase、未検査の支援技術や機能、残る問題を記載します。一つのフォームのkeyboard・error確認が終わったことと、site全体のWCAG適合は分けて報告します。