コンタクトフォームに必ず付きまとうセキュリティですが、フォームを利用した悪意のある攻撃は大きく分けると以下のつにわけられるかと思います。

• SQLインジェクションやコマンドインジェクションのような別のプログラムを混入させ、実行させるもの
• DoS/DDoSやスパム送信などの大量の処理を実行するもの

AdvancedGFormsではこのような悪意のある攻撃からフォームを守るための対策を十分に行っております。

SQLインジェクションやコマンドインジェクションの対策

SQLインジェクションやコマンドインジェクションはデータベースを使用していたり、PHPなどのサーバーサイドで動くプログラムを使用している際に発生するリスクがあります。

多くのフォームはこちらの図のよう仕組みで動作します。

webサイトからユーザーがお問い合わせ内容を送信すると、一度サーバーを介し、送信内容のデータをチェックしたり、データベースへ保存したり、返信メールを送信したりと様々な処理を行います。

このサーバー側での様々な処理を行う際に悪意のあるプログラムを混入させてしまうリスクがあるわけです。

そのリスクを完璧に排除する事はなかなか難しいでしょう。

これだけIT技術が発展しても不正アクセスや情報漏洩などのインシデントはなくなっておりません。

それは、多くの場合がセキュリティに関するエンジニアの知識不足によるもので、世界的に周知な攻撃手法に対する対策が十分に施されないままサイトを公開してしまっているからなのです。

大手企業ならば大量にお金をかけて高度なセキュリティ対策を行う事が可能ですが、中小企業や小さなweb制作会社などでは十分なセキュリティ対策が難しいというのが現状です。

AdvancedGFormsはGoolgeフォームを使用するので安心

セキュリティに対しての知見を持ったエンジニアを中小企業や小さなweb制作会社などが確保するのは難しいのでなかなか十分なセキュリティ対策を行うのが難しいのが問題でしたが、この問題を根本から解決するにはサーバーサイド部分のセキュリティは大手にお任せすることです。

AdvancedGFormsではそもそもサーバーサイドのプログラムを使用しておりません。

AdvancedGFormsはGoogleフォームを使用しますので、サーバー部分のセキュリティは全てGoogleが保証してくれます。

世界中のスーパーエンジニアが在籍するスパー大企業が提供するフォームですのでセキュリティは完璧です。

DoS/DDoSやスパム送信

サーバー側のセキュリティは安心とはいえ、大量送信を行うDoS/DDoSやスパムの問題は残ります。

ボットを利用して単純に大量のフォームを送信を行いサーバー側の処理を圧迫させるという嫌がらせのような行為や、広告文やURLをお問い合わせ内容に記載し、お礼メールを利用して悪さをする事もあります。

ここでは大半を占める手法として、サンクスメールの送信機能を悪用した攻撃の例を紹介します。

サンクスメールを利用した攻撃

多くのフォームには、お問い合わせがきた際に「お問い合わせありがとうございました」という趣旨のメールを自動で送信する機能が搭載されていますが、この仕組みを悪用したものになります。

例えば、以下のようにする事で攻撃ができてしまいます。

1. フォームのメールアドレス欄に攻撃したい相手のメールアドレスを入力する
2. お問い合わせ内容を記載するテキストエリアに広告のリンクやフィッシングサイトのURLを入力する
3. 送信
4. サンクスメールが1で入力したアドレスに送信される

そして、その後、サンクスメールを送信された相手がそのサンクスメールに記載されている広告やフィッシングサイトのURLをクリックし、何かの損害を被ってしまう。

このような流れで誰かを攻撃するという手法がありますが、その攻撃に加担してしまう点が恐ろしいところです。

このような攻撃はプログラムを使用して機械的に大量に送ります。

ですので、ボットかどうかを判断するためにリキャプチャ対策を行う事が一般的となっております。

AdvancedGFormsのスパム対策

スパム対策として一般的なものはリキャプチャですが、リキャプチャを利用するためにはサーバー側プログラムを使用した認証を行う必要があります。

AdvancedGFormsはサーバー側のプログラムを使用していないので、リキャプチャを使用する事が難しいです。

ですのでAdvancedGFormsではリキャプチャを使用しない別の対策を行っており、以下の2点になります。

1. ハニースポットを用意する
2. 送信先を隠す

ハニースポットの利用

