フォームは送信してもらえばこそ

実践アクセシブルHTML 第三回

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

フォームとは、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で挙げた現象が起きてしまうこともあります。この現象が発生してしまうと、せっかく確認画面にまで漕ぎ着けるほどに正しくデータを入力してくれたユーザーが、もうすっかり脱力してしまい、ウェブサイトから去ってしまう可能性が急激に高まることでしょう。

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

だらだら続けない

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ひとつのラベルにひとつの入力

HTML 4.01の仕様書には、LABEL要素を用いたラベルとコントロールとの関連づけのやり方が書かれており、すでに説明したとおり、明示的なものと暗示的なものの2通りがあるとされています。

明示的な関連づけの際に使われるfor属性の値は、IDREFの型をとります。IDREFとは、他の要素の属性で定義された単一のIDトークンへの参照です。つまり関連づけられるひとつのコントロールがともなうid属性の値が、LABEL要素のfor属性に入るということです。似たような型にIDREFSというものがありますが、これは複数のIDトークンへの参照になります。for属性はIDREFSではなくIDREFの型をとりますので、ひとつのコントロールしか関連づけることができないということです。

また、暗示的な関連づけでは、LABEL要素の中のテキストがラベルとされ、同じLABEL要素の中にあるひとつのコントロールに関連づけられます。このとき、for属性をともないません(ともなってもいいのですが、LABEL要素の中にあるコントロールがともなっているid属性の値でなければなりません)。そして、LABEL要素の中に複数のコントロールを入れることもできません。

LABEL要素による関連づけには、このような制約がありますが、これを遵守することで、ひとつの入力欄には必ずひとつのラベルがあるということになり、その入力欄が一体何であるかを把握しやすくなります。

ようするに、ひとつのラベルに関連づけたいコントロールが複数あったら、必要なラベルが欠落しているか、もしくは余分なコントロールが存在しているか、そのどちらかであるといえます。ちゃんとすべてのコントロールに、1対1の関係でラベルが関連づけられているかどうかを基準にすることで、そのフォームのアクセシビリティを確認することができるというわけです。

たとえば、よくある電話番号の入力欄で考えてみます。

【図10】ありがちな電話番号入力

「電話番号」というラベルに対して3つのコントロールがあります。ひとつのラベルはひとつのコントロールにしか関連づけられないので、これではマズイといえます。2つある「-」がそれぞれのコントロールに対応しているといえば、まあそうともいえるのですが、その「-」をラベルとするのは結構厳しいものがあります。「-」単体としてみると、それは記号でしかなく、コントロールが何であるかの意味を説明していないからです。ほかの言い方をすれば、アクセシビリティといえばという勢いで引き合いに出されるホームページ・リーダーなどの音声ブラウザでは、「-」単体は読み上げられない傾向にありますから、ブラウザによっては表現されないということでもあります。したがって、「-」単体はラベルとして不適切であると考えられます。

電話番号の「-」で区切られる3つの番号群は、実は「市外局番」「市内局番」「加入者番号」です。これを明示すれば3つのコントロールで表現するのが、むしろ正しいカタチであるといえます。

【図11】3つにちゃんとラベルをつける

しかしはたして、このように電話番号を入力しろといわれることが、ユーザーにとって近づきやすいことなのか、どうでしょう。電話番号を3つに分割して入力して欲しいというのは、システム側の都合である場合が多いでしょう。システム側の都合を除けば、「電話番号」というラベルに対応するのは「市外局番」「市内局番」「加入者番号」を繋げた一連の番号です。

「電話番号」というラベルが適切である場合は、1つのコントロールでその入力を促せるようなフォーム設計になっていることがアクセシブルでしょう。3つのコントロールで表現するならば、「市外局番」「市内局番」「加入者番号」という、それぞれのコントロールに対応したラベルを用意し、かつそれらを「電話番号」という内容のLEGEND要素をともなったFIELDSET要素で囲むというのが、より良い入力欄であるといえます。

ほかには、たとえば「名前」の入力欄がふたつに分かれていたら、きちんと「姓」「名」というラベルを用意すべきか、それとも姓名を分断せずにひとつのコントロールで扱うか、どちらか相応しいほうを採用することを検討できますね。

このように、「ひとつのラベルにひとつの入力」という関係ができているかを見ていくことで、フォームがアクセシブルに設計されているかを判断することができるのです。

無駄な動きのないキーボード操作

コントロールとコントロールの間にリンクが存在していると、操作中に意図せず他のページへ遷移してしまう可能性があります。もちろん、ラベルやコントロールのそばに添えた注意書きだけでは説明しきれないような、その入力項目に関する詳細な説明を用意していることなどがありますので、一切リンクを存在させてはいけないというわけではありません。しかし、そのリンクを配置するタイミングというのをよく考える必要があります。不用意にリンクが挟まっていることで、ただでさえ操作しづらいフォームの操作性を、いっそう低下させてしまうおそれがあります。

ありがちなものとして、ログインフォームが挙げられます。

ログインに必要な情報は、そのフォームを用意しているサイトによりますが、多くの場合はユーザー名とパスワードのふたつでしょう。ユーザー名は、メールアドレスを利用していたりもしますね。

ログインしたいと思っているユーザーは、ユーザー名とパスワードを入力すればログインできると考えているのです。そしてそれらの入力は、キーボードを操作して行なうことが多いわけですが、慣れていればいるほど、ログインの操作はすべてキーボードだけで行なえるようになります。

