AdvancedGFormsではEFO対策とアクセシビリティや使いやすさ考えたUIデザインを取り入れております。
AdvancedGFormsで行っているEFO機能とフォームで実装すべきアクセシビリティについて紹介していきます。
UIデザイン編
プレースホルダーをラベル替わりにしない
フォームでラベルとしてプレースホルダーを使うのはおすすめしません。プレースホルダーはユーザーが入力を始めると消えてしまうため、使い勝手が悪くなります。
ユーザーは通常、複数の作業を同時に行っており、フォーム入力中に他のタブを開いたり、考え事をしたりすることがよくあります。
そのため、フォームに戻ったときにプレースホルダーがなくなっていると、何を入力すべきか忘れてしまう可能性がありますのでプレースフォルダーとは別にラベルを表示する機能があります。
補足テキストを隠さない
補足テキストをツールチップに隠してしまうデザインがありますが、内容を閲覧するためにはユーザーのアクションを必要とするため、そのひと手間を面倒だと感じてしまい負荷を与えてしまいます。
ですので、なるべく初めから確認が可能な状態へ展開して表示し、スムーズなフォーム入力の理解を促す事がおすすめです。
特に入力条件、例えば、
「電話番号のハイフンは含めないでください」
などの絶対に伝える必要がある情報などは特に隠してはいけません。
ですので、ツールチップではないタイプの補足テキスト表示機能があります。
補足テキストは入力フィールドから離して記載しない
補足テキストを記載するときはなるべく入力フィールドの近くに記載し、情報の関連性が目視でわかるようにします。
離れた位置に記載していますと、どの入力フィールドに対しての説明なのか判断が付かず、混乱を招く原因になってしまいます。
ですので入力フィールドから離れすぎないようなデザインにしていると共に、何らかの理由で表示位置を変更したい場合に備えて、表示位置を変更する事ができるよういくつかのレイアウトパターンを選択可能にしています。
HTMLでの関連付け
見た目上で関連性を紐づけるという話をしていますが、HTMLでのフォームと説明文の関連付けも必要です。
視力にハンデのある方が支援ツールなどを使用してフォームの内容を理解する際に、HTMLレベルでの紐づけが行われていないと支援ツールで適切に理解する事ができなくなってしまいます。
HTMLでの説明文の関連付けについてはAdvancedGFormsのアクセシビリティ（HTMLコード編）の説明の紐づけをご覧ください。
必項という事を省略しない
入力フィールドが必項である事を*などで省略して表記する事がありますが、*という表現になれていないユーザーからすると訳が分かりません。
ですので、省略せずにきちんと「必項」とテキストを添えるべきですので、入力フィールドを必項に設定すると、テキストで「必項」とタグが付くようなデザインにしています。
チェックボックス、ラジオボタンは一列に並べる
チェックボックスやラジオボタンは余白の開け方やデザインによっては、どのラベルがどのチェックに紐づいているのかが理解しずらい部分があります。
さらに人間は横長に続くテキストを見ると認知負荷が高くなりますので、横に短く、縦に長く並べてあげる事で認知負荷を下げる事が可能です。
ですので、チェックボックス・ラジオボタンは一列に並ぶデザインにしています。
見出しを付けて情報をグループ化する
長いフォームの場合、ユーザーに単調で入力が面倒くさそうだと思われ、躊躇してしまう事があります。
その課題を解消するためにはステップにし、順番に入力させる方法がありますが、これは実装に手間がかかります。
最もコスパよくできる対策として見出しを用いて、何についての情報を聞いているのかグループ化する事です。
視点の移動をスムーズになり、フォームの見やすさがかなり向上します。
AdvancedGFormsはグーテンベルクエディタを使用してフォームを構築していきますのでデザインは自由自在です。
プログラムコードを触ることなく、お好きにデフォルトの見出し機能などを組み合わせてフォームを制作する事ができます。
ラベルと入力欄はグループにする
ラベルと入力フィールドを近づけて情報のまとまりをつくり、ラベルと入力フィールドの関連性を視覚的に表現しましょう。
このような工夫がない場合、どの項目がどの入力フィールドに紐づいているのか判断が難しくなり、負荷が高まることで離脱の原因になってしまいますので、視覚的にグループ化するデザインにしてます。
HTMLでの関連付け
見た目上で関連性を紐づけるという話をしていますが、HTMLでのフォームとラベルの関連付けも必要です。
視力にハンデのある方が支援ツールなどを使用してフォームの内容を理解する際に、HTMLレベルでの紐づけが行われていないと支援ツールで適切に理解する事ができなくなってしまいます。
HTMLでのラベルの関連付けについてはAdvancedGFormsのアクセシビリティ（HTMLコード編）のラベルの紐づけをご覧ください。
入力エリアだと簡単にわかるようにする
「洗練された」などをコンセプトにデザインを行うと多くの場合文字が薄く、補足なったり、入力フィールドの存在感も薄めになりがちです。
確かに洗練された高級感を演出する事は可能ですが、入力エリアだという事の認識の難易度があがってしまうというデメリットがあります。
コンバージョンを第一に考えるとフォームは認知負荷を高めるべきではありませんので、しっかりと認識できるデザインにしています。
電話番号や郵便番号の入力欄はハイフンごとに分けない
電話番号や郵便番号はハイフンを含む表現や含まない表現があります。
含む表現を使用する場合、ブロックに応じて入力フィールドを分ける事がありますが、電話番号であれば初めの3桁を入力し、次の4桁目を入力するフィールドをマウスでクリックし、また入力を始めなければいけません。
これはユーザーの入力の手間を増やしてしまい、離脱の原因になってしまいます。
ですので、ハイフン事に分けずに1つのフィールドで入力させるようなデザインにしています。
エラー文は正確に、すぐそばに表示する
入力内容をバリデーションチェック後、もしもエラーがあればユーザーにエラーメッセージのフィードバックを表示しますが、そのエラーメッセージも補足テキストと同じように入力フィールドの近くに表示し、関連性が目視でわかるようにします。
逆によくない例としてはエラー内容をフォームのトップや送信ボタンの上にまとめて記載していまうようなデザインです。
これでは、エラー内容がどの入力項目を指しているのか一目ではわかりずらく、エラーメッセージと入力フィールドが離れいた場合、行ったり来たりと操作負荷が高くなってしまいます。
ですので、エラー表示はエラー内容と入力フィールドの関連をわかりやすくし、どの値をどのように直せばよいのかすぐにわかるようなデザインにしています。
HTMLでの関連付け
こちらも見た目の話であり、視力にハンデのある方など支援ツールを使用している方はエラー内容を目視で認識する事が難しいですので支援ツールに適切にエラーの関連性を伝える必要あり、HTMLレベルでの紐づけが必要となってきます。
HTMLでのエラーメッセージの関連付けについてはAdvancedGFormsのアクセシビリティ（HTMLコード編）のエラー表示と動的に変化するエラーメッセージを通知するをご覧ください。
他のエレメントとの違いをはっきりさせる
このように入力フィールドとボタンの見た目が同じであると操作にまよいがでてしまうので、別のエレメントであり、役割が異なる事を視覚的伝える事が大切ですので、区別できるようなデザインにしています。
フィールドの幅は適切なサイズにする
入力フィールドの幅は入力内容によって適切な幅にしましょう。
長いテキストの入力を求めるのに、フィールドの幅が狭いとテキストが隠れてしまい、入力の難易度が上がってしまいます。
ですので、入力内容に合わせて自動的に可変するような仕組みにしています。
16px以下の文字サイズにしない
テキストの視認性から16px以下のフォントサイズにする事は望ましくありません。
特にiPhoneでは16px以下のフォントサイズの入力フィールドの場合、自動的ズームインし、フォントサイズを大きく見せるという機能が付いており、その自動ズームインがユーザーの操作性を損なわせてしまします。
これは実質、16px以下に設定をするなと言っているようなものです。
ですので、はじめから入力フィールドのフォントサイズは16px以上に設定しています。
スマホ最適化をおこなう
スマホでお問い合わせを行う事もサービスの内容によては多くなるでしょう。
スマホの状態でもユーザーの操作性を損なわないよう、スマホの時はスマホに適したデザインになるよう、レスポンシブデザインにも対応させます。
例えば、デスクトップパソコンの状態では2つ横並びの入力フィールドをスマホでは縦並びにするなどです。
どのようなデバイスで閲覧されても問題なく入力作業が行えるようなデザインにしております。
フォームを制作する際に制作者が気を付けるべき事
選択肢が4つ以上になる場合はセレクトボックスにまとめる
選択肢が4つ以上になる場合はなるべくセレクトボックスなどにまとめ、フォームが縦に長くなってしまう事を避けましょう。
ただ、セレクトボックスにしてしまうと選択肢が隠れてしまうので、隠さない方がよいと判断できる場合や、複数選択を許可する場合はチェックボックスにし、縦に展開して並べたほうがよいです。
ユーザー視線をZの形にしない
ラベルと入力フィールドを以下のような配置にする事でユーザーの目線がZのような動きになります。
Zに動くと無意識のレベルで認知負荷を上げてしまうのでなるべくIの形にし、スムーズな目線の動きにする事が望ましいです。
AdvancedGFormsでは様々なフォームのデザインを制作できるように配置のパターンをいくつか用意しています。
配置のデザインは入力フィールドの内容にもよりますので、知識として頭に置きつつ、総合的に考えて配置を考えましょう。
アクションボタンのテキストは何が起こるのかを明確にする
AdvancedGFormsは送信ボタンのテキストを変更可能です。
自由な文字を入れる事ができるので、どのようなテキストにしようか悩む所ですが、意識したいのは、ボタンをクリックすると何が起こるのかがわかるような表現にする事です。
プレースホルダーで例文を表示する
入力フィールドに何を入力していいかわからない….
というような経験はないでしょうか？
例えば、「お問い合わせ内容を入力」という項目を必項で用意しているフォームをよく見かけますが、そこにどんな文章を書いて送信すればいいのか、とくにその業界の知識があまりなかったりすると困った経験がよくあります。
そのような事が懸念される場所にはプレースホルダーを使用して例文を記載してあげるとユーザーの思考の助けになります。
外部への導線は設けない
離脱の一番の原因になりますので、リンクはあまり載せない方がよいでしょう。
リンク先で気になる記事やコンテンツを見つけてしまい、フォームの入力を途中でやめてしまうという事も珍しくありません。
リンクを張る事をプライバシーポリシーや同意を求める文章などの最低限にとどめておきましょう。
EFO（エントリーフォーム最適化）機能
エラー箇所はわかりやすいデザインにする
エラー箇所がわかりずらいと、ユーザーの入力の手間を増やしてしまい、離脱の原因となってしまいます。
ですので、エラーのある入力フィールドは一目でエラーをわかるようなデザインにする事が望ましです。
AdvancedGFormsではエラーの入力フィールドの背景をエラー色に変更し、アイコンを表示する事で簡単にエラー箇所を認識できるようなデザインにしています。
エラーが発生しても、入力情報はクリアしない
エラーがあると修正する必要があるため、入力内容をクリアするフォームが存在しますが、値は消去してはいけません。
例えばエラーの内容が1文字修正すればクリアできるのに、すべての文字を消してしまっては再入力が面倒ですし、どのような入力内容でエラーが出たのかを確認できず、再びエラーを起こしてしまう可能性も高くなります。
リアルタイムアラートを入力途中で使わない
入力内容のチェックは送信ボタンを押した後に一括で行うパターンと、入力フィールドごとにその場で行うパターンがありますが、使いやすいのは後者の入力フィールドごとにチェックをし、エラー内容をリアルタイムで表示するパターンです。
ですが、リアルタイムと言ってもユーザーが1文字入力する毎、何かアクションを起こす毎に毎度エラー表示やアラートを出してはかえって鬱陶しいだけの存在になってしまします。
そうなるくらいなら前者の方がよっぽど良いです。
ですので、ユーザーの入力が終了し、フォーカスが外れたタイミングなどを見計らってバリデーションチェックをかけリアルタイムアラートを出した方がよいでしょう。
AdvancedGFormsでは入力系はフォーカスが外れたタイミング、選択系は選択した値が変わったタイミングでバリデーションチェックとエラー表示を行うようにしています。
入力成功サイン
エラーデザインだけでなく、成功したときのデザインも考えます。
入力が完了しているのか、未入力なのか、簡単にわかるよう、AdvancedGFormsでは入力が完了したフィールドをsuccessカラーにし、チェックマークが表示されるようなデザインにしています。
全角/半角は自動変換する
入力フィールドの内容によっては半角のみ受け付けたい場合や逆に全角のみ受け付けたいというような事があります。
その場合に、間違った形式で入力してしまった場合に、エラー表示をだすのではなく自動で変換してくれる機能があればユーザーの負荷を解消する事が可能ですので、全角/半角の自動変換機能を搭載しています。
入力モード自動変換
入力する内容によっては数字だけが必要だったり、テキスト入力を行う必要があるフィールドなど様々です。
特にスマホでは、入力のためのキーパットのモードを数字モードやテキストモードに切り替える必要があったり、パソコンの場合も半角/全角のモードを切り替える必要があり、面倒に感じます。
そのような面倒をなくすために、適切な入力モードに自動で切り替えてくれるという機能があり、ユーザーの手間を省きます。
制限事項を明記する
テキストエリアなどは送信容量の関係や、送られてきた文章を読む時間を取れないという理由で、文字数を制限する事があります。
その場合、文字数のカウントをユーザーに強いる事なりますが、テキストエリアに文字数カウント機能を付け、常に現在入力している文章の文字数が何文字なのかを表示してくれていると便利です。
ですので、テキストエリアには文字数カウント機能を搭載し、制限文字数を超えた場合はリアルタイムでエラー表示を出すような機能を持っています。
オートコンプリート機能を利用する
長い住所や、メールアドレスは覚えておくのも入力するのも面倒です。
ユーザーによっては引っ越したばかりで住所を覚えていないというような人もおり、自分の住所を調べるのが面倒だと思い離脱してしまうかもしれません。
そんなときはオートコンプリート機能を利用し、ユーザーの入力を自動保管する事入力の手間を省けます。
オートコンプリート機能とはブラウザが記憶している別のフォームなどで入力したユーザーの個人情報を提案してくれる機能です。
例えば過去に別のフォームで住所を入力していると、オートコンプリート機能を適切に設定しているフォームで同じように住所を入力する際に「もしかして、これを入力したいんじゃないですか？」と前に入力した住所を提案してくれます。
これでユーザーは再度長い住所を入力する事なく、ワンクリックで入力する事が可能となります。
オートコンプリート機能を使用するにはHTMLを適切な形で制作しなければいけませんが、AdvancedGFormsではこれをきちんと設計しています。
郵便番号からの住所自動入力
オートコンプリート機能で記載した理由と同じですが、住所の入力は面倒です。
ですので、郵便番号から検索が可能な機能があると便利です。
AdvancedGFormsでは郵便番号を入力すると自動的に住所を割り出し、入力してくれる機能があります。
もちろん、自動入力をさせたくない場合はその機能を切る事も可能です。
離脱防止ブロックを付ける
フォームの入力途中に間違って他のページのリンクをクリックしてしまったり、スマホですと間違ってスワイプし、前のページに戻ってしまったりし、入力していたデータがすべて消えるという事があります。
入力データがすべて消えてしまった瞬間、よほどお問い合わせのモチベーションが高い人でない限り再入力はしてくれないでしょう。
そのような事故を防ぐため、入力中にページを離れようとした場合にアラートを出す機能を付けるとよいです。
AdvancedGFormsではフォーム入力中に以下のような操作があった場合、本当にページを離れてもよいかの確認アラートが表示され、事故を防ぐ事が可能です。
- ブラウザバック
- リンククリック
- ブックマーククリックによるページ遷移
- タブを閉じる
- ブラウザを閉じる
アクションボタンは必須項目の入力が完了するまではアクティブにしない
送信ボタンなどのアクションボタンは送信に関する条件をすべてクリアするまで非活性だとわかるようなデザインにし、送信に関する条件がクリアしたタイミングで活性とわかるデザインへ変更する事で、ユーザーの理解を助けます。
処理に時間を要する場合にはローディングを使用する
人間は皆、とてもせっかちです。
送信ボタンなどのアクション系の操作をして0.1秒以内になにかのフィードバックがないと不安を覚えます。
ですので、例えば送信ボタンを押した場合はすぐに処理中という事をフィードバックする事が親切です。
また、すぐにフィードバックをがもらえない場合、ユーザーはクリックできなかっただと思い、何度も送信ボタンを押し、二重送信の原因にもなりますので複数回クリックしても一回のみ処理が実行されるような対策も行っております。
