W3J.org

こんなフォームはイヤだ！

フォームとは、HTMLのFORM要素などによってマークアップされているコントロール群の塊のことです。さまざまなウェブサイトにおいて、主に問い合わせのページであるとか、サイト内検索のためのキーワード入力用にだとかで利用されています。コミュニティ機能を備えているようなサイトであれば、掲示板システムのようなところでも使われていることでしょう。フォームのないウェブサイトのほうが珍しいのではないでしょうか。それくらい、制作側にもユーザーにも身近なものです。

INPUT要素やTEXTAREA要素などといった、フォームのコントロール各要素の機能はブラウザによって提供されているため、どのようなブラウザであってもその操作感に大きな違いが出ません。しかしコントロールごとの操作に違いが出ないといっても、フォーム全体としてはやはり使いやすいフォームと使いにくいフォームというのがあります。フォームは健常者が使っても、基本的に操作が容易なものではありません。そのフォームの利用に慣れているユーザーであっても、しばしば入力内容や操作を間違えたりするものです。障碍者や、あるいは不便な環境や状況で使用するユーザーであれば、なおのこと使いにくいフォームには出会いたくないことでしょう。ウェブサイトで、問い合わせる必要があるなどして用意されたフォームを利用しなければならないとき、それが使いやすいフォームであればまだしも、使いにくいフォームだったりしたら、利用自体を諦めてしまうかもしれません。

さて、それはどのようなフォームが使いにくいかといえば、たとえば以下のようなものです。

1. どの入力項目に対応しているのか、さっぱりわからないラベルがある。
2. 生年月日の項目で、年のプルダウンメニューが100年分くらいある。
3. 郵便番号は半角のくせに住所の番地は全角で入れろだとか、もうバラバラだ。
4. 確認画面で誤入力があると叱られて戻ったら、入力した内容が全部消えていた。
5. 確認画面へ進むのかと思ってボタンを押したら、送信が完了してしまった。
6. 入力しなくちゃならない項目が、なんだか物凄くいっぱいある。
7. がんばって全部に入力したら、実はほとんどが入力しなくても構わない項目だった。
8. しかもその後、広告メールがたくさん届くようになった。

以上のどれもこれも、少なからず見受けたことがあるのではないでしょうか。これらの原因のほとんどは、制作側の怠慢によって形成されているものです。もっと正しくマークアップしていたら、もっと注意深く説明文を用意しておいたら、もっとしっかりとしたCGIプログラムで受け取るようにしていたら、きっと「こんなフォームはイヤだ！」などとはいわれないものができたはずなのです。

というわけで最終回でもある今回は、気持ちよく最後まで入力し切って送信できるような、そんなフォームについて解説していきます。

正しくフォームをマークアップする

HTML 4.01は、仕様書のAbstractに書かれている通り、それ以前のバージョンであるHTML 3.2やHTML 2.0よりも、ずっと国際化やアクセシビリティなどについて考慮されたHTMLのバージョンとなっています。定義された要素や属性には、それらへの対応を意識しているものが多くありますし、仕様書の文面やサンプルなどでも精力的にそれらのことを解説しているのです。WAIのアクセシビリティガイドラインであるWCAG 1.0は、さらに突っ込んでアクセシビリティのことを述べまくっているのですが、HTML 4.01仕様書と重複した説明も見受けられます。WCAG 1.0はHTML 4.01よりも早く勧告されていますが、WCAG 1.0よりも前にHTML 4.0が勧告されています。HTML 4.01は、HTML 4.0のマイナーチェンジ的なバージョンですが、その間に勧告されたWCAG 1.0の影響も受けていると考えられ、そのためアクセシビリティについても広く考慮されているのは当然であるともいえるでしょう。

そんな経緯も踏まえれば、フォームのマークアップが正しくHTML 4.01に準拠したものになっているだけでも、当然ながらそうでないものに比べ、その操作性は大きく向上するといえます。また、HTMLの各バージョンは、常に後方互換を意識していますから、HTML 4.01として妥当な文書であれば、HTML 4.01準拠を謳うブラウザはもちろんのこと、それ以前のバージョンに準拠しているブラウザでも多くは正常な動作をするでしょう。たとえばそのフォームが、常にうまく機能するであろうことが期待できるのです。

