フォームのアクセシビリティについてまとめてみる

フォーム実装時に注意したいアクセシビリティのポイントを、ラベル・エラー通知・placeholderやdisabledの扱いなどを中心に、WCAGの達成基準とあわせて備忘録としてまとめました。

はじめに

フォームはユーザーが入力するための要素であるため、フォームのアクセシビリティを考える必要があります。
また、サイトによってはフォームに問い合わせてもらう、資料請求まで行うことが目的である場合あるため、フォームのアクセシビリティを考えることは重要だと思っています。
全てを網羅してまとめられているわけではありませんが、実装経験や調査を通してわかったことを中心に備忘録としてまとめていこうと思います。

デモサイト

作成したデモサイトはこちらになります。

フォーム実装の時に注意すること

最初に実装時に注意してみておくことを挙げてみます。

• 入力項目にラベルをつける
• 色だけで必須やエラーを表現しない
• 必須の文字が認識できない位置にない
• 入力補完を利用できるものはautocompleteを使う
• 入力要素がフォーカスを受け取れるようにする
• エラーが出たときに支援技術に通知され、適切に読み上げられる
• disabledの使用は避ける
• placeholderを使わない

入力項目にラベルをつける

htmlのセマンティクスを意識して、label要素を使います。
labelのfor属性と入力要素のidも忘れずに設定しましょう。
スクリーンリーダーで使用時、入力要素にフォーカスが当たるとidで紐づけたlabelの内容と一緒に読み上げてくれるので、どの要素を入力しているかがわかるようになります。

1
<!-- 例 -->
2
<label for="name">名前</label>
3
<input type="text" id="name" name="name" />

色だけで必須やエラーを表現しない

色だけで必須やエラーを表現せず、テキストとして情報を伝えるようにします。
テキストでないと、ロービジョンの方は判別できなかったり、スクリーンリーダーユーザが認識できなかったりします。
一般のユーザーにとっても、「赤＝必須」を覚えていなければならず、負担になってしまいます。

1
<!-- 悪い例 -->
2
<p>赤の要素は必須です。</p>
3
<label for="name" style="color: red">名前</label>
4
<input type="text" id="name" name="name" required />

1
<!-- 良い例 -->
2
<label for="name">名前<span>必須</span></label>
3
<input type="text" id="name" name="name" required />

該当するWCAG

必須の文字が認識できない位置にない

必須の文字が、ラベルとあまりにも離れすぎていると、視野狭窄の方が気付けない可能性があります。 ラベルと必須のテキストが離れすぎていたり、両端に配置しするようなレイアウトは避ける方が良いでしょう。

1
<!-- 悪い例 -->
2
<label for="name" style="display: flex; justify-content: space-between;">
3
  <span>名前</span>
4
  <span>必須</span>
5
</label>
6
<input type="text" id="name" name="name" required />

該当するWCAG

調べてみたところ、直接該当しそうな項目はありませんでした。 デザインとの兼ね合いにもなってくるので、現実的に難しそうだなと思いつつ、今回挙げています。 配慮できそうならするくらいの感覚でもいいのかもしれません。

情報源はデジタル庁のブログ記事になります。

入力補完を利用できるものはautocompleteを使う

入力時に「名前」や「住所」「電話番号」といった要素は、他のフォームでも使いまわしているケースが多いです。 また、場合によっては何を入力するべきか瞬時に把握できないこともあります。 autocomplete属性を使うことで、入力補完を利用できるので負担が減ります。また、ユーザーが何を入力するべきか理解する手助けにもなります。 また、autocomplete="off"は入力補完を切ることになるので、毎回入力が異なる補完の効かない項目でのみ使用するようにしましょう。

1
<div>
2
  <label for="name">名前<span>必須</span></label>
3
</div>
4
<input type="text" id="name" name="name" required />

該当するWCAG

入力要素がフォーカスを受け取れるようにする

入力要素がフォーカスが受け取れる・受け取ったことがわかるようにします。 outline: none;はフォーカスインジケータが表示されなくなってしまうので、見直すか代替手段を用意しましょう。

該当するWCAG