ハニースポットの利用について理解するためにはそもそも、ボットがどのようにして大量にフォームを送信するのかという事を知る必要がります。

ボットから大量にフォーム送信を行う方法として多く採用されているのは存在する入力フィールドを機械的に適当な値で埋める事で送信可能にする方法です。

その方法の手順は以下のような形になります。

1. フォームへアクセスします
2. HTMLを解析し、inputもしくはtextareaタグなど入力を受け付けるHTMLタグを見つけます
3. 2で発見した入力フィールドすべてを適当な値で埋めます
4. submitと記載のあるinputもしくはbuttonタグを見つけます
5. 4で見つけたボタンをクリックします

このような作業をプログラムを使って自動で行います。

ここでの対策のポイントは、ボットが入力フィールドをすべて適当な値で埋める点を逆手に取ることです。

ダミーのinputを用意し、そこに値が存在すれば送信できないような仕組みにする事でボット対策が可能となります。

そのダミーのinputはユーザーからは見えないように透明にしておく。

もしくは、「あなたが人間の場合、こちらにチェックを入れないでください。」というような文言と一緒にチェックボックスを用意します。

もしもフォームを操作しているのが人間ならこの文章を読み、チェックを入れる事はないでしょう。

ですが、ボットの場合、書かれている文字を読み取ってその意図を認識し、チェックするかしないかを判断するような高度な事はなかなか難しいです。

ですので、これに引っ掛かり、スパム送信を防げるという仕組みです。

AdvancedGFormsではこのハニースポットを利用してスパム攻撃対策を行っております。

送信先を隠す

ハニースポットを利用してスパム対策を行っておりますが、ハニースポットを利用する対策は一般的ですので攻撃側も重々承知です。

ですので攻撃手法を工夫し、別の方法を利用する事があります。

別の方法とは、送信先URLを抜き出し、フォームから送信ボタンを押さず、直接送信してしまう方法です。

一般的にフォーム構築する場合はフォーム自体を表示いているサイトと、送信後の処理を行う場所が分かれております。

処理を行う場所のアドレスはHTMLコードに記載しており、HTMLコードを見ると簡単にわかってしまいます。

HTMLコードは誰でも簡単にブラウザから確認する事が可能です。

実際にフォームを構成するHTMLコードを見てみると以下のようにformタグのactionに送信先のURLが記載されている事がわかるかと思います。

<form ... action="https://送信先のURL" ... >

このactionに記載されているURLへ直接データを送信する事でフォームの送信が可能なのです。

ですので、多くの場合は直接送信された場合には処理を行わないというようなセキュリティ対策を行いますが、AdvancedGFormsでは、そもそもactionに送信先のURLを記載しないという形で対策を行っております。

URLを知らなければ送信のしようがありませんので、これはかなり強力な対策と言えます。

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秒以内になにかのフィードバックがないと不安を覚えます。

ですので、例えば送信ボタンを押した場合はすぐに処理中という事をフィードバックする事が親切です。

また、すぐにフィードバックをがもらえない場合、ユーザーはクリックできなかっただと思い、何度も送信ボタンを押し、二重送信の原因にもなりますので複数回クリックしても一回のみ処理が実行されるような対策も行っております。

AdvancedGFormsでは世界規格であるW3Cのwebアクセシビリティと日本規格であるJIS X 8341-3のwebアクセシビリティに従ってフォームのアクセシビリティ要件を満たすよう、セマンティックコーディングを行っております。

タブ遷移自体やフォーカススタイルを無効にしない

マウスを使用する事ができない状態の人や普段からキーボードでほとんどの操作を行っている人などはタブを使用して入力フィールド間を移動したり、ボタンやリンクをエンターキーで操作したりします。

通常inputタグやaタグ、buttonタグにはタブ移動時、フォーカスが当たり、フォーカスがどのアイテムにあたっているのか、現在地を示すために太めのボーダーが表示されます。

webサイトのデザインによっては、このタブ遷移やフォーカス時のスタイルがカッコ悪いからと言って無効する事を見かけますが、そのようなカスタマイズはアクセシビリティの観点からみるとよくないですので（ユーザーの操作を妨げる）AdvancedGFormsでは行っておりません。

ラベルの紐づけ

視覚的に判断すれば、入力エリアの近くにラベルがあればその入力エリアがどんな項目なのか判断する事が可能です。

