第17回 お問い合わせページを完成させる―mailtoフォームとAdSenseの記載を追加

第16回では、タグの表記揺れが再発しないように、タグマスタとalias、共通の正規化処理を追加した。

そのあと固定ページを確認すると、お問い合わせだけはまだ「準備中」の文章が残っていた。

About、プライバシーポリシー、免責事項はすでに公開している。フッターからお問い合わせへも移動できる。それなのに、移動先では実際の連絡手段を用意できていなかった。

今回はお問い合わせページを実際に連絡できる状態へ変更し、あわせてプライバシーポリシーのGoogle AdSense部分へ不足していた説明を追加する。

お問い合わせは外部フォームを使わずメール起動方式にする#

お問い合わせを作る方法はいくつかある。

フォームサービスを使う方法もあれば、Cloudflare Workers側で送信処理を作る方法もある。ただ、今回必要なのは「記事の誤記を連絡したい」「リンク切れを知らせたい」といった連絡窓口で、問い合わせ管理システムまで作る必要はない。

そこで外部サービスは追加せず、入力内容からmailto:を作って利用者のメールアプリを開く方式にした。

ページ上部の問い合わせ対象はそのまま残している。

• 記事内容についての質問
• 誤記や古くなった情報の修正依頼
• 著作権や掲載内容についての連絡
• リンク切れなど、サイト上の問題
• その他、ゆまラボに関する問い合わせ

修正後は、その下にメールでの問い合わせ方法を追加した。

連絡先は次のメールアドレス。

hs1900705@yahoo.co.jp

フォームが使えない場合でも連絡できるよう、メールアドレス自体を通常のmailto:リンクとして表示している。

JavaScriptが無効な環境ではフォームを表示せず、この直接リンクと案内だけを残すようにした。フォームの機能と連絡先そのものを分けているので、JavaScriptが動かないだけで連絡手段まで消えることはない。

フォームからサイト側へ送信はしない#

追加したフォームは次の3項目だけにした。

お名前             任意
件名               必須
お問い合わせ内容   必須

送信ボタンの名前も「送信する」ではなく、メールアプリを開くにしている。

ここは表示と実際の動きを合わせた。

このフォームからゆまラボのサーバーへ内容を送るわけではない。ボタンを押すと、入力した件名と本文を使って次の形式のURLを作る。

mailto:hs1900705@yahoo.co.jp?subject=...&body=...

件名と本文はencodeURIComponentでエンコードする。本文の改行はCRLFへ統一した。

日本語や記号をそのままクエリ文字列へ連結すると、メールアプリへ渡す途中で文字列が崩れる可能性がある。入力値をエンコードしたうえでsubjectとbodyへ入れる形にしている。

実際に入力した状態も確認した。

フォームの説明には、次の点も明記した。

• ボタンを押すとメールアプリが開く
• サイトから自動送信はされない
• 内容を確認してメールアプリ側から送信する
• すべての問い合わせへの返信を保証するものではない

サイト側から送信していないのに、送信完了画面を出すような処理は入れていない。

必須項目はHTMLと入力値の両方で確認する#

件名とお問い合わせ内容にはHTMLのrequiredを設定した。

ただし、requiredだけでは空白だけを入力したケースまで十分に扱えないため、実装側でも空白だけの入力を拒否するようにしている。

フォームについて確認した内容をまとめる。

件名・本文の必須チェック
空白だけの入力を拒否
日本語のエンコード
記号・絵文字のエンコード
複数行本文の改行
キーボード操作時のフォーカス表示

入力欄はlabelと関連付け、placeholderだけに項目名を任せない形にした。

見た目については既存の固定ページと同じ本文幅を使い、新しいUIフレームワークは追加していない。PCのほか、320px、360px、390pxでも横方向にはみ出さないことを確認している。

今回のフォームは連絡を受け付けるための最小構成にしているので、メールアドレス入力欄や問い合わせ履歴の保存機能も追加していない。

mailto:方式でできることと残る制約#

今回の実装では、フォームに入力した内容をゆまラボ側で受信してからメールへ転送する処理はない。

流れは次のところまで。

フォームへ入力
↓
件名と本文をエンコード
↓
mailto: URLを作成
↓
利用者のメールアプリへ渡す

そのため、フォームへ入力した時点では何も送信されていない。メールアプリが開いたあと、利用者が宛先・件名・本文を確認して送信する必要がある。

この方式には制約もある。

ブラウザやOS側で既定のメールアプリが設定されていなければ、ボタンを押しても想定したアプリが開かない場合がある。Webメールを普段使っている環境でも、mailto:の関連付け次第で動きは変わる。

そのため、フォームだけを唯一の連絡手段にはしなかった。ページ上へメールアドレスを文字列でも表示し、コピーして別のメールサービスから送れるようにしている。

外部フォームサービスを追加していないので、今回の変更によって問い合わせ内容を保存するデータベースや、新しい送信APIも増えていない。連絡窓口を用意するという目的に対して、変更範囲をcontactページ内へ寄せられた。

プライバシーポリシーのAdSense説明を追加する#

お問い合わせとは別に、プライバシーポリシーも1か所変更した。

修正前のGoogle AdSense部分には、Cookieを利用することや、過去のアクセス情報をもとに広告が配信される場合があることは記載していた。

既存の説明は削除せず、その下へ次の内容を追加した。

利用者は、Googleの広告設定から、パーソナライズド広告を無効にすることができます。

Googleの広告設定からは、Google公式の広告設定ページへ移動できる。

https://adssettings.google.com/

この修正ではプライバシーポリシー全体には手を入れていない。

Google AdSense部分の既存文章を維持したまま、広告設定に関する1段落とリンクだけを追加している。

Google AdSenseのプライバシーポリシーに必要な内容については、Google公式の案内も確認した。

今回のお問い合わせ修正とあわせて見ると、固定ページは「存在すること」だけでは足りない。お問い合わせは実際に連絡できる状態が必要で、プライバシーポリシーは現在使っているサービスに対応した説明が必要になる。

どちらも大きな機能追加ではないが、公開後に読者が直接使うページなので、記事ページとは別に動作と記載内容を確認しておく。

ビルドと表示を確認する#

今回の修正後にnpm run buildを実行し、94ページの生成まで完了した。

Pagefindは24記事を索引化。RSS、sitemap.xml、個別タグのnoindex, follow、パンくずのJSON-LD、前後記事、目次など既存機能もあわせて確認している。

お問い合わせについては一時的なブラウザー検証も行い、PCと320px、360px、390pxでフォームの表示を確認した。

確認できた範囲は、フォームの入力、必須チェック、空白チェック、mailto:の生成、日本語・記号・絵文字・改行のエンコードまで。

実際のメールアプリ起動と、その先のメール送信は公開後の確認項目として残している。OSやブラウザで既定のメールアプリ設定が異なるため、ここは本番環境で実際にリンクを押して確認する。

追加した連絡先とプライバシー項目#

準備中になっていたお問い合わせページは、外部サービスを増やさず、メールアプリを利用する形で連絡できるようにした。

フォームが動かない場合でも直接メールアドレスを使えるようにし、JavaScriptが無効でも連絡先は残る。

プライバシーポリシーには、Googleの広告設定からパーソナライズド広告を無効にできる説明を追加した。

固定ページを作るだけでなく、実際に利用できる状態まで確認するところまで進めた。

参考#

• Google AdSense ヘルプ：プライバシーに関する必須コンテンツ
  https://support.google.com/adsense/answer/1348695?hl=ja