作成するフォームは人間のためです。 ユーザーはそれぞれ異なるデバイスを使用します。 マウス、タッチデバイス、キーボード、目の動きで制御されるデバイスを使用することがあります。スクリーン リーダーを使用するもの、小さな画面を使用するもの、テキスト拡大ソフトウェアを使用するものもあります。 すべてのユーザーがフォームの使用を希望しています。すべてのユーザーがフォームにアクセスして使用できるようにする方法をご覧ください。
フォーム項目の目的をユーザーが理解できるようにする
さまざまなフォーム コントロールから選択できます。
それぞれの共通点は何でしょうか。
すべてのフォーム コントロールに <label> 要素が関連付けられている必要があります。<label> 要素は、フォーム コントロールの目的を記述します。<label> テキストはフォーム コントロールと視覚的に関連付けられ、スクリーン リーダーによって読み上げられます。
また、<label> をタップまたはクリックすると、関連するフォーム コントロールがフォーカスされ、ターゲットが大きくなります。
有意な HTML を使用して組み込みのブラウザ機能にアクセスする
理論上は、<div> 要素のみを使用してフォームを作成できます。ネイティブの <form> のように表示することもできます。
非セマンティック要素の使用にはどのような問題がありますか。
組み込みのフォーム要素には、多くの組み込み機能があります。例を見てみましょう。
視覚的には、<input>（この例の最初の要素）と <div> は同じように見えます。<div> には contenteditable 属性があるため、両方にテキストを挿入することもできます。ただし、適切な <input> 要素を使用することと、<input> のような <div> を使用することの間には、多くの違いがあります。
スクリーン リーダーのユーザーが、<div> を入力要素として認識せず、フォームに入力できない。スクリーン リーダーのユーザーには「名前」としか聞こえません。この要素がテキストを追加するためのフォーム コントロールであることはわかりません。
<div>Name</div> をクリックしても、それに伴う <div> はフォーカスされませんが、<label> と <input> は for 属性と id 属性を使用して接続されます。
フォームを送信した後、<div> に入力されたデータはリクエストに含まれません。JavaScript でデータをアタッチすることもできますが、デフォルトでは <input> がそれを行います。
組み込みのフォーム要素には、他の機能もあります。たとえば、適切なフォーム要素と正しい inputmode または type を使用すれば、画面キーボードに適切な文字が表示されます。<div> で inputmode 属性を使用することはできません。
想定されるデータ形式をユーザーに認識してもらう
フォーム コントロールにはさまざまな検証ルールを定義できます。たとえば、フォームの項目に常に 8 文字以上含める必要がある場合などです。
minlength 属性を使用して、ブラウザに対する検証ルールを示します。確認ルールについてユーザーにも知らせるには、どうすればよいですか。ユーザーに伝えましょう。
目的のフォーマットに関する情報をフォーム コントロールの直下に追加します。
アシスト デバイスであることを明確にするため、フォーム コントロールで aria-describedby 属性を使用し、同じ値のエラー メッセージで id を使用して両方を接続します。
フォーム コントロールのエラー メッセージをユーザーが見つけられるようにする
検証に関する前のモジュールで、データエントリが無効な場合にエラー メッセージを表示する方法を学習しました。
<label for="name">Name</label>
<input type="text" name="name" id="name" required>
たとえば、フィールドに required 属性があり、無効なデータが入力された場合、ブラウザではフォームの送信時にフォーム コントロールの横にエラー メッセージが表示されます。また、スクリーン リーダーはエラー メッセージを読み上げます。
独自のエラー メッセージを定義することもできます。
この例では、エラー メッセージをフォーム コントロールに接続するため、さらに変更が必要です。
簡単な方法は、エラー メッセージ要素の id と一致するフォーム コントロールで aria-describedby 属性を使用することです。その後、エラー メッセージに対して aria-live="assertive" を使用します。ARIA のライブ リージョンでは、エラーが表示されると同時にスクリーン リーダーのユーザーにエラーが通知されます。
複数のフィールドを含むフォームの場合、この方法には問題があります。これは、複数のエラーが発生した場合に、通常 aria-live が最初のエラーしか通知しないということです。同じアクションに関する複数の aria-live のお知らせに関する記事で説明されているように、すべてのエラーを連結して 1 つのメッセージを作成できます。別の方法として、エラーがあることを通知し、フィールドがフォーカスされたときに個々のエラーを通知することもできます。
ユーザーがエラーを認識できるようにする
設計者は、:invalid 疑似クラスを使用して無効な状態を赤色にすることがあります。ただし、エラーや成功を伝える場合は、色のみに頼らないでください。赤 - 緑が見えない人は、緑と赤の境界線がほぼ同じになります。メッセージがエラーに関連しているかどうかを確認することはできません。
色に加えてアイコンを使用するか、エラー メッセージの先頭にエラータイプを付けます。
<span class="error">
<strong>Error:</strong>Please use at least eight characters.
</span>
ユーザーがフォームを操作しやすくする
CSS を使用して、フォーム コントロールの表示順序を変更できます。 画面の表示順序とキーボード ナビゲーション（DOM 順序）のずれは、スクリーン リーダーとキーボードのユーザーにとって問題となります。
詳しくは、ページの表示順序を DOM 順序に合わせるをご覧ください。
現在フォーカスされているフォーム コントロールをユーザーが確認できるようにする
キーボードを使用してこちらのフォームに移動してください。フォーム コントロールがアクティブになると、スタイルが変わったことに気づきましたか？
これがデフォルトのフォーカス スタイルです。
これは :focus CSS 疑似クラスでオーバーライドできます。:focus 内でどのスタイルを使用するにしても、常にデフォルト状態とフォーカス状態の視覚的な違いを認識できるようにしてください。
詳しくは、フォーカス インジケーターの設計をご覧ください。
フォームが使用可能であることを確認する
さまざまなデバイスでフォームに記入することで、多くの一般的な問題を特定できます。キーボードのみを使用するか、スクリーン リーダー（Windows では NVDA、Mac では VoiceOver など）を使用するか、ページを 200% にズームします。フォームは必ずさまざまなプラットフォーム（特に、毎日使用しないデバイスや設定）でテストしてください。どなたかはスクリーンリーダーか テキスト拡大ソフトを使っているかフォームへの記入を依頼します。 ユーザー補助に関するレビューは素晴らしく、実際のユーザーでテストするとさらに効果的です。
詳しくは、ユーザー補助機能の審査の実施と実際のユーザーでテストする方法をご覧ください。