ですが、支援ツールを使用している方やクローリングボットにはどのラベルとどの入力エリアが紐づいているのかが判断できません。

ですので入力エリアに対してラベルタグを使用し、この2つを連携さることが必要です。

<label for="name">お名前</label>
<input 
  type="text"
  id="name"
/>

[MDN]label

このように、labelタグにはforを、inputタグにはidをセットし、同じ値を入れる事でラベルと入力エリアを紐づけることが可能です。

もしくは以下のようにする事で紐づける事も可能です。

<label>
お名前
<input 
  type="text"
/>
</label>

この場合、forとidの設定は必要ありません。

とわいえ、デザイン上、labelの中に必ずinputを入れるというHTML構造にする事は難しい事が多いでしょう。

ですので、AdvancedGFormsでは、1番目に紹介したforとidを使用した紐づけを行っております。

説明の紐づけ

入力フィールドに何を入力すればいいのか、など、補足説明を表示する事は多くあります。

こちらもラベルの紐づけと同じくどの入力エリアにたいしての補足説明なのかを紐づける必要があります。

aria-describedby属性を使用し、以下のように紐づけます。

<input
  type="text"
  aria-describedby="nameDesc"
/>

<span id="nameDesc">姓と名の間は半角開けてください</span>

[WCAG 2.0]aria-describedby

必須要素

入力エリアが必項だった場合、*印や「必項」というタグをラベルの横に表示する事が一般的ですが、こちらも視覚的に判断するユーザーへのアプローチとなりますので、支援ツールには認識されません。

ですので、以下のようにrequired属性を付ける事でこの入力エリアが必項という頃を伝える事ができます。

<input
  type="text"
  required
/>

さらに、WAI-ARIAにもaria-required属性というものが存在し、W3Cのwebアクセシビリティ項目にもaria-required="true"を付けるとよいと記載されいますので、こちらも追加します。

<input
  type="text"
  required
  aria-required="true"
/>

[WCAG 2.0]aria-required

ラジオボタン・チェックボックスのグループ化

ラジオボタンやチェックボックスなどの複数の選択肢が存在する場合、グループ化し、選択肢のまとまりをそれぞれ明確にする事で支援ツールを使用している方やクローリングボットへ情報の関連性やまとまりを適切に伝えることが可能となります。

グループ化の方法は2つあります。

まず1つ目は以下のようにfieldsetを使用する方法です。

<fieldset>
    <div>すきな食べ物はなんですか？</div>
    <div>
        <input type="radio">
        <label>いちご</label>
    </div>
    <div>
        <input type="radio">
        <label>メロン</label>
    </div>
</fieldset>

[MDN]fieldset

もう1つはrole属性を使用する方法です。

<div role="group">
    <div>すきな食べ物はなんですか？</div>
    <div>
        <input type="radio">
        <label>いちご</label>
    </div>
    <div>
        <input type="radio">
        <label>メロン</label>
    </div>
</div>

[WCAG 2.1]grouping roles

AdvancedGFormsでは、2つ目のrole属性を使用してグループ化をしております。

グループ化したinputに対してそのグループのラベルと、そのグループの説明を紐づける場合は以下のようにaria-describedby属性とaria-labelledby属性を使用して紐づけを行います。

<div>
    <div id="group-label">すきな食べ物はなんですか？</div>
    <div id="describedby">すきな食べ物を必ず1つ選択してください。</div>
    <div
    	aria-describedby="describedby"
		aria-labelledby="group-label"
        role="group"
    >
    </div>
    <div>
        <input type="radio" id="input-item-1">
        <label for="input-item-1">いちご</label>
    </div>
    <div>
        <input type="radio" id="input-item-2">
        <label for="input-item-2">メロン</label>
    </div>
</div>

[WCAG 2.0]aria-labelledby

エラー表示

ユーザーが入力フィールドへ値を入力した後にバリデーションチェックを行いますが、その際、入力値にエラーがあった場合はユーザーへフィードバックを行います。

通常は視覚的にフィールドを赤色表示にしたり、エラーメッセージを表示したりますが、支援ツールにはそのメッセージは伝わりません。

エラーということをツールなどに伝えるにはaria-invalid属性を使用します。

<input stype="text" aria-invalid="true"> // trueの場合はこのフィールドがエラーであることを指します。
<input stype="text" aria-invalid="fasle"> // falseの場合はこのフィールドにエラーはない事を指します。

