入力欄を磨く前に、尋ねることを減らす
問い合わせに必要なのは、返信先と短い質問だけかもしれません。詳しいプロフィールまで求める前に、各項目がなぜ必要で、誰がその情報を使うのかを書き出します。目的がはっきりしない項目は削り、任意の項目にはそう明記しましょう。一般的なメッセージ欄に機微な情報を書かない理由も伝えます。これは編集・設計上の提案であり、現在のスタジオのフォームについて述べたものではありません。
入力欄には、見え続ける名前を付ける
何を入力する欄なのかを示す明確なラベルは、入力中も表示しておきます。プレースホルダーの例は入力すると消えるため、それだけで説明を済ませないようにします。ラベルは近くに置くだけでなく、コード上でも対応する入力欄と関連付ける必要があります。形式の指定があるなら、送信前に分かるよう説明します。氏名を複数の欄に分けるのは、業務上の必要がある場合に限りましょう。
データの種類、用途、キーボードを区別する
HTMLの入力タイプは大まかなデータの種類を、autocompleteのトークンは期待する用途を示します。利用者のメールアドレスにはtype="email"とautocomplete="email"を使い、電話番号にはそれぞれtelを指定します。inputmodeは画面上のキーボードへのヒントであり、入力値を検証する機能ではありません。識別番号や電話番号を、数字を含むからという理由だけでtype="number"にしないこと。先頭のゼロやプラス記号にも意味があります。
自動入力は助けになるが、必ず動くとは限らない
適切なautocompleteの値は、ブラウザーや支援ソフトウェアが、一般的な個人情報の入力欄を識別する助けになります。WCAG達成基準1.3.5の対象は、利用者本人の情報に関する所定の入力目的と、それをサポートする技術です。すべての欄に一律に適用される規則ではありません。実際の自動入力はブラウザー、設定、保存済みデータによって変わります。候補を本人が確認・修正できるようにし、自動入力をきっかけに、気付かないまま送信される設計は避けます。
実際にあり得る入力で確かめる
手入力、貼り付け、自動入力、国際形式の電話番号、長い氏名、ラテン文字以外の文字、空欄の任意項目を試します。スクリーンショットには実在する顧客の連絡先ではなく、テストデータを使いましょう。ラベル、フォーカス、エラー時の説明に加え、修正可能なエラーの後も入力内容が残るかを確認します。静的なコードの確認だけで、実機やブラウザーでの動作確認まで済んだことにはできません。
小さな確認記録を残す
各項目の目的、ラベル、入力タイプ、該当する場合のautocomplete、必須・任意の区別、確認したブラウザーを記録します。入力を助けるフォームのエラー表示と目で追えるキーボードフォーカスも併せて確認しましょう。翻訳や提供サービスの変更後には再点検が必要です。この記録は確認を支えるもので、アクセシビリティを認証したり、問い合わせや売上の増加を約束したりするものではありません。