アクセシビリティ第一歩、labelが超重要な話。~ placeholderじゃダメなの？~
アクセシビリティ観点で必須の<label>要素について、
- その重要性
- なぜ重要なのか。メリット・デメリット
- placeholderじゃダメなのか
などについてまとめます。
labelの重要性
アクセシビリティ観点でlabelはどのくらい重要なのでしょうか？
適合レベル
A
適合レベルとは、アクセシビリティ上の重要度を示す指標のことです。
WCAG 2.1の適合レベルは、レベルA、レベルAA、レベルAAAの3つに分かれています。
その中でレベルAとは、
最低限のレベルであり、達成できていないと、スクリーンリーダーや拡大鏡などの支援技術を用いてもサービスを利用できないことを意味します。
なぜそんなに重要？
label要素があることのメリット
1. 選択が容易になる
ラジオボタンやチェックボックスなどの小さな選択欄の場所を正確にクリック/タップできなくても、隣接するラベルをクリック/タップすることで、選択肢を選ぶことができるようになります。
昨今ではスマートフォンが普及し、マウスより精緻さに欠ける指タッチの操作が増え、うまく選択できない問題があります。 この"fat finger" problemと呼ばれる問題に恩恵をもたらすと言えます。
(ちなみに私の母は文字通り指が太く、小指でスマホ操作をしていたので朗報です👍)
また、チェックボックスやラジオボタン以外の入力要素であっても、ラベルがあると、
そのラベルをクリック/タップすることでその入力欄にフォーカスを当てることができるようなります。
2. 音声読み上げが可能となる
スクリーンリーダーを使いながら[Tab] キ―でフォーカス位置を移動させている場合、
その要素に紐づいたラベルが音声読み上げされ、ユーザーに項目名を伝えることができます、
無いとどうなる？
<label>要素が無いと上記のメリットがなくなるわけですが、その中の具体例を１つ例を紹介します。
例えば、
スクリーンリーダーは、<label>要素に指定されているものを読み上げてることでユーザーにその記入欄の項目名を伝えます。
よってスクリーンリーダーの使用者はlabelがないと、その記入欄に何を記入すれば良いのか分からなくなってしまいます。
placeholder vs label
「labelじゃなくてplaceholderじゃダメですか？？」
これはlabelについて考え始めた時の私の質問です🫠🫠🫠
答えは....↓
ラベルの代わりにプレースホルダーを使わない
「ラベルの代わりにプレースホルダーが使える」という考え方はアウトでした。m(＿ ＿)mm(＿ ＿)mペコペコ
理由を説明していきます！
下記のように、ラベルの代わりにプレースホルダーを使っているケースがいくつかあります。
こうなる場合、外見上スマートに見せたい・限られたスペースを考慮しコンパクトにまとめたい
などの理由があるかと思いますが、多くのデメリットがあります。
デメリット
ユーザーの短期記憶に負荷をかける
プレースホルダーには「6桁以上」などのヒントを書くことが多々あります。
しかし、このヒントをユーザーが忘れたらどうなるでしょうか。
ユーザーは記入中に人に話しかけられたり、違うサイトを確認したり、他の作業に気を取られることがあります。そうでなくても、長いヒントを忘れることは大いにあり得ます。
もし忘れてしまった場合、ユーザーは書いたものを消したり、場合によっては、その入力欄から離れたところをクリックしてプレースホルダーテキストをもう一度出さなければならなくなります。
フォーム送信前に入力内容をチェックできない
ラベルがないと、フォームにざっと目を通した際に、自分の入力値とその項目が合致しているのか分からなくなります。
内容を確認する際には、一度入力値を消してプレースホルダーのテキストを再び表示させ、入力値が説明に一致しているのかを確認しなければなりません。
エラーの解決方法がわからない
エラーが出た際、記入欄の外に説明がないとユーザーは入力値を一度消して、説明を表示させないと何が間違っているのか分かりません。
キーボード操作ユーザーをイライラさせる
Tabキーを使うユーザーは入力欄から次の入力欄に次々に迅速に移動します。
入力欄へのタブ移動前に立ち止まってその入力欄について調べることなどしないため、入力フォーム内にカーソルが入るとプレースホルダーが消える挙動はこのユーザーをイラつかせます。
未入力欄に気づかない
アイトラッキング調査によると、ユーザーの目は空の入力欄にいきます。
プレースホルダーを使用していると、その入力欄は「空」ではなくなり、ユーザーが未入力の欄を見つけるのに余分に時間がかかることになります。最悪の場合、ユーザーがその入力値を見逃すことになります。こうなると、ビジネスを台無しにする大惨事ともなりえます。
自動入力されたデータだと勘違いする
ユーザーがプレースホルダーを自動入力されたデータだと勘違いする恐れがあります。中にはプレースホルダーテキストをデフォルト値だと思い、その入力欄を完全に飛ばす人います。
手動で削除する手間が発生しうる
プレースホルダーが編集可能なテキストとして残っている場合、ユーザーが入力欄にフォーカスを当ててもプレースホルダーが消えません。
その場合、ユーザーは手動でそれを選択肢、削除する必要があり不必要な負荷をかけることになります。
ヒントの解釈が異なる
例えば下記の画像のような入力欄があるとします。
これでは、
「http://」 から入力せよという意味なのか、もしくは「http://」 を省略して入力できるという意味なのかはっきり分かりません。
このようにユーザーを惑わせてしまう場合があります。
アクセシビリティを阻害する
- 見づらい
デフォルトの薄い灰色のプレースホルダーテキストはほとんどの背景に対してコントラストが弱く、視覚障害のあるユーザーにとって、テキストが読みづらくなります。すべてのブラウザのプレースホルダーテキストがCSSを利用して設定できるわけではないので、対応が難しい問題です。
- 負担がさらに重くなる
プレースホルダーはこれまで見てきたように、記憶負荷を増加させたり、入力済の値と間違えたり、混乱を起こします。こうしたことは、認知や運動機能に障がいのあるユーザーにとっては負担がより重くなります。
- プレースホルダーテキストに全くアクセスできない場合がある
視覚に障がいがあるユーザーは、スクリーンリーダーの読み上げによって項目内容を把握するケースがあります。しかし、全てのスクリーンリーダーがプレースホルダーの内容を読み上げてくれるわけではありません。そうなると、プレースホルダーに込めたヒントに全く気付けなくなってしまいます。
結局どうするのが良いの？
一番良いのは、いつでも確認できる明快なラベルを入力フォームの外に置くことです。
一方で、プレースホルダーのみ表示しているサイトも多くあります。アカウント登録済のユーザーに対しての、IDとパスワード入力欄などがありえます。
ユーザーのメンタルモデルとの間で齟齬がなければ、このような実装もアリだと言えます。
ただし！
アクセシビリティ観点では、<label>要素がないと上記で挙げたメリット2が担保できず、ユーザーが何を記入していいか全く分からなくなってしまう可能性が高いです。
プレースホルダーのみ表示したい場合も、CSSなどを使用してあくまでも「外見上はラベルが表示されない」状態にしておくのが良いです。
<label>要素は担保しつつプレースホルダーのみ表示する実装
上記で述べたように、アクセシビリティ観点では<label>要素を担保したいです。
様々な事情でプレースホルダーのみ表示したい時に、<label>要素を保つ実装を別の記事にまとめてますので、必要な際にはご参照ください。
まとめ：必ず<label>要素はつけよう！
labelとplaceholderについて、
技術顧問の @ozu_syo さんが教えてくださった考え方が非常にまとまっていて勉強になったので紹介します。
placeholderは悪ではなく、役に立つ時もあります。
ただし上記で述べたデメリットが生じる場合も多く、そのことを考慮しながら取り入れる必要があります。
そして、<label>要素についてはアクセシビリティ観点で無くてはならないものであり、外見上表示しない場合でも必ずつけるようにしましょう。
参考文献
Discussion