[WCAG 2.0]aria-invalid

動的に変化するエラーメッセージを通知する

バリデーションチェック後、エラーがあった場合ユーザーにエラー内容を通知する必要がありますが、メッセージ内容の変更を支援ツールなどに通知する必要があります。

組み込みバリデーションチェックを使用する場合は通知設定は必要ありませんが、独自でバリデーションを実装している場合には通知設定が必要です。

通知するにはrole="alert"もしくはaria-live="assertive"をセットします。

この属性の設定は値が変更される前に設定してある必要がりますが、変更の前であればJavaScriptから動的に追加しても問題ありません。

<input type="text">
<p role="alert">ここにエラーメッセージが動的に追加されます</p>

[WCAG 2.0]ARIA role=alert or aria-live=”assertive”

role="alert"とaria-live="assertive"の2つの設定方法がありますが、2つを同時に使用するとiOSで重複して読み上げられてしまうので2つ同時の使用はよくありません。

AdvancedGFormsではrole="alert"を使用しています。

という声も聞こえてきそうですが、マインドセットは本当に大切ですのでどうか少しの時間をください。

このマインドセットを知っているか知っていないかで学習の効率が大きく変わってきます。

マインドセットが大切な理由

正しい努力は報われるが、ただの努力は報われない

これをわかりやすく例えるなら

1. ただの努力とは「九州を目指している。そうだ、自転車で埼玉方向へ全力で走ろう！」
2. 正しい努力とは、「九州行を目指している。飛行機のチケットを取るためにバイトしてお金を貯めよう」

明らかに2の正しい努力の方が先にゴール（九州）に効率的にたどり着きますよね。

これからお伝えするマインドセットはプログラミングを学ぶ上でこのたとえくらいの効率の違いを生みます。

大切なマインドセットとは。概要の解説

マインドセットとは考え方の方向性、行動パターンをまとめたもので、習慣と似たようなものです。

自由だからこそ、はじめの例で出したように

• 自転車で向かうという判断をする人
• 飛行機で向かうためにお金を貯めようと判断をする人

というように考え方の違いによって行動、手段が変わってくるのです。

行動が異なると同じ目標でも、達成スピードとコストが大きく違ってきます。

目標をあっという間に達成する人と、なかなか達成できない人の違いはこれなんですね。

お金持ちになる人はお金持ち特有の考え方や行動パターンがあります。またその逆もありです。

ですので、大切なことは既に目標を達成した人がどのようなマインドセットを持って、どのような考え方、行動パターンをしていたかを知り、それを真似する事が大切です。

「学ぶ」とはもともと「まねぶ」からきているといわれています。

学ぶこと = 真似なんですよね。

まずは先輩の行動をまねることからです。

マインドセットの目次

• なぜプログラミングを学びたいのか、しっかり認識しておこう
• 世の中の99.99%の課題は既存の知識の組み合わせで解決できる
• 学ぶ上で大切なのはやっぱり基礎力・基礎知識
• プログラムを書くトレーニングも大切だが、それ以上に読むトレーニングが大切
• プログラミングは暗記じゃない
• 細かいことはどうでもいい。メンタルモデルを構築しろ
• ラーニングピラミッド理論で効率的な学習方をする

そもそもなぜプログラミングを学びたいのか

あなたはなぜプログラミングを学びたいのでしょうか？

• 今よりお金を稼ぎたい？
• 今より自由な時間が欲しい？
• 一拠点にとどまらず、海外などいろいろな場所に行きたい？
• 単純にコンピュータが好き？

どんな理由であれ、すべて一人一人の大切な理由で、皆少しずつ異なりますが必ず共通するものがあります。

それは、

1. お金
2. 時間

です。

タイムイズマネーというように、この2つは密接につながっております。

そして、時間は今の人類の技術では増やすことはできません。

地球で暮らす以上、皆平等です。

めちゃくちゃ余談ですが、地球外の何かと比べた時は時間は平等ではないということ、知ってました？？

ですが、お金は増やせます。

どんな理由でプログラミングを学ぼうとも、どう効率的にお金を増やし、どう自由な時間を作るか、それがすべての根底にあるものになります。

1. お金

お金ではなく、夢なんだ。

お金よりも愛が大切だ。