コントロールには、次のような要素があります。コントロール群にとっての基本要素となるFORM要素、コントロール群をグループ化するためのFIELDSET要素とLEGEND要素、コントロール群であるINPUT要素、BUTTON要素、SELECT要素、OPTGROUP要素、OPTION要素、TEXTAREA要素、そしてそれぞれのコントロールに対するラベルとなるLABEL要素といったものです。

さきほど挙げた、イヤなフォームの例でいうと、たとえば1は正しくマークアップすることで回避できるようになります。

ラベルというのは、入力項目名のことです。具体的には、このようなフォームがあったら「お名前」が入力項目名ですから、つまりこれがラベルだというわけです。そしてこのラベルに続いているINPUT type=text要素が入力欄です。

【図1】ラベルの例

ラベルを明示するために用意されているのがLABEL要素です。この要素でラベルをマークアップし、入力欄に関連づけることことができます。この場合なら、たとえば次のようにマークアップします。

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

<label>お名前：<input type="text" name="frName" id="frName" value=""></label>

前者のようにfor属性をともなったLABEL要素によって、for属性で指定した値をid属性として備えるフォームコントロール要素に関連づけられていることが明示されます。後者は、やや暗示的な関連づけとなっており、for属性をともなわず、LABEL要素の内容となっているテキストが、同じくLABEL要素の内容に含まれるコントロールと対であると見なされるものです。

これにより、ラベルをフォーカスすればそのままコントロールへの入力が行えるようになります。Ineternet Explorer（以下、IE）などのグラフィカルブラウザでラベル部分をクリックしてみてください。関連づけられたINPUT type=text要素がフォーカスされることがわかるでしょう。ただし、IEなどは後者の関連づけを理解してくれないようですので、基本的には前者の明示的な関連づけを採用すると良いでしょう。

しかし、このような「お名前」の入力を促しているフォームは、ラベルと入力欄との関連が比較的自明に見えるかと思います。一般に、ラベルとコントロールが対の関係であることがわかりにくいのは、チェックボックスやラジオボタンを、横に並べている場合でしょう。見ればわかるかと思いますが、チェックボックスがその前後のラベルのどちらに対応したものであるのかが一見して判別しづらいのです。この図では項目数が少ないからまだ良いのですが、これがもっと多くなり何行にも続くかのように表示されてしまうと、だんだん手に負えなくなってくるものなのです。

【図2】横に並べたチェックボックス

このとき、ユーザーがチェックしたいと思って注意を注ぐ先は、並んでいるラベルたちであって、チェックボックスたちではありません。したがって、ラベルのそばにあるチェックボックスなら何でも良いと勘違いしてしまう可能性があると考えられます。実際問題として、チェックボックスは必ずラベルの前にあるというような合意がないわけですから、後ろにあると思ってしまっても間違いではないのです。むしろ、そう思わせてしまうような見せ方をしてしまった制作側に非があります。

たとえば雑誌などのアンケートのためのフォームの場合、「面白かったものすべてにチェックをしてください」などという設問に続けて、20個近いラベルがずらずらと続いてしまってもおかしくないのです。そういった規模のときに、チェックする箇所を間違えたことに気づいたりなんかしたら、なんというか期末テストで最後の問題に到達したとき、答案用紙の解答欄に、答えをひとつずつズレたまま書き続けてしまったことに気づいたという状態と同じ気持ちになってしまうようなものです。ちなみに僕なら、テスト時間の残りにもよりますが、面倒だし諦めてしまうかもしれません。同様にこのフォームの設問においても、面白くなかったものにチェックしちゃったかもしれないけど、まあいいやと思ってしまうことでしょう。そもそもフォームへの入力なんて、期末テストなんかよりも明らかにプライオリティが低いわけですから。

