JavaScriptを使うmenuとformはscriptが動かない画面でも必要な案内へ進めるように作る
公開日: 執筆:佐藤
JavaScriptを使うmenuやformは、scriptが動くことを前提に画面を作る前に、利用者が必要な案内へ進む基本のHTMLを残します。menuなら通常のlink、formなら送信先とserver側の確認を用意します。JavaScriptは操作を便利にするために足し、必要な本文、連絡先、送信の入口を作る代わりにはしません。
W3CのHTML 5.1は、scriptで実現する機能には、可能な場合に宣言的な代替手段を使い、scriptが使えない状況でも段階的に機能するapplicationを作るよう勧めています。これは、全ての画面からJavaScriptをなくすという意味ではありません。scriptが動かないとき、何が使えず、何だけは使える必要があるかを分ける考え方です。
menuを動かすscriptと行き先のURLは役割が違う
menuを押したときに下位項目を開く動きは、JavaScriptで作れます。しかし、会社案内、サービス、問い合わせのpageへ進むURLまでscriptの中だけに置くと、scriptが読み込めないときに利用者は行き先を失います。開閉する操作と、pageへ進むlinkを同じものにしないでください。
たとえば、サービスmenuを押すと項目が開くsiteを考えます。通常のHTMLにサービスpageへのlinkがあり、そのlinkへJavaScriptで開閉や表示の調整を足すなら、scriptが動かなくてもサービスpageへ進めます。一方、見た目だけのbuttonを置き、押したあとにJavaScriptがURLを組み立てる形では、scriptの読み込み失敗、browserの設定、scriptの競合が起きたときに、利用者は本文を読めません。
| 画面の役割 | JavaScriptで足してよいこと | HTMLやserver側に残すこと |
|---|---|---|
| global menu | 開閉、animation、現在地の強調 | 各pageへのlinkとlink text |
| service一覧 | 絞り込み、並び替え、表示の切替 | 一覧の基本情報と詳細pageへのURL |
| 問い合わせform | 入力中の補助、送信前の表示、確認画面の補助 | 送信先、必須項目の確認、受信処理 |
| 地図や予約 | 表示の切替、日時の選択補助 | 住所、電話番号、予約の代替連絡先 |
説明用の仮例として、飲食店がmenuの中に「予約」「営業時間」「アクセス」を入れる場合を考えます。mapを表示するscriptが止まっても、住所と電話番号が本文にあれば、利用者は店へ連絡できます。予約formの日時選択が使えなくても、電話番号か予約pageへの通常のlinkがあれば、用件を進められます。mapやcalendarの便利な画面と、連絡するための情報を分けます。
noscript要素へ「JavaScriptを有効にしてください」とだけ書いても、利用者の用件は終わりません。scriptが使えない理由を利用者がすぐ解決できるとは限らないからです。必要なpageへのlink、電話番号、email address、営業時間を読める形で置き、noscriptは補足として使います。警告を出したことと、代わりの道を用意したことは別です。
formの入力補助と送信の確認を混同しない
JavaScriptは、入力欄へ文字数を示す、郵便番号から住所候補を出す、送信前に確認画面を表示する、といった補助に使えます。こうした補助は利用者の手間を減らします。ただし、scriptが動いたときだけ必須項目を確認するformでは、serverへ届いたdataを正しく扱えません。
formで先に決めるのは、何を受けるか、どこへ送るか、受けた人がどう対応するかです。名前、連絡先、相談内容を受けるなら、formのactionで送信先を決め、server側でも入力と形式を確認します。JavaScriptの確認は、送信する前に利用者へ分かりやすく伝える補助です。送信dataを信用してよいかを決める最終の検査ではありません。
たとえば、email addressの入力形式をJavaScriptで確認している場合でも、scriptを使わないbrowserや、自動処理からformが送られることがあります。server側で確認せず、JavaScriptの表示だけを頼りにすると、受信側は必要な連絡先がない問い合わせを受ける可能性があります。反対に、server側でしか確認しないと、利用者は送信後まで入力間違いに気付きにくくなります。二つの役割を重ねずに使います。
また、送信buttonを押したあとにJavaScriptで画面を切り替えるformでは、二重送信や通信失敗のときの表示も確認します。「送信しました」と画面に出ても、serverが受け取っていなければ、利用者は連絡できたと思い込みます。test用の内容で送信し、完了page、受信mail、管理画面の記録を順に確認します。画面のanimationより、受信側へ届くことを先に確かめます。
scriptが止まる場面を一つだけ試す
全てのbrowserと通信障害を再現する必要はありません。まず開発用のbrowserでJavaScriptを無効にする、またはscript fileの読み込みを一時的に止め、主要なpageを開きます。top pageからmenuをたどり、サービス説明、会社案内、問い合わせへ進めるかを見ます。formがあるなら、入力欄の項目名と連絡先を読めるかを確認します。
ここで見つかった問題を、noscriptの文章だけで隠しません。menuからlinkが消えるならHTMLへURLを戻し、formの入力確認がclient側だけならserver側の検査を加えます。JavaScriptを直す担当者と、掲載する情報を確認する担当者が違う場合は、止めたときに読めなかったURL、操作、期待した結果を渡します。
| 確認する順序 | 開くもの | 判断すること |
|---|---|---|
| 基本の案内 | top page、global menu、主要page | scriptなしでも本文とlinkを読めるか |
| 連絡導線 | 問い合わせpage、電話番号、email address | 利用者が連絡先を見つけられるか |
| form | 入力欄、送信先、完了page | server側の処理まで確認できるか |
| JavaScriptありの画面 | 開閉、入力補助、表示の切替 | 便利な操作が基本のHTMLを隠していないか |
外部の制作会社へ依頼する場合は、「JavaScriptを無効にしても見られるように」とだけ言わず、残すべきpageと用件を指定します。サービスpage、問い合わせ、予約、電話番号のどれを必須の導線とするかが分かれば、作る側はHTML、server側のform、scriptの役割を分けられます。実装を任せても、利用者へ何を伝え、どこへ進ませるかの判断はsite側に残します。
最初の一手は、siteでJavaScriptが止まると困る操作を三つ書き出し、その操作なしでも進めるURLまたは連絡先があるかを確認することです。scriptを便利な追加として扱えば、変更や障害があってもsiteの案内を残せます。
関連記事