よくこのような言葉を聞きます。

ですが、これはを現実世界で実現しようとするとなかなか難しいところがあります。

実際は、「夢」にも「愛」お金が必要です。

西野亮廣さんの「夢と金」という本の紹介がyoutubeでありますが、これはとても参考になります。

そしてこちらはデヴィ夫人の「大好きな年収200万円の男性」と「好きでもない年収1億円の男性」では、どちらと結婚するべき？【デヴィ夫人の婚活論】というyoutube動画です。

プログラミングを学びたい理由が「お金」という明確な理由ならわかりやすいのですが、「自由な時間」「海外に行きたい」「作りたいサービスがある」というように直接お金に結びつかない場合は、イメージしにくいかもしれません。

夢のためでも、自由な時間が欲しいためでも、絶対にお金の問題はついてきます。

きちんとお金の知識をもち、効率的に稼ぐことができれば、夢の選択肢も広がりますし、働かなくてよい時間が増え、自由も手に入れることができます。

何を目標し、自分が向かっている先は市場全体でどのくらいのお金が動いていて、自分がどのくらい稼ぐことができそうなのか、それを知るっておくことはとても大切なことなのです。

この考え方について、とても大切なことを気ずかせてくれる武井壮さんの「大人の育て方」という授業がyoutubeにあるのでこの動画はぜひ目を通していただきたいです。

かなりおすすめで、学び方と、教育に関して「ハッ」とさせられます。

2. 時間

どんなにお金を持っている人でも、持っていない人でも与えられた時間は同じ24時間です。

そして、寿命もある程度決まっています。

その中で目標を達成していかなければいけないわけですが、だれも、時間を無駄にはしたくないですよね。

効率的に目標を達成するには、時間のリソース配分がとても大切になってきます。

時間を増やすことはできないですが、お金で買うことができます。

九州へ自転車で行く例がそうですよね。

自転車で行けば大きなお金はかかりませんが、時間がとてもかかります。

飛行機で行けばお金はかかりますが、時間を圧倒的に短くすることができます。

このように、増やせない時間をせめて無駄に消費しないよう、お金で買う必要があります。

そのためにはお金が必要です。

ですが、多くの人ははじめからお金が潤沢にあるわけではありませんので、稼ぐ必要があります。

稼ぐにはどうしてもある程度の時間が必要です。

となると、最小限の時間を投下して、最大のお金を稼ぎたいですよね。

上で紹介した武井壮さんの「大人の育て方」でもありましたが、

• かけた時間をギャンブルにしない
• これから進もうとしている道がどのような経済的価値を持っているのかを知る
• 経済的価値の高いポジションは何なのかを知る

そのためになぜ自分はプログラミングを学びたいのかを改めて明確にし、↑で上げたことを知っておくことが大切です。

プログラミングの技術を使ってお金を増やすには時間をどこに投下すればよいのか

以下の表はエンジニアのキャリアマトリクスです。

この表をもとに自分の目指す場所を明確に持っておき、その軸からぶれないように積み上げ、最短距離で目標を達成する事が大切になります。

この中でも特におすすめのポジションが、「IT企業×資本集約型（他に働いてもらう）」と「経営者/投資家×資本集約型（他に働いてもらう）」のポジションです。

このサービス売却がなぜおすすめかと言うと、ミドルリスクとハイリターンと、もっともコスパが良いからです。

そして次におすすめなのが「経営者/投資家×労働集約型（自分で働く）」のポジションです。

[もっともおすすめ]サービス売却の手順

サービス売却と聞くととても難しそうに聞こえますよね。

私もプログラミングを勉強し始めたころはそうでしたが、やってみると以外と簡単でした。

実際。私は自分で制作したサービスを売却し、売却先の企業で開発に関してアドバイスを行うというポジションについています。

売却の手順

このようなステップで制作から売却までを行う事で、比較的低リスクで、大きなリターンを得る事が可能です。

ここでのリスクとは、最初に投下するコストの事を指しています。

この場合、初期のコストは自分の時間です。

これは、自分でサービスを開発し、そのサービスを運用して利益を得るよりも圧倒的にコストと失敗のリスクが小さいです。

自分でサービスを収益化しようすとすると、マネタイズやマーケティングなど、もっと幅広く、膨大な知識、スキルが必要となってきます。

