リセットボタン
「フォームにリセットボタン(type="reset"のコントロール)を設けないのは、意に反して契約の申込みをさせようとする行為に相当するとして、違法になる」という類の記述を、書店でWebデザイン関連の書籍を読んでいて見つけた。
しかしリセットボタンを間違って押した時のリスクは大きく、ユーザビリティとしては寧ろ低下するのではないかと思う。送信のつもりでリセットを押した時の悲劇といったら、かなりものだ。一般的な登録フォームであれば、入力内容全体を修正するケースなど稀だろう。私は基本的に type="reset" のリセットボタンは設置しない方針だ。
上記ガイドラインに抵触しないためには、送信ボタンを押した時に確認ページを一枚用意すれば充分だと思う。
誰が悪いの？
ふとこんな事を考えてみた。
公に勧告された仕様に完全に準拠した文書をWebに公開した。一人のユーザがとあるブラウザでその文書を閲覧しようとしたところ、まともに閲覧できる状態ではなかった。このユーザはサイト作成者に対してクレーム・メールを送った。果たしてこれは誰が悪いのだろうか。
- 1．そのブラウザに対する適切な配慮を行なわなかったサイト作成者が悪い。直ちに内容を修正すべき
- 2．仕様に準拠しなかったブラウザベンダが悪い。新しいバージョンでは改善すべき
- 3．そんな屑ブラウザを使用しているユーザが悪い。見たければ、もっとまともなブラウザを用意すればよい
模範回答は2．の「ブラウザベンダが悪い」だろうけれども、例え次のバージョンで問題点が改善されたとしても未だバグブラウザは世間に出回ったままである。いまさら批判したところで、過去に配布されたアプリケーションを取り戻す事は出来ない。
3．の「ユーザが悪い」は恐らく違うだろう。そういう一面もあるかもしれないが、基本的にそれは「このサイトはIE5.5以上で見てください」と同じ主張である。そのブラウザが仕様に準拠しているか否かは、殆どのユーザにとってはどうでもいい事で、ただ自分のブラウザで表示できないという事実に対してのみ腹を立てる。ましてや、それが半数以上のシェアを占めているブラウザならなおさらだ。
つまり消去法で行くと、結局作成者側がそのツケを払わされる事になるのだ。それは時にコードを2倍書いたり、判別したり、バグを逆手に取ったりによってである。
過去のブラウザに対する最低限の配慮は、やはりある程度しなくてはなるまい。それは義務ではないかもしれないが、Webに公開する上での責任ではあると思う。
さて今回言いたかった事は、そのようなブラウザに対する配慮は果たして「ユーザビリティ」や「アクセシビリティ」の項目に含まれるのだろか。少なくとも、その手のガイドラインに代替手段の提供はあってもブラウザ判別のススメは書いていなかったような気がするのだが。
mailto:リンクのアンカーテキスト
メールアドレスに対するリンクのアンカーテキストには、直接のメールアドレスを用いることが一番望ましい。つまり、
<a href="mailto:[]m_juryoku@yahoo.co.jp[]">無重力</a><a href="mailto:[]m_juryoku@yahoo.co.jp[]">[]m_juryoku@yahoo.co.jp[]</a>まず、その方がメールアドレスに対するリンクである事がわかりやすいという点である。2002年 ウェブ・デザインの間違いトップ10にある通り、思いがけないところに仕組まれたmailto:リンクはユーザの期待を裏切る事になる。
人名をクリックしたら、人物紹介ページに行くのが普通だ。
そしてもう一つ、ユーザが必ずしもブラウザにメール送信クライアントを設定しているとは限らない。セキュリティの問題性からそうしている人もいれば、ブラウザ上で操作するメールサービスを利用している人もいる。
そういう人にとって、mailto:を設定したアンカーをクリックしても殆ど無意味である。そこに書き込まれたメールアドレスをコピーし、貼り付けるという作業を行わなくてはならない。IEの「ショートカットをコピー」がリンク先のURLをクリップボードにコピーするコマンドである事に気付かない人は、アンカーテキストとして明示されていなければメールアドレスを知るのは困難である。
実際、私は以前ステータスバーに表示されるメールアドレスを必死に書き写していたものだった。細かい事かもしれないが、意外と障害になりやすい部分である。
<a>お問い合わせは []m_juryoku@yahoo.co.jp[] まで</a>大手サイトの標準的なスタイル - 横幅指定と大仰なナビゲーション -
横幅指定
最近どうにも私の中で、テーブルでしっかり 800 px に横幅指定されていないと大手企業のサイトに見えない、という感覚が現れ始めてきた。理想的なスタイル、つまりリキッド・レイアウトのサイトでは、ふとどのくらいの規模の企業か疑ってしまう。大変悪い傾向だ。固定的なデザインでは、ユーザのあらゆる環境に対応しきれない。低解像度のデバイスでは横スクロールが出るし、広い画面領域を持つ PC では左右がまるでがら空きだ。さらに悪い事に、そういうデザインのサイトに限って文字サイズが固定されており、そして目を瞬かせるほど小さい。
Jakob Nielsen のこの言葉を思い出した。
60〜90％の大手サイトが、ある一定のやり方を採用しているなら、それは強い慣習と考えるべきだ。そして、ユーザビリティ測定で50％以上優れているという結果が得られない限りは、これと違ったデザインを採用してはならない。
統計を取ったことが無いのでわからないが大手企業サイトの現状を見る限りはおそらく、このランクにまでは横幅指定が来ていると思われる。たしかにそれは「強い慣習」と呼べるだろう。そこで問題となるのが、リキッド・レイアウトが「ユーザビリティ測定で50％以上優れていると証明できるか」どうかである。
私は確かに流動的なデザインのほうが優れていると信じているし、その裏付けもある。しかし依然として固定的なデザインは増えつづける一方。いくつかの Web デザイン指針の中には、「一行の文字数を x 文字に抑えるべきである」というのを見かける。
流動的なデザインを好む人はいる。だが一方で、固定的なデザインをより見やすいと判断する人もいることは確かだ。そしてそれは数にして、後者の方が多いのでは無いかという疑惑さえ抱き始めている。そうなれば少数派は妥協し、嫌ならユーザスタイルシートでも使いなさい。などと言わなくてはならなくなるのだろうか。
これ以上の拡大が食い止められないならばそれはデファクト・スタンダードとなり、我々もそれを採用せざるを得なくなってしまうかもしれない。
大仰なナビゲーション
企業サイトのもう一つの特徴として、「全てのページに割り当てられたグローバル・ナビゲーション領域」が挙げられる。私はグローバル・ナビゲーションが概ね嫌いだ。大抵凝ったデザインをしているため表示に時間が掛かり、回線の細いマシンにとって致命的なレスポンスの低下に繋がる。貴重な画面領域を削り、本文と殆ど関連のないリンク群で埋め尽くされるのだ。またバナー広告と競い合うようにその存在を主張したがるので、まるで本文に集中できない。
一番肝心なところは、それらのリンクをクリックする確率が極めて少ないという点だ。
ユーザは派手なデザイン領域や、ある特定の位置（特に画面上端）に存在しつづける要素を無視する傾向がある。これは広告がもたらした功罪とも言えるだろう。凝りすぎたグローバル・ナビゲーションは、かえってユーザのためにならない。
よりシンプルなもの、つまり現在位置がわかり、あとは左右上方に対するリンクを用意するだけで充分だ。デザインにはわざわざユーザを惑わすような画像を用いずに、簡単なリストやパン屑ナビゲーションを用いると良いだろう。最後の手段として、自由に切り離せるフレームを用いるのも一つの手だ。
しかし残念ながら、グローバル・ナビゲーションも現在標準的なものとなりかけている。わざわざインデックスページに戻るという手間を煩わしく感じ、それを好む人もいるのだろう。確かにそういう人から見れば、グローバル・ナビゲーションが無いサイトは「ユーザビリティの低いサイト」に見えるだろう。
グローバル・ナビゲーションにも利点はある。つまり、どこへでも行けるという便利感だ。しかし行くべき選択肢が多いほど、より迷いやすいという傾向もある。
その辺りをよく検討した上で、導入を考えた方が良いのかもしれない。
長い URL と検索エンジン
紙媒体や電話口などを用いて特定のサイトを紹介する場合、長ったらしくて間違えやすい URL より「〇〇というキーワードで幸運を感じてくれ」と言ったほうが余程伝わりやすかったりする。
それを考えるならば、無理をして短いドメイン名を取得しようと躍起になるよりも、サイト名をユニークなものにし、検索エンジンの上位を狙うほうが現実的だろう。正直私がアドレスバーに 1 から URL を打ちこむ時なんざ、たまに Yahoo を覗きに行く時ぐらいだけだ。URL が長かろうが短かろうが、程好いキーワードを思いついてお尋ねするか、信用あるリンク集を覗きに行くほうが多い。
URL を一字一句覚えさせるなんて、ユーザにはあまりに酷過ぎる。それが例え15文字以内に収まるものであってもだ。折角ドメイン名を覚えたとしても ".com" なのか、".co.jp" だったか、".org" であるかなんて思い出せるはずがない。Google で見つからなければ自分の絶対リンク感を疑うか、はじめから無かったものと見なすしか無いだろう。
こういうナビゲーションの仕方はどうだろうか。「このサイトはキーワード〇〇で幸せになれます。」*1
*1:ちなみにこの日記はキーワード「猫式」で幸せです
ソースを隠す方法
一部の初心者にやたらとソースを隠したがる傾向が見受けられるのは、割と自然なことだと思う。多くのアプリケーションの使用承諾条件にも、プログラム内部を解析するなという項目があるし。多分それと同じことなのだろう。
しかし HTML に関して言えば、ほとんど不可能といっても良いだろう。HTMLソースを見られないようにする方法というサイトで事細かくされていた。結論から述べてしまえば、何れの方法もユーザビリティを大幅に低下させるだけということだ。
折角なので、上記のサイトに載っていなかった方法を2つほど。
XSLT を用い、キャッシュを無効化
クライアント側で XSLT させれば、生成後の HTML ファイルを見られる可能性は低い。キャッシュにも残らない。さらにキャッシュを無効化させておけば、IE で「ソースの表示」を行なっても「XMLソースを表示する事が出来ません」というエラーが出てキャンセルされる。
もちろん XSLT 非対応のブラウザでは、まともに閲覧する事が出来ない。
全部 DOM で生成
全ての要素・属性を一つ一つ DOM でノードから作成し、文書として書き上げる。解析するのも大変だが、作成するのはもっと面倒。
DOM 非対応ブラウザや、スクリプト無効化しているユーザなどはそっちのけ。
ちなみにこれは、アドレスバーに javascript:alert(document.documentElement.outerHTML) で一発です。全く使い物になりませんのであしからず。