エラーが出たときに支援技術に通知され、適切に読み上げられる

今回はライブリージョンを使ってみます。

1
<label for="name">名前<span>必須</span></label>
2
<input
3
  type="text"
4
  id="name"
5
  aria-describedby="name-error"
6
  aria-invalid="true"
7
  autocomplete="name"
8
  required
9
  name="name"
10
/>
11
<!-- ↓以下はバリデーションチェック後に出す -->
12
<div
13
  class="error"
14
  role="alert"
15
  aria-atomic="true"
16
  aria-live="assertive"
17
  id="name-error"
18
>
19
  <span>名前を入力してください</span>
20
</div>

入力要素 aria-describedbyは入力要素にフォーカスが当たった時に、指定した要素を読み上げてくれます。 aria-invalidは入力値が無効であるかどうかを通知します。

エラー本体 class="error"の要素はバリデーションチェック後にエラーがあれば出すようにしてください。
role="alert"はaria-live="assertive"とaria-atomic="true"の複合です。
aria-live="assertive"はユーザーへの通知を即座に行います。

該当するWCAG

disabled属性の使用を避ける

今まで入力エラーや必須項目の入力時には、送信ボタンがdisabled属性を使うのが良いと持っていたのですが、フィードバックや調査しているうちにあまりよくないと言うことがわかってきました。
理由としては、キーボード操作でフォーカスを受け取ることができないためです。また、視認性が悪くロービジョンユーザーが認識できない可能性があることや、「なぜ押せないのか、どうしたら押せるようになるのか」がユーザーにわかりにくいといった問題もあります。
スクリーンリーダーで無効であることは読み上げられるため、適切な場所でdisabledを使うようにしましょう。

該当するWCAG

実際には該当する項目が見当たりませんでした。 達成基準 1.4.3:コントラスト (最低限) (レベル AA) でみれば、ユーザーが操作できないユーザーインターフェースコンポーネントは、コントラスト要件を満たす必要はないとの記載があり、一見問題ないようにも思います。 一方で、一部の記事や書籍には、フォームの送信ボタンにdisabledを使用するのが適切ではないとされているものが多いです。
disabledの仕様上、フォーカスができないようになっているので、無効になっていることがわからないことが主な原因となります。
そのようなケースがあるかはわかりませんが、万が一フォームの送信ボタンにdisabledを使用する場合は、別のテキストとして、必須項目の入力やエラーの解決をしない限り、ボタンが押せるようにならない旨をおく必要がありそうです。

placeholderを使わない

1
<label for="name">名前<span>必須</span></label>
2
<input
3
  type="text"
4
  id="name"
5
  autocomplete="name"
6
  name="name"
7
  placeholder="名前を入力してください"
8
/>

placeholderを使うと、入力欄にそのテキストが出てきます。一見問題ないように見えますが、スクリーンリーダーで読み上げられません。 また、コントラストも良くないことから、説明文はplaceholderを使わず、別のテキストとしておくことが望ましいです。
別テキストとしておく時には、aria-describedbyを使うと入力要素にフォーカスが当たった時に、説明文も一緒に読み上げてくれます。

1
<label for="name">名前<span>必須</span></label>
2
<input
3
  type="text"
4
  id="name"
5
  autocomplete="name"
6
  name="name"
7
  aria-describedby="name-desc"
8
/>
9
<p id="name-desc">名前を入力してください</p>

該当するWCAG

最後に

今回はフォームのアクセシビリティについて、一度自分で整理してまとめてみました。
注意すべき点はここに記した限りではないと思いますが、基本的な方針はまとめられたと思います。

例えば、リアルタイムでエラーを出す時とエラーサマリーを出す時とでは、エラーの通知タイミングや方法が異なるかもしれません。 実際の要件ごとに注意して、実装して行けたらいいなと思います。
今回はここまでとなります。ありがとうございました！

参考

• フォーム | freeeアクセシビリティガイドライン
• 7-2. フォームパーツにアクセシブルネームがある | SmartHR Design System
• インプットテキスト | デジタル庁デザインシステム
• 【HTML】ボタン要素にdisabled属性をつけるのをやめませんか？ | Qiita