チェックボックスやラジオボタンを列挙するときは、できるだけ縦に連なる箇条書きとなるように見せると良いでしょう。フォームのページの縦スクロールが長くなるのを嫌うよりも、信頼のおけるデータを入力してもらうことに配慮したほうが正しい姿勢であるといえるでしょう。それに、縦に連なる前提で制作しておけば、画面の小さい端末などでフォームを利用する状況にも近づきやすいものとなります。

【図3】縦に並べたチェックボックス

そしてもちろん、忘れずにLABEL要素でチェックボックスとラベルとを関連づけます。また、LABEL要素のネストが仕様上できないため、「興味のあることにチェックを入れてください。」と続くチェックボックスたちとの関連がちょっと弱く感じられてしまうかもしれません。これはFIELDSET要素とLEGEND要素を用いることで、うまく関連づけを明示させることができます。

<fieldset>
<legend>興味のあることにチェックを入れてください。</legend>
<ul>
<li><input type="checkbox" name="frCb1" id="frCb1" value="cb1"><label for="frCb1">HTML</label></li>
<li><input type="checkbox" name="frCb2" id="frCb2" value="cb2"><label for="frCb2">CSS</label></li>
<li><input type="checkbox" name="frCb3" id="frCb3" value="cb3"><label for="frCb3">アクセシビリティ</label></li>
<li><input type="checkbox" name="frCb4" id="frCb4" value="cb4"><label for="frCb4">セマンティックWeb</label></li>
</ul>
</fieldset>

FIELDSET要素によって互いに関連するものであると明示された要素たちは、グラフィカルブラウザのデフォルトスタイルでは、しばしば特殊なボーダーで囲まれたように表現されます。たとえばWindows XPのIE6ではこのように表示されます。

【図4】WinXP IE6での表示

デザイン上の理由からこのボーダーを消したい場合は、FIELDSET要素のスタイルを変更します。通常「border:none」の指定で消せるはずですが、Opera7.2などでは、この書き方ではボーダーが消えません。border-styleにnone以外の値を指定してやらねばならないようです。そのうえでborder-widthを0pxとすれば消えてくれます。この書き方ならば、IE6やMozillaだけでなく、Opera7.2などでも意図どおりにボーダーが消えてくれるので安心です。

fieldset { border:0px solid transparent; }

プログラムの制約を押し付けない

イヤなフォームの例の2や3は、主に送信されたデータを受け取るCGIなどのプログラムの仕様によるものです。SELECT要素のプルダウンメニューというものは、ユーザーに任意の入力をさせないようにするために登場します。また、半角英数字とか全角カタカナとかで入力しろといってくるものは、プログラム側でそれら以外の値を一切サポートしていないために、ユーザー側へ入力値の制約を課しているわけです。

数字の入力を求めるとき、全角で書こうが半角で書こうが、プログラム側でそれを判別するのは容易なはずなのです。そしてデータベースなどに書き込む際に、格納するのに都合が良い書式に変換してあげれば済むことでもあります。全角と半角の違いがわからないとか、キーボード操作が苦手であるとか、あるいは普段使いではない不慣れな状況や環境からアクセスしているユーザーもいますから、制約は項目名だけに、つまり「お名前」というラベルの欄には名前を書いてくださいということ以上の制約は設けないほうが、より近づきやすいフォームであるといえます。

プルダウンメニューで入力する内容を選択させることは、一概に使いにくいフォームの要因であるとはいいきれません。たとえばiモード端末のように用意されたキーの数や種類に制限がある小型端末などでは、少ないキー操作で入力を終えられたほうが使いやすかったりもします。生年月日のような数字の入力だけで済む場合は、1900年から2000年くらいまでの幅で用意されたプルダウンメニューから選ばされることを思えば、直接入力するほうが容易でしょう。しかし住所であるとか、漢字変換の作業が必要になるような入力項目においては、プルダウンメニューなどで選択できるようになっていたほうが、使いやすいのではないかとも考えられます。したがって、プルダウンメニューの是非というのは、結局のところは程度の問題であるといえます。

