サイトアイコン IT & ライフハックブログ｜学びと実践のためのアイデア集

フォームはなぜ使いにくくなるのか｜WCAG 2.2で押さえる入力支援とエラー設計の基本

greeden
monitor displaying error text

Photo by Pixabay on Pexels.com

フォームはなぜ使いにくくなるのか｜WCAG 2.2で押さえる入力支援とエラー設計の基本

Webアクセシビリティの話題になると、画像の代替テキストや色のコントラストに意識が向きやすいものですけれど、実務の現場で特に大きな差が出やすいのは、実はフォームです。問い合わせ、資料請求、会員登録、採用応募、セミナー申込、決済、各種申請。Webサイトにおいてフォームは、利用者が情報を見るだけでなく、行動へ移る重要な入口です。にもかかわらず、現実には「入力しづらい」「エラーがわかりにくい」「どこを直せばよいのかわからない」といった理由で、途中離脱が起こりやすい場所でもあります。第3回では、フォームはなぜ使いにくくなるのかを整理しながら、WCAG 2.2の考え方に沿って、入力支援とエラー設計の基本を実務目線で読み解いてまいります。

この記事でわかること

  • フォームで離脱や混乱が起きやすい理由
  • WCAG 2.2でフォームに関わる主な達成基準
  • ラベル、説明、必須表示、エラーメッセージの考え方
  • 実務で起きやすい“惜しい設計”と改善の方向
  • UUUウェブアクセシビリティサービスとフォーム改善の役割分担

フォームが使いにくくなる理由は、単に入力項目が多いからだけではありません。利用者がつまずくのは、「何を入力すればよいかが見えにくい」「入力ミスに気づけない」「修正方法がわからない」「やり直しの負担が大きい」といった、情報の伝え方と操作の導き方に問題がある場合がとても多いのです。たとえば、ラベルが曖昧で入力内容を判断しにくい、必須項目が色だけで示されている、入力例がプレースホルダーだけに頼っていて入力開始と同時に消えてしまう、エラーが画面上部にまとめて出るだけで該当箇所との対応がわかりにくい、確認画面で戻ると入力内容が消える。このような設計は、障害のある方に限らず、多くの利用者にとって負担になります。つまりフォーム改善は、アクセシビリティ対応であると同時に、成果につながるUI改善でもあるのです。

WCAG 2.2では、フォームに関わる観点として、入力支援の項目がとても重要です。特に押さえておきたいのは、3.3.1「エラーの特定」、3.3.2「ラベル又は説明」、3.3.3「エラー修正の提案」、3.3.4「エラー回避（法的、金融及びデータ）」、3.3.7「Redundant Entry」、3.3.8「Accessible Authentication (Minimum)」です。これらは、利用者が正しく入力できるように助けること、エラーが起きたときに内容と修正方法がわかること、同じ情報を何度も入力させないこと、認証で過度な負担をかけないことなどを求めています。少し難しく見えるかもしれませんが、要するに「利用者に無駄な迷いと負担を与えないフォームにする」という考え方に集約できます。

まず最初に見直したいのは、ラベルの付け方です。フォームのラベルは、単に項目名が近くに書いてあればよいわけではありません。その入力欄が何のためのものかを、誰にでも誤解なく伝える必要があります。たとえば「名前」だけでは、氏名全体なのか、姓のみなのか、ニックネームでもよいのかが曖昧になることがあります。「会社名」も、法人名なのか部署名まで含むのかで迷いが生まれます。「電話番号」についても、ハイフンの有無や固定電話・携帯電話の可否がわからなければ、利用者は一度立ち止まってしまいます。W3Cのフォームチュートリアルでも、ラベルはフォーム部品の目的を説明し、適切に関連付けられている必要があると示されています。見た目の近さだけに頼るのではなく、HTML上でもラベルと入力欄を正しく関連付けることが大切です。

ここで実務上とても多いのが、プレースホルダーをラベル代わりに使ってしまうケースです。たとえば入力欄の中に「メールアドレス」と薄く表示し、それ以外にはラベルを置かない設計です。見た目はすっきりしますけれど、入力を始めると表示が消えてしまうため、何を入力していた欄なのかがわかりにくくなります。コントラストが低く読みづらいことも多く、支援技術との相性の面でも注意が必要です。プレースホルダーは補助的な例示として使うなら有効ですが、ラベルそのものの代わりにはなりません。フォームをすっきり見せたい気持ちは理解できますが、情報を減らしすぎると、結局は入力しにくくなってしまいます。