それに対して、新しいサービスを真似るだけなら収益化もマーケティングも必要ありません。

そして、売却時には、ある程度の金額が入って来ます。

何かの交流会などで売却経験ありと自己紹介してみてください。

一目置かれると思いませんか。

たとえ、売却金額が、10万円や1万円と金額が低かったとしても関係ありません。

webサービスを制作し、売却したという経験はこれからビジネスを行う上で、必ず大きな武器になります。

時には売却金額が1000万を超えてくる場合もあります。

私と一緒にスクールを運営しているメンバーの中にはメディアを制作し、7000万円ほどで売却した実績を持っている方もいます。

[次におすすめ]経営者/投資家の近くでエンジニアとして働く

次におすすめなのが経営者もしくは投資家の近くでエンジニアとして働くことです。

私のキャリアはこのパターンです。

決裁権を持つ人の近くで働くと意見が通りやすくなりますので自由度がかなり高くなりますよ。

簡単とは言いません。

ですが、立ち上げたばかりで人手が欲しいという会社ならかなり現実的に可能となってきます。

決済権を持つ人と仲良くなり、エンジニアとして働くおすすめの方法は、「今、決済権を持っている人は対象から外す」ことです。

どういうことかと言うと、これから決済権を持ちそうな人と仲良くなっておき、その人が後々決済権を持った時に連絡を取ってみるという戦略です。

そのためには、なるべく沢山のクリエイターと交流をしておきましょう。

現在すでに成功しつつある決裁者は話をする内容のレベルが高すぎたり、とても忙しく、会うことすら難しいでしょう。

ですので、気軽に話すことができる決裁者の卵となるような人物とつながっておきます。

このように、成功前の状態の知り合いを増やすことで驚くほど仕事がしやすくなります。

これは私の実体験でもあります。

見極めはあきらめてとりあえずコミュニティに属する事が大切です。

まずは、コミュニティサービスに入ってみるという一歩を踏み出してみましょう。

[セーフティーとして]一般のIT企業への就職

サービスの売却と、決済権のある人の近くで働くという話をしましたが、これら2つはどちらも中期的に見た場合の戦略です。

デメリット、リスクとして、

• 来月のお金は稼げない
• 貯金がある程度ないと実行するのが難しい
• 時間をかけて知り合いやサービスを作ったとしても必ずお金になるわけではない

と言ったことがあります。

ですので、リスクヘッジとして、まずは一般のIT企業へ就職、転職し、上記2つは平行して進める形が理想的です。

プログラミング未経験の場合、IT業界の立ち回りや常識がわかりません。

職につき、プロのエンジニアとして活動した経験がある人とそうでない人とでは、スキルや信頼が大きく違います。

の順が最もおすすめのキャリア戦略です。

世の中の99.99%の課題は既存の知識の組み合わせで解決できる

IT企業へ就職するにしても、自分でサービスを制作するにしても、エンジニアがやることは変わらず、以下の内容です。

世界中の現実で起こっている課題/問題をプログラムに落とし込んで解決する

これにつきます。

そして、世の中の99.99%の課題は既に解決済みです。

つまり、世の中のほぼすべてのエンジニアの仕事は誰かが解いた問題をもう一度解いているだけです。

ある程度プログラミングを勉強すると、自分がやっていること、エンジニアがやることは毎回書くコードも違うし、お客さんの課題も違う。

オリジナルだ！

と思うようになります（自分がそうでした）が、ほぼ確実にオリジナルではありません。

過去にやったことの繰り返しです。

本当にオリジナルであれば、それは論文にして学会に発表すべきです。

そうならないということは、すでに解かれた問題であり、それらが組み合わさって、全体で見るとオリジナルになっているだけなのです。

いかに問題の本質を見極るか。そしてその問題の解決方法を知識としてストックしておくか。これが大切！

まぁ、少し難しいところもありますが、大切な基礎ですので必ず習得したいところです。

これらの知識は主にコンピュータサイエンスと呼ばれる分野で勉強します。

アメリカやインドなどの情報系の大学では当たり前に学ぶ分野となっており、就職するにはコンピュータサイエンスの学位を持っていないと応募で落とされるらしいです。

それぐらい基本的な知識であり、この知識がない人は足切り対象になるくらい大切なものです。

ですが、日本ではまだまだ一般的ではなく、この知識がない人でもエンジニアになれてしまうことが残念なところです。