したがって、

  1. ユーザー名の入力欄をフォーカスさせる
  2. ユーザー名を入力
  3. タブキーを押してパスワード欄をフォーカスさせる
  4. パスワードを入力
  5. タブキーを押して送信ボタンをフォーカスさせる
  6. エンターキーを押してログイン

という一連の操作によってログインすることができるわけです。慣れれば、まさに神の速度でログインできるログインフォームなのですが、しかし実際にはサイトによってはこのふたつ以外の情報の入力を要求することがあるために、5番目の操作が繰り返される可能性があります。そのため、ログインにもたついてしまうことなどがあります。

たとえば、僕もよく利用している関心空間のログインフォームを見てみましょう。

【図12】関心空間でのログイン

ブラウザに認証情報を記憶させてログインを省略するためのチェックボックスは、確かに機能としてはあったほうが良いのですが、ログインのために必要な情報として送信してもらいたいのではないでしょう。ユーザーはログインしたいと思っており、メールアドレスとパスワードを入力すればログインできることを知っているのにも関わらず、ログインを省略するか否かの質問にも答えなければならないわけです。

関心空間に神の速度でログインするためには、以下の操作をすることになります。

  1. メールアドレスの入力欄をフォーカスさせる
  2. メールアドレスを入力
  3. タブキーを押してパスワード欄をフォーカスさせる
  4. パスワードを入力
  5. タブキーを押してチェックボックスをフォーカスさせる
  6. タブキーを押して「ヘルプ」というリンクをフォーカスさせる
  7. タブキーを押して「ログイン」ボタンをフォーカスさせる
  8. エンターキーを押してログイン

送信ボタンの前にチェックボックスとリンクがひとつずつあるために、操作が2ステップ増えてしまうわけです。

このチェックボックスによって提供される機能は便利なものですが、個人用のパソコンを使用していないときなどには不要な機能でもあります。そもそもログインに必須の情報でもありません。そして送信ボタンのラベルは「ログイン」ですから、ログインのために必要な情報だけを入力してもらうことで、送信ボタンのラベルが意図どおりとなります。

ログインフォームの意図を踏まえると、ログイン省略機能を実行するためのフォームは別に用意したほうが良いかもしれません。しかしその機能の実行にメールアドレスとパスワードが必要なわけですから、同じようなフォームがふたつ続いてしまうことで、逆にユーザーが混乱するおそれもあります。したがって、可能であればひとつのフォームにひっくるめてしまいたいところでもあります。

入力に必須な情報を集めて、そうでないものは後回しにするという考え方で配置していけば、操作たとえば「ログイン」ボタンの下(「ログイン」ボタンと「パスワードを忘れた方はこちら」の間)に、チェックボックスやヘルプへのリンクが配置できると考えられるのではないでしょうか。そうすることで、便利な機能をオプショナルで提供すること、神の速度でログインする操作を妨げないことが両立できるのです。

また、この両立を実現することで、必須の入力が何であるかを暗示させる効果も期待できます。通常、フォームはINPUT type=text要素がフォーカスしている際にエンターキーを押すことで送信することもできるため、パスワードを入力した時点でエンターキーを押すことで5~7番の操作をすべてすっ飛ばし、神の速度を更新することができるわけです。しかし、「ログイン」ボタンの前にログインに必要でないコントロールが存在すると、そこも入力しなければならないようにも見えてしまいます。チェックボックスやヘルプへのリンクを「ログイン」ボタンの下へ配置し、オプショナルな項目であることをアピールすることで、安心して神の速度に挑戦してもらえるというわけです。

ちなみに、ログイン省略機能を利用する場合は、チェックを入れた後で「ログイン」ボタンへフォーカスを戻すというやや面倒な手順を含んでしまいますが、この機能は基本的に一度だけ実行するものですから、それほど影響はないと考えられます。

このように、用意したフォームの操作と入力をキーボードだけで無駄なく行えるように、必須でないコントロールが送信ボタンの意図をボケさせていないかどうか、不用意にフォームでないページへ遷移させてしまうリンクが送信ボタンの前に紛れていないかを確認しましょう。送信ボタンまで行き着くためにタブキーを押さなければならない回数が、必要な情報の入力のために配置されているコントロールの数を上回っている場合は要チェックです。あるいはフォームの設計から見直す必要があるかもしれません。

いつだって感謝の気持ちを忘れちゃダメ

そして最後に、ともかくコレです。かなり抽象的な気がしますがこだわりません。

いつも「ありがとう」の気持ちを忘れてはいけないのです。フォームは送信してもらえばこそです。送信してもらうために、アクセシビリティ的な観点だけにとどまらず、気持ちよく入力してもらえるようにするための、あらゆる努力を費やしましょう。そしてそのうえでさらに、大事なあるいは貴重な情報を送信してくださってありがとうという気持ちが必要なのです。

送信されてくるデータは、それが何であれ大切なユーザーからのメッセージです。そう認識していれば、個人情報を入力させるわりには暗号化されていない素のHTTPで送信させるような振る舞いや、送信されてきた内容を漏洩させてしまうなどのずさんな取り扱いはできないはずです。安心して送信してもらえるように、そして送信した後もずっと安心し続けてもらえるようなフォームを設置しなければならないのです。