次に重要なのが、説明文の出し方です。WCAG 2.2の「ラベル又は説明」は、入力が必要な場面で、利用者が何をどう入力すればよいかを理解できるようにすることを求めています。ここで大切なのは、説明を増やしすぎることではなく、必要な情報を必要な場所で示すことです。たとえば、パスワード欄なら「半角英数字8文字以上」のように条件を先に示す、電話番号欄なら「ハイフンなしで入力」のように形式をあらかじめ伝える、郵便番号から住所を自動入力する機能があるなら、その使い方を近くに書く、といった工夫です。説明は、エラーが出てから伝えるのでは遅い場合があります。利用者が迷いそうな点は、入力前にわかるようにしておくことが、結果としてエラーの減少につながります。

必須項目の伝え方も、とても大切です。多くのフォームで見かけるのが、必須項目を赤色だけで示す方法です。しかし、色だけの違いでは情報が十分に伝わらない場合があります。WCAGの考え方でも、情報や指示を色だけに依存しないことは基本です。そのため、「必須」とテキストで明示する、凡例を用意する、スクリーンリーダーでも伝わるよう実装するなどの配慮が必要になります。さらに、必須と任意が混在する場合には、利用者が一目で判断しやすいルールにそろえることも重要です。たとえば、すべての項目に「必須」「任意」を付ける、または「任意」を省略して必須のみ明示するなど、サイト全体で表記方針を統一すると、迷いが減ります。

フォームの使いにくさが最も表面化しやすいのは、エラー発生時です。W3Cの解説では、送信に失敗した際にフォームを再表示するだけでは不十分で、どこに問題があり、何が誤っていたのかを利用者が認識できる必要があるとされています。これは実務でもまったくその通りで、よくない例として「入力内容をご確認ください」とだけ表示するケースがあります。このメッセージだけでは、どの項目が誤りなのか、未入力なのか、形式が違うのか、利用者には判断できません。よいエラーメッセージは、少なくとも三つの要素を持っています。第一に、エラーが起きた項目がわかること。第二に、何が問題なのかが具体的であること。第三に、どう直せばよいかが伝わることです。

たとえば、「電話番号を入力してください」なら未入力が明確ですし、「メールアドレスの形式が正しくありません。例: sample@example.jp」のように示せば修正方法も伝わります。一方で、「不正な値です」「入力エラーです」といった抽象的な表現では、利用者はまた試行錯誤を繰り返すことになります。W3Cのフォーム通知に関するガイダンスでも、エラー一覧には対応するラベルへの参照、簡潔でわかりやすい説明、修正方法の案内、該当項目へ移動しやすくする工夫が望ましいとされています。つまり、エラー表示は“叱る表示”ではなく、“再開を助ける案内”として設計することが大切なのです。

実務でよくある悩みとして、「リアルタイムバリデーションはどこまで入れるべきか」という論点もあります。入力中にすぐエラーを出す設計は便利に見えますが、タイミングを誤ると、まだ入力途中なのに赤字が出続けてかえって焦らせてしまうことがあります。特にメールアドレスや電話番号のように、最後まで入力して初めて形式が整う項目では、文字を打つたびに警告を出すのは親切とは限りません。そのため、入力完了後に判定する、フォーカスが外れたタイミングで伝える、あるいは送信時にまとめてわかりやすく示すなど、項目の性質に応じた設計が必要です。大切なのは、エラーを早く見せることそのものではなく、利用者の思考を邪魔せず、修正しやすくすることです。

確認画面や再入力の扱いも、フォームのアクセシビリティに深く関わります。WCAG 2.2で追加された3.3.7「Redundant Entry」は、同じプロセスの中で、一度入力した情報を原則として繰り返し入力させないことを求めています。たとえば、申込フォームで入力した住所や氏名を、確認段階や別ステップで再度すべて打ち込ませる設計は、利用者に大きな負担をかけます。入力ミスも増えますし、認知的な負担も高まります。実務では、入力内容の引き継ぎ、自動補完、確認画面からの戻りやすさ、修正しやすさを見直すことが大切です。フォームは“慎重に入力させること”が目的ではなく、“必要な内容を正しく完了できること”が目的だという視点を忘れないようにしたいところです。

