作成するフォームはユーザーを対象としています。 ユーザーはさまざまなデバイスを使用します。 マウス、タッチデバイス、キーボードなどを 目の動きで制御される装置です。 スクリーン リーダーを使用する人、小さい画面を使用する人、テキスト拡大ソフトウェアを使用する人などさまざまです。 全員がフォームを使用したいと考えています。フォームを誰でもアクセスできて使えるようにする方法を学びます。
ユーザーがフォーム項目の目的を理解できるようにする
さまざまなフォーム コントロールから選択できます。
それらすべてに共通しているものは何ですか？
すべてのフォーム コントロールに <label> 要素が関連付けられている必要があります。
<label> 要素は、フォーム コントロールの目的を記述します。
<label> テキストはフォーム コントロールと視覚的に関連付けられ、スクリーン リーダーによって読み上げられます。
また、<label> をタップまたはクリックすると、関連するフォーム コントロールがフォーカスされます。
標的を拡大しています
わかりやすい HTML を使用して、組み込みのブラウザ機能にアクセスする
理論上は、<div> 要素のみを使用してフォームを作成できます。
ネイティブの <form> のように表示することもできます。
どのような問題がありますか？
非セマンティックな要素でしょうか。
組み込みのフォーム要素には、多くの組み込み機能が用意されています。例を見てみましょう。
視覚的には、<input>（この例の最初のもの）と <div> は同じに見えます。
<div> にはタグがあるため、両方にテキストを挿入することもできます。
contenteditable 属性。
ただし、適切な <input> 要素を使用することと <div> を使用することの間には、多くの違いがあります。
<input> のように表示されます。
スクリーン リーダーのユーザーが <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 属性があり、無効なデータが入力された場合、ブラウザには
フォームの送信時に、フォーム コントロールの横にエラー メッセージが表示されます。スクリーン リーダーもエラー メッセージを読み上げます。
独自のエラー メッセージを定義することもできます。
この例では、エラー メッセージをフォーム コントロールに接続するために、さらに変更が必要です。
シンプルなアプローチは、aria-describedby を使用することです。
エラー メッセージ要素の id と一致するフォーム コントロールの属性です。
次に、aria-live="assertive" を使用してエラー メッセージを確認します。
ARIA のライブリージョンでは、エラーが表示されたときにスクリーン リーダーのユーザーにエラーが通知されます。
複数のフィールドがあるフォームでの
この方法の問題は
aria-live は通常、複数のエラーが発生した場合に最初のエラーのみを通知します。
同じアクションに対する複数の aria-live の通知に関するこの記事で説明されているように、すべてのエラーを連結して 1 つのメッセージを作成できます。もう 1 つの方法は、エラーがあることをアナウンスし、フィールドがフォーカスされたときに個々のエラーをアナウンスすることです。
ユーザーがエラーを認識できるようにする
無効な状態を赤色にすることもあります
:invalid 疑似クラスを使用します。
ただし、エラーや成功を伝えるには、
色のみに頼らないでください
赤緑失明の人にとって
緑と赤の枠線はほぼ同じに見えます。
メッセージがエラーに関連しているかどうかを判断できません。
色に加えてアイコンを使用するか、エラー メッセージの先頭にエラータイプを付加します。
<span class="error">
<strong>Error:</strong>Please use at least eight characters.
</span>
フォーム内の移動をサポートする
CSS を使って、フォーム コントロールの視覚的な順序を変更できます。 視覚的な順序とキーボード ナビゲーション（DOM の順序）の乖離 スクリーン リーダーとキーボードのユーザーにとって問題となります。
詳しくは、 ページ上の表示順序は DOM の順序に従います。
現在フォーカスされているフォーム コントロールをユーザーが特定できるようにする
キーボードを使用して移動します
こちらのフォームにご記入ください。
フォーム コントロールが有効になると、そのスタイルが変化したことをご存じですか。
これがデフォルトのフォーカス スタイルです。
代わりに
:focus CSS 疑似クラス。
:focus 内で使用するスタイルが何であれ、
デフォルトの状態とフォーカス状態の視覚的な違いを常に認識できるようにしてください。
詳細: フォーカス インジケーターの設計をご覧ください。
フォームが使用可能であることを確認する
さまざまなデバイスでフォームに入力することで、多くの一般的な問題を特定できます。 キーボードのみを使用し、スクリーン リーダー（ NVDA（Windows） VoiceOver）、 またはページを 200% に拡大します。 フォームは必ずさまざまなプラットフォームでテストし、 毎日使用しないデバイスや設定は特に重要です。 スクリーン リーダーを使用している方はいらっしゃいますか。 文字拡大ソフトウェアを使用している場合は、フォームへの記入を依頼します。 ユーザー補助の審査は有益ですが、実際のユーザーによるテストはさらに効果的です。
詳しくは、 ユーザー補助機能の審査 実際のユーザーでテストする方法について学びます。