程度の問題ということはつまり、制作側としては「ユーザーにとって操作が容易であるかをきちんと考慮した結果、そこはプルダウンメニューにしている」と、きちんと説明できるくらい考えたうえであれば良いのではないかということです。

とはいえ、プログラム部分は別の制作会社が作っているだとかいうような事情というのも、しばしば見受けられるものです。それと、半角カナで入力されたら、入力し直してねと表示するか、それとも全角に変換してからデータベースに書き込むように実装するかといった違いにしても、制作期間や予算などの都合といったものもあるかもしれません。いつも使っている下地となるライブラリには変換して書き込むようなものがなかったりしたら、新たに作らなければならないわけですから。

当然ながら、入力する値に制約を設けている場合は、ラベルのそばにその注意書きを入れます。

【図5】注意書きを添えたラベル

しかしこのままでは、この注意書きに沿わない入力をした場合に、その注意を受けるのは送信した後になってしまいます。これを送信する前に注意してあげることで、同じ制約を課すにしてもユーザーのいらいら感であるとか、この入力で良いのだろうかといった不安感を軽減させることができるのではないかと思われます。また、イヤなフォームの例の4に対する恐怖感もかなり安らぐことでしょう。ですので、JavaScriptを用いて、送信する前に入力されたデータのチェックをするようにしましょう。本当に送信する直前にチェックするのであれば、FORM要素のonsubmit属性にチェックのための処理または関数を設定します。あるいは各項目への入力ごとにその内容をチェックするというのも良いでしょう。その場合は、各項目のコントロール要素のonblur属性にその要素に対する入力が正しかったかどうかをチェックする処理を設定することになります。どちらが良いかという的確な解答はありませんが、たとえば入力項目が多いときなどは、個別にチェックしていったほうが良いかもしれません。

<label for="frTel">電話番号</label> (半角)〔入力例 03-1234-5678〕：<input type="text" name="frTel" id="frTel" value="" onblur="if(this.value==''){alert('電話番号が入力されていません。');this.focus();}else if(!(/^(\d+)-(\d+)-(\d+)$/.test(this.value))){alert('電話番号じゃないっぽいです。');this.focus();this.select();}">

基本的に、このJavaScriptでのチェックというのは、ちょっとした間違いをさせないためのものなので、あまり厳格に値を見る必要はありません。厳格なチェックは、プログラム側で確実に行なうというのが大前提です。JavaScriptを利用できない環境というものも十分にありえるのですから。

送信ボタンの意図をはっきりさせる

ビジネス・アーキテクツでは、サロンと呼ばれる懇親会のようなものが定期的に行なわれているのですが、とあるサロンの時のことです。たらふく酒を飲んだ後、いい気分になって自分の席へ戻り、なんとなく会員登録済みのショッピングサイトのパソコン売り場コーナーなんぞを巡ってみたりしていたのです。どうせ買わないからということで、好きなだけスペックや周辺機器を増強したうえで、「次へ」と書かれたボタンをなにげなくクリックしました。そこで僕の目に飛び込んできた画面には、なんと「ご購入ありがとうございました」と表示されていたのです！　この時は本当に驚きましたというか酔いが醒めました。そして数日後にパソコンが届き、まあそこまでは良しとしても、翌月クレジットカードの利用明細が届いたときには、もうなんというか本当に残念な思いをしたものです。

というわけで、このほろ苦い思い出に現れたフォームというのは、ようするにイヤなフォーム例の5なのです。こんなフォームには要注意です。いや、この場合は、よしんば注意していたとしても気づいたときには購入済みだったりして手遅れなのですが。

さて、このようなフォームの挙動で明らかに問題なのは、ユーザーの意識をまったく無視していることです。「次へ」と書かれたボタンでは、購入を確定するということを意識させることはできません。大半のユーザーは、購入手続きの中の一遷移であると感じるでしょう。ウェブサイト側の意図とユーザーの意識とを一致させるには、やはり「購入する」などのように具体的な言葉を示す必要があります。それにより、5のような事態に陥ることを回避できるというわけです。