逆に考えると、日本はアメリカの10年遅れでやってくるといわれていますので、ライバルが少ない、今勉強する事で一歩先に進むことができるかもしれません。

学ぶ上で大切なのはやっぱり基礎力・基礎知識

何かを学ぶ上で大切なことはやっぱり基礎をどれだけ習得しているかどうかです。

初めのほうで紹介した武井壮さんの「大人の育て方」という授業でもあるように、基礎力がなければ学ぶことができる土俵にすら立てません。

ですので、まずは徹底的にプログラミングの基礎を学びましょう。

昔から守破離と言いますが、改めて基礎は大切だと感じます。

　webエンジニアに基本的な知識は以下です。

• webの仕組み
• webサイトの制作方法
• プログラミングの基礎
  • 変数と参照
  • 条件分岐
  • 繰り返し
  • 関数
• データ構造とアルゴリズム
• データベース設計とSQL

こちらで上げたのは大枠になります。細かくするともっと多くの基礎を学ぶ必要があります。
基礎と言ってもパパっとすぐに終わらせることはできません。

多くのプログラミングスクールを見ると特に、データ構造とアルゴリズムを教えているスクールがほとんどありません。

データ構造とアルゴリズムは本当に大切なプログラミングの基礎知識で、数学に例えるなら小学生の算数です。

基本的な算数がわからないのに大学の問題を解かされているようなものです。

「○○を動かすには□□というコードを書けばいい」このように公式を暗記すればスクールの問題は解くことができるかもしれませんが、そのような人はその公式を分解して応用する事ができなくなりますので、すぐに限界が来ます。

さらに、そのレベルなら今はChat GPTで代用可能です。

ですので、ただただ公式を覚えるのではなく、その本質である基礎の知識を習得する方がとっても大切なのです。

プログラムを書くトレーニングも大切だが、それ以上に読むトレーニングが大切

プログラミングの勉強法に「アウトプットが大切！」「とにかく書け！」と言っていることを多く見かけます。

たしかにそうです。

初めの事はインプット3割、アウトプット7割くらいに。とにかく書くこと、アウトプットする事はが大切だと思いますが、忘れてはいけない大切なことが正しく読むトレーニングです。

最終的に価値を生む（お金が発生する）のはアウトプットに対してです。

なので、アウトプットのトレーニングに目が行きがちですが、

正しくインプットできなければ正しいアウトプットもできません。

なのでプログラムコードの読解力はとても大切なのです。

これは先ほどの「学ぶ土俵に立つ」にも関連する事ですが、

正しく読むことができない = 勉強する事すらできない

ということです。

次の章でプログラミングのメンタルモデルについて解説します。

細かいことはどうでもいい。メンタルモデルを構築しろ。

メンタルモデルとは「○○をすると□□になる」というような物事に対する認識やイメージです。

といってもよくわからないかもしれませんので例を用いて解説します。

メンタルモデルとは？森のくまさんのメンタルモデル

例えば、「森のくまさん」という歌がありますが、歌詞は以下のようになっています。

あるひ　もりのなか
くまさんに　であった

この文章を見ることで、頭の中には熊にであったことでその人が襲われるかもしれない危険な状態であるということを想像できるかと思います。

これがメンタルモデルです。

文章ないには、熊が襲ってきたというような内容は一切記載されていませんが、

• 熊 = 力が強い
• 熊に襲われるというニュースを見る

というような情報があらかじめ脳内に存在する事によって「襲われるかもしれない危険な状態」ということが予想されたのです。

これが、「○○をすると□□になる」というイメージ。今回の場合は「熊に出会うと危険である」というメンタルモデルということです。

日本では….

実は森のくまさんはアメリカ人が作った曲ですが、アメリカでは銃を持っていることが当たり前の価値観です。

と言うことは森で熊に出会っても撃ち殺すことができるので危険な状態なのは熊さんかもしれません。

このように、環境や経験によってメンタルモデルが事なると、人によって認識が異なってきます。

ですので、プログラミングに対しても正しいメンタルモデルを構築しておかないと、話が通じなくなることがありますので重要なのです。

メンタルモデルを気にせず勉強するとどうなる？数学のメンタルモデルで解説

人間は自然とメンタルモデルを構築する生き物ですが、仮に全くメンタルモデルを構築できないとどうなると思いますか？

