フォームのラベル

「Email」という語の隣にあるテキストボックスは、label 要素と結びつけるまではラベルが付いていません。それまでは、スクリーンリーダーは「編集テキスト」としか言わないかもしれません。

どの入力欄にも名前が必要

フォーカスがフォームの入力欄に来ると、スクリーンリーダーはそのラベル、種類、状態を「Email、編集テキスト、必須」のように読み上げます。ラベルは、入力欄と結びつけた label 要素から来ます。結びつけ方は2つあります。input に id を、label にそれと同じ値の for を付けるか、input を label の中に入れるかです。どちらの方法でも、ラベルのテキストをクリックすると入力欄にフォーカスが移るので、小さなチェックボックスやラジオボタンがずっと押しやすくなります。

<label for="email">Email</label>
<input id="email" type="email" autocomplete="email">

<label>
  <input type="checkbox" name="news"> Send me the weekly menu
</label>

WCAG 2.2のレベルAの達成基準3.3.2「ラベル又は説明」は、コンテンツが利用者の入力を必要とするときには必ずラベルか説明を求めます。また、1.3.1「情報及び関係性」は、ラベルと入力欄の結びつきが画面の上だけでなくコードの中にあることを求めます。たまたま input の上にある段落は、見た目で近いだけです。その2つがひと組だと支援技術に伝えるものは何もありません。

プレースホルダーはラベルではない

placeholder 属性は、空の入力欄の中に灰色のヒントのテキストを表示します。ラベルの代わりに使いたくなりますし、多くの登録フォームがそうしています。困るのは、入力を始めたとたんに消えてしまうので、その欄が何のためのものだったか確かめられないことです。それに、ふつうは前のユニットのコントラストのルールに不合格になるほど薄い色です。見えるラベルを使い、必要なら例の値を示すプレースホルダーもあわせて使いましょう。

グループ、目的、エラー

ラジオボタンや関連するチェックボックスにも、グループのラベルが必要です。fieldset で囲み、その legend に質問を書きます。すると、スクリーンリーダーは「Small、ラジオボタン、3個中1個目」の前に「Size、グループ」と言います。個人情報には autocomplete 属性を使います。name、email、tel、new-password、one-time-code のようなHTML標準の名前で、その欄が何のためのものかをブラウザーに伝えます。レベルAAの達成基準1.3.5「入力目的の特定」がまさにこれを求めています。ブラウザーが欄を自動で入力できるようになり、ツールによっては欄の隣に見慣れたアイコンを表示できるからです。

何かがうまくいかなかったときは、言葉でそう伝えます。達成基準3.3.1「エラーの特定」は、入力エラーを枠線を赤くするだけでなく、テキストで特定して利用者に説明することを求めます。WCAG 2.2は3.3.7「冗長な入力」も加えました。同じ手続きの中ですでに入力した情報は、2回入力させるのではなく、自動で入力しなおすか、選べるようにします。また、レベルAAの3.3.8「アクセシブルな認証（最低限）」は、助けがない限り、ログインの手順が何かを覚えたり書き写したりすることにたよってはならないとしています。パスワードマネージャーに入力させることや、貼り付けを許すことは、どちらもその助けに当たります。

始める前に、必要なことを伝える

説明は、失敗した後のエラーメッセージではなく、それが説明する入力欄の前に置きます。パスワードが15文字以上必要なら、ラベルの隣にそう書きます。必須の欄は、たとえば「required」という言葉でラベルのテキストに示し、required 属性も付けてブラウザーにも伝えさせます。エラーメッセージが出るときは、その入力欄の隣に置き、メッセージの id を指す aria-describedby で2つを結びつけます。すると、入力欄にフォーカスが来たときにスクリーンリーダーがメッセージを読みます。最後に、問題のある最初の入力欄か、上部のエラーの一覧にフォーカスを移します。そうすれば、キーボードの利用者が長いフォームのいちばん下で何が起きたのかと取り残されずに済みます。