ところで「次へ」のような送信ボタンで進む先といえば、ふつうは追加入力が必要な場合では第二のフォームのページになるか、もしくはこれで送信して良いかどうかを確認し、誤入力があれば修正のために元のフォームのページへ戻れるような確認ページになるかでしょう。前者の場合は、また改めて「次へ」のような送信ボタンがあるでしょうから、最終的な送信の前には必ず確認画面があるということが、ユーザー側から期待されていると考えられます。

確認画面においては、「この内容で送信する」といった送信ボタンと、もうひとつ「修正する」という送信ボタンが配置されることが多いでしょう。音声ブラウザのように、先に何が書いてあるかの予測がしづらい環境からのアクセスも踏まえると、「修正する」のほうを先に読み上げられるように配置しておくのがアクセシブルです。

【図7】修正ボタンを前に置く

修正を促す送信ボタンを押した場合の挙動には、きちんと値を保持したままもとのフォームのページへ遷移してくれるタイプと、単にJavaScriptなどで履歴をひとつ遡らせているだけのタイプというものが見受けられます。制作側としては、当然のことながら、前者のタイプで実装するようにしましょう。後者はブラウザの戻るボタンで戻っているのと同じであり、環境によってはイヤなフォームの例の4で挙げた現象が起きてしまうこともあります。この現象が発生してしまうと、せっかく確認画面にまで漕ぎ着けるほどに正しくデータを入力してくれたユーザーが、もうすっかり脱力してしまい、ウェブサイトから去ってしまう可能性が急激に高まることでしょう。

そもそもこれは、送信ボタンの意図をきちんと把握していないからこそ、後者のような実装をしてしまう場合があるのです。後者によって実現されるものは、修正画面へ遷移するための送信ではなく、履歴を遡って戻るということに過ぎないのです。ですから、それを正しく理解していれば、「戻る」というようなボタンになるべきなのです。かといって、「戻る」にすれば後者の実装でも良いというわけではありません。制作側もユーザー側も、そのボタンを押すことによって期待しているのは「修正する」ということだからです。

<input type="reset" value="取り消す" onclick="if(!confirm('本当に取り消して良いですか？')){alert('no');return false;}">

<script type="text/javascript"><!--
document.write('<input type="reset" value="取り消す" onclick="if(!confirm(\'本当に取り消して良いですか？\')){return false;}">');
//--></script>

だらだら続けない

たとえばフォームの入力項目が100個もあったら……。僕ならその場で退散したい気分になりますが、どうしても問い合わせなければならないときなどは、やむを得ず入力するでしょう。

冒頭で述べたとおり、フォームの操作・入力というのは結構しんどいものです。面倒くさかったりもします。そんなフォームだというのに、項目がたくさん並んでいたら、それだけで気も滅入ってしまいます。気が滅入るフォームは、まさにイヤなフォームの例の6に該当します。

しかし一見すると項目がたくさんあるものの、実際には入力してもしなくても良い項目というのが点在しているものです。絶対に入力しなければならないものだけを抽出すれば、それほどの数ではないかもしれません。それが必須の項目なのか、それともオプショナルな項目なのかを、すぐに判別できるようにしておくことで、イヤなフォームの例の6だけでなく7の事態も回避できるようになるでしょう。

よくあるのが、必須項目のラベルにアスタリスクなどの記号を添えておく目印です。これは一般的に書籍や用紙のたぐい、いわゆる紙媒体では多く見受ける手法のために、そのままウェブサイトにも転用したというのが始まりなのでしょう。しかし、ホームページ・リーダーなどの音声ブラウザでは、記号類をきちんと発音してくれないことがあります。そのため、アスタリスクなどの記号ではなく「必須」とテキストで添え、発音できるようにしておくことが、アクセシブルなフォームの第一歩といえます。このとき「必須」のテキストは、入力欄よりも手前に書いておきます。これは先ほど送信ボタンのところでも説明したとおり、実際に読み上げられるまでは先に何が書いてあるかを予測しづらい環境でアクセスされる可能性に対応するためです。項目のラベルによって何を訊かれているのかを知り、続いてそれが必須かどうかがわかり、そして初めて入力に移るという、脳内での理解と同じ順序にするわけです。グラフィカルブラウザによるアクセスであっても、考えるのと手を動かすのとが一致することで、利用しやすくなるであろうことが期待できます。