また、認証を伴うフォームでは、3.3.8「Accessible Authentication (Minimum)」の視点も欠かせません。ログインや会員登録の場面で、利用者に過度な記憶や認知負荷を求める設計は、大きな障壁になります。たとえば、コピー＆ペーストを禁止する、パスワードマネージャーの利用を妨げる、解きにくい画像認証だけを必須にする、複雑なパズル型CAPTCHAに頼る、といった方法です。もちろんセキュリティは重要ですが、使えない認証は結果として多くの利用者を排除してしまいます。安全性と利用しやすさの両立を考え、認証方式や補助機能の扱いを見直すことも、これからのフォーム設計では重要になります。

ここで、実務者にとってわかりやすいように、よくある“惜しいフォーム”の例を整理してみます。第一に、見た目は整っているのにラベルが曖昧なフォームです。第二に、必須や形式条件の説明が不足しているフォームです。第三に、エラーメッセージが抽象的で、修正箇所が特定しにくいフォームです。第四に、送信エラー後に入力内容が消えてしまうフォームです。第五に、スマートフォンでタップしづらく、チェックボックスや小さなボタンの操作が難しいフォームです。第六に、確認画面や複数ステップで同じ情報を何度も入れさせるフォームです。これらはどれも、特別に高度なシステムでなくても起こりやすい問題ですし、少しの設計見直しで改善できることも少なくありません。

たとえば資料請求フォームを例にすると、改善前は「お名前」「メール」「会社」「お問い合わせ内容」とだけ並び、必須は赤い印だけ、メール欄の形式説明なし、送信後に「エラーがあります」とだけ表示される状態かもしれません。改善後は、「氏名（必須）」「メールアドレス（必須）」「会社名（任意）」のように役割が明確になり、メールアドレス欄には入力例を補足し、未入力時には「メールアドレスを入力してください」、形式エラー時には「メールアドレスの形式が正しくありません。例: sample@example.jp」と表示し、エラー一覧から該当項目へ移動できるようにします。確認画面から戻っても入力内容は保持され、スマートフォンでもボタンや選択肢が押しやすいサイズになっている。こうした違いは、一つひとつは小さく見えても、完了率や安心感に大きく影響します。

では、UUUウェブアクセシビリティサービスとの親和性はどう考えればよいのでしょうか。UUUのように、文字サイズ変更、コントラスト調整、行間や文字間隔の調整、読み上げ、翻訳、ふりがな表示などの閲覧支援機能を提供するサービスは、フォーム周辺の理解しやすさや見やすさを補助する面で価値があります。たとえば、説明文や注意書きが読みやすくなる、視認性が上がる、利用者が自分に合った閲覧環境を選びやすくなる、といった点では相性がよいでしょう。

一方で、フォームそのもののアクセシビリティは、閲覧補助だけでは十分には整いません。ラベルの適切な関連付け、エラー文言の具体性、必須表示の方法、送信後のエラー通知、再入力の削減、認証の設計といった部分は、元のHTMLやシステム、UI設計を見直す必要があります。つまり、UUUのようなサービスは“見やすく使いやすくするための支援”として親和性が高い一方、フォーム設計そのものの品質は、やはり作り手側が丁寧に整えなければなりません。この役割分担を理解しておくと、ツール導入への期待を適切に持ちながら、本質的な改善にも目を向けやすくなります。

フォーム改善は、専門家だけの仕事ではありません。広報担当者であれば、案内文や説明文をわかりやすく整えることができます。Web担当者であれば、必須項目やエラー文言のルールを統一できます。ディレクターであれば、要件定義の段階で「入力内容は保持されるか」「エラーは具体的か」「スマートフォンで押しやすいか」といった観点を組み込めます。エンジニアであれば、ラベル関連付けや通知方法、フォーカス移動、認証の扱いを実装面で支えられます。つまりフォームのアクセシビリティは、一人の専門家が最後にチェックして終わるものではなく、企画、文言設計、UI設計、実装、運用のすべてに関わるテーマなのです。

第3回のまとめです。フォームが使いにくくなる原因は、項目数の多さだけではなく、ラベルの曖昧さ、説明不足、必須表示の不親切さ、エラー設計の弱さ、再入力の多さ、認証時の負担といった、細かな配慮の不足にあります。WCAG 2.2は、こうした問題に対して、ラベルや説明、エラーの特定、修正提案、再入力の削減、認証のしやすさといった観点から、利用者を助けるための考え方を示しています。フォームは、サイトの成果に直結する重要な接点だからこそ、見た目だけでなく、完了しやすさまで含めて設計することが大切です。次回は、キーボード操作とフォーカス表示をテーマに、見えにくい使いにくさをどう減らすかを具体的に見てまいります。

参考リンク

モバイルバージョンを終了