メンタルモデルは経験などからくるイメージや価値観、予想ですので、それがないということはすべて暗記に頼るしかなくなります。

覚えていることしかアウトプットできなくなるのです。

メンタルモデルを構築しない学習 = 暗記

例えば、掛け算の仕組みである、足し算を繰り返しているというメンタルモデルが構築されないまま、掛け算九九を暗記させられるとどうなるでしょうか？

ですが、掛け算の仕組みである足し算を知っていれば9 × 9 = 81に9を足して90ということが導きだせます。

さらに、引き算が可能ということを知っていれば、20 × 19という問題があったときに

メンタルモデルがないと、このような応用した計算ができず、暗記勝負になってしましい、未知の問題を解くことができなくなってしまうのす。

プログラミング学習においても全く同じことが起こります。

ですので、プログラムの世界の○○をすると□□になるという仕組みを理解し、しっかりメンタルモデルを構築する事を意識しましょう。

プログラミングは暗記じゃないし、言語の問題じゃない

これまでの説明からこのようなことが言えます。

プログラミングは暗記じゃないし、言語の問題じゃない。

学校での勉強のせいか、プログラムを丸暗記しようとする人を多く目にしますが、暗記してはいけません。

メンタルモデルを構築する事を最優先にしてください。

そして、ともに多く目にする的外れな事がもう一つあります。

それは、「どの言語を勉強すればよいですか？」という質問です。

「森のくまさん」で説明したことを思い出してください。

あそこでのポイントは文章をイメージ化し、見えたストーリーについて話していました。

言語は関係ないのです。あの文章が中国語で書かれていても、英語で書かれていても、読み取れるストーリーは同じであり、大切な事はストーリーなのです。

森のくまさんというストーリーを書きたいのに、「どの言語を勉強すればよいか？」と聞く人は少ないでしょう。

プログラミングも同じです。

プログラムを書く上で大切な事は「世の中の99.99%の課題は既存の知識の組み合わせで解決できる」の章でも説明したように、問題を解決する方法を素早く導き出すことです。

その解決方法を日本語で記載しようが、英語で記載しようが、Java Scriptで記載しようが、phpで記載しようがなんでも書くことができるのです。

大切な事は問題を解決する手順を知っているかどうかです。

プログラム言語を知っていても、解決方法を知っていなければ、プログラムを書くことはできません。

ですが、逆に、プログラム言語を知っていなくても解決方法を知っていれば、それをChatGPTに入力し、phpで書いてと命令すれば書いてくれます。

プログラムを書くことは単なる翻訳作業でしかないですので、実際の現場ではおそらく全体の20%程度の作業量でしかありません。

残りの80%はどうすれば問題を解決できるのかを考えることに頭を使っています。

ラーニングピラミッド理論で効率的な学習方をする

マインドセットを構築することが大切といいましたが、マインドセットを構築するにはアクティブラーニングが必要です。

アクティブラーニングとは、ラーニングピラミッドの下3つの「討論・体験・教える」という学習方法の事を指します。

ラーニングピラミッドとは、学習したことの定着率、言い換えるならメンタルモデルの構築度合別に分類したものです。

ピラミッドの下に行けば行くほど、定着率が上がります。

ですので、なるべくアクティブラーニングを心掛けながら学習を進めていきましょう。

アクティブラーニングとそれ以外との違いはインプットかアウトプットかの違いです。

アクティブラーニング = アウトプット
それ以外 = インプット

ここがよく言う、インプット3割、アウトプット7割論につながります。

アクティブラーニングを多くすることでより学習したことの定着率が上がり、メンタルモデルの構築も早くなります。

他の人に教えるということにハードルを感じる場合、学んだことをブログなどにまとめるのがおすすめです。

ブログを書く際に、だれが特定の人物を想像し、その人に自分の学んだことを教えるつもりで記事を書いてみてください。

そしてそれをweb上に公開してみるのです。

実際にそのブログが検索され、ユーザーが訪れると、モチベーションにもつながります。

さらに、何より、ブログを書く際はWordPressを使うと思いますので、WordPressの勉強にもなるという一石二鳥な勉強方法です。

サーバーの解説からブログの立ち上げ、カスタマイズ、記事の制作、SEOなどをアクティブラーニングを通して幅広く学習する事で、将来できる仕事の幅がかなり広がります。