項目の並べ替えが可能なのであれば、フォームの最初のほうに必須の項目ばかりを配置し、オプショナルな項目は後ろへまとめてあげると良いでしょう。その際、全部で何個の項目があるかを明記してあげるとより親切です（同時に、各項目に何番目の項目なのかも併記します）。そして必須の項目群の終わりに、「ここから先の入力は任意です」などというテキストとともに、送信ボタンへのショートカットリンク（ページ内リンク）を設置しておくと、時間に融通の効かない状況でのアクセス時などには有効に働いてくれるかもしれません。もしくは、最初のページには必須の項目だけを用意し、「次へ」進んだ先で、オプショナルな項目を並べるというような遷移にしておくのも良いでしょう。ただしこの場合は、あらかじめ2ページ目にも入力項目がまだあるということを、1ページ目で知らせておく必要があります。

ちなみに、たとえばFAX番号のように、あれば入力して欲しいというような項目の場合も、必須の項目のまとまりに入れることができるといえます。オプショナルな入力項目というのは、たとえば補足コメントの記入欄であるとか、アンケート的な調査の項目であるとかだと考えれば良いでしょう。

このようにフォームを整理していくことで、制作側としては、本当に欲しい情報は何なのかという再確認もできますし、ユーザー側としては、どこに何を入力すれば期待どおりの結果が得られるのかということが把握しやすくなります。

スパム扱いされないようにする

ふつう、問い合わせフォームや会員登録フォームの最後の項目などには、「広告メールを受け取る」というチェックボックスなどが設置されていたりするものです。近年ではデフォルトでチェックが外れており、意識的にチェックしないことには、ユーザーは広告メールを受け取らないようなことになっていたりします。

本来配信しようとしているものは、広告も含んでいるかもしれませんが、スパムではなく何らかの有益な情報を含むお知らせメールだったりもするのです。それを一概にスパム扱いという意識で接してこられては、なかなか受け取ってもらえません。ですから、このメールの配信を承諾することで、いろいろメリットがあることをアピールする必要があります。

いずれにしても、受け取ることを明示させるか、受け取らないことを明示させるか、どちらか按配の良いほうを使いましょう。ちなみにこのような、事前に承諾を得ようとする手法をオプトインと呼んだりします。

【図8】オプトインの例1

【図9】オプトインの例2

ユーザーが広告メールを受け取ることを意識していないのに、広告メールを配信してしまうと、あんなフォームには（ひどい場合は、あんなサイトには）二度と近づかないぞと思わせてしまう可能性があるということです。このとき、注意書きを表示しているか否かはあまり関係ないというところに注意してください。ユーザーが意識するかしないかが肝なのです。なんか知らんけど広告メールが来るようになったなぁと思わせてしまうようでは、イヤなフォームの例の7からは逃れられないどころか、イヤなサイトにもなりうるのです。

なお、このようなメールはいつでも停止できる手段を提供することを忘れてはいけません。

アクセシブルなフォームにしよう！

さて、まとめです。フォームを用意するとき、ここまで説明してきたとおりの考え方で設計すれば、きっとアクセシビリティの高いフォームを作ることができると思います。しかし、どれも「こうしたほうが良い」だの「程度の問題である」だのと、基準としてはいまひとつ抽象的なところに難を感じるかもしれません。もう少し具体的な基準があれば、アクセシビリティを向上させようという試みが、多くの人にとって可能なものとなるでしょう。

そこで、より実装に即したところで、3つのもう少し具体的な基準を提示しておきます。これらの基準を満たしていることが、アクセシブルなフォームのスタート地点になると考えてください。