さて、たまにGoogleで探し物をしている時、昔読んでブックマークした記事に出会って読み返すことがあります。さっきはposition:fixed大嫌い：agendaを読み返していたんですが（内容については一度読んでください）、始め読んだときには、この理由というか補足説明にあるWorld Wide Webはハイパーテキストという概念を応用した「ハイパーテキストアプリケーション」で、ブラウザはハイパーテキストアプリケーションのビューワー。当然ウェブログもハイパーテキストアプリケーションという意味がいまいちつかめませんでした¹ （改めて読んでみたらしっくりきたんですが）。

末尾でも「ページ上部へ移動」とか「スタイルシート切り替え」とか「サイト内検索」とか、本質的にハイパーテキストインスタンスには必要のないものだから。それはブラウザの仕事だとして触れていますが、改めて「ハイパーテキストアプリケーションのビューワ」としてブラウザ側がやるべき領域と「ハイパーテキストアプリケーション」としてのウェブサイトがやるべき領域について考え直さないといけないと思わされました。

ブラウザの役割、ウェブサイトの役割

その各々の役割について考えていた時にInfoperience – ナビゲーションの落とし穴という記事を読みました。ここでは、ナビゲーションをウェブサイト側が担当すると、制作者によるナビゲーションエリアの設計ミスが起こりやすいとしつつ、最後には極論としつつもナビゲーションと内容物を分離するべきではないかと述べています。

ナビゲーションエリアは、ユーザにサイトの基本的な機能を提供するインターフェイスである。しかしそのエリアのデザインを間違えれば、ユーザの操作を不本意に制限してしまうという全く逆の役割を果たしてしまう。

極論から言えば、そもそもコンテンツとナビゲーションを一枚の HTML の中に記述するということ自体が間違っているようにも思えるのである。素のドキュメントとしての価値が下がり、せっかく論理的にマークアップされた文書が、加工・再利用されにくくなってしまう。

また、本来ユーザはサイトの情報構造などというものに興味はない。ユーザは必要な情報を早く見つけたいだけなのであって、すばらしく計算されたサイトの設計などはどうでもよい。ただ便宜上、サイトの構造を理解していれば自分の判断で必要な情報にたどり着けるので、仕方なく全体を把握しようとするだけである。

それと同時に、制作側がどのような順番で情報を見せたいかということもユーザには関係がない。とにかくシンプルな構造にしてさえくれれば、ユーザは好きなようにそれを利用できるのだ。そのためには、ドキュメントは様々なコンテクストや利用方法に耐えられるように、ナビゲーションと内容物を分離するべきである。そして、サイトによって異なる方法で情報構造を示すのではなく、そういった機能は「ブラウザが提供すべき」なのではないだろうか。

Infoperience – ナビゲーションの落とし穴

多様な機器

私はこの意見に賛成です。ブログの普及によってある程度のデファクト・スタンダードができたとはいえ、ナビゲーションの設計が個々人の設計能力に委ねられている以上、その設計ミスにより利用者を迷わせてしまうことは否めません。だとしたら、ウェブページからナビゲーションを分離し、ブラウザの一部として統合・標準化していったらよいのではないかと思います。

そして、その場合のロードマップをこんな感じで考えています。

1. ウェブサイトにおけるナビゲーションの記述方法を仕様として標準化する（HTML5・microformatなどの仕様を活用してなんとかならないか考える）
2. 標準的な仕様・技術が出来ることにより、機械的なナビゲーションの生成（ブログやウェブサイト作成ソフトなど）が行いやすくなる
3. 多くのウェブサイトがその標準に従うようになり、ナビゲーションに関する要素が文書中（埋め込みか参照かはさておき）に記述されるようになる。表示の可否も含め、その表示・動作方法はWebブラウザに委ねられる（後方互換性を考慮し、対応しないWebブラウザのウェブサイト内での表示方法も当面は必要になるでしょう）。

このようにコンテンツとナビゲーションを「分離」、つまり「ハイパーテキストアプリケーション」としてのWebを操作する部分を「ビューワ」であるブラウザ側に委ねていくことで、

• ナビゲーションの一貫性・信頼性が保証できるようになる（サイト毎の一貫性→Web全体での一貫性）
• ナビゲーションが不十分だったサイトにおいても利用者が操作に迷わなくてすむようになる
• “広大な”サイドバーナビゲーション領域が整理され、一画面の本文表示領域が増える
• アクセス環境（PC、携帯端末、プリンター、音声ブラウザ…）や利用者の要求に応じて表示・動作方法を変更（＝最適化）することが出来る

という効果があり、結果として

• ユーザビリティ・アクセシビリティの底上げが図れる
• 機器に依存しないウェブ² へより近づく

ということになります。

「分離」と書いているのは、「コンテンツ」も「ナビゲーション」いずれも一枚の文書中に記述するので分離という言い方はやや不正確かもしれないからと思ったからです。マークアップの観点からは「明確化」と言った方がいいのかもしれません。

ただ、全てのナビゲーションをウェブページから「分離」すればいいわけではなく、サイトイメージの重要な要素である（トップページへのリンクを含む）サイトロゴや、例えばECサイトにおける「買い物かごに入れる」など重要なナビゲーションは、あえてウェブページ中に常時表示させておくことが必要でしょう（特に重要な要素を他のナビゲーションと並列に表示すると、かえってナビゲーションの中に埋没してしまいかねないため）。

「ナビゲーション」とは

さて、「コンテンツ」と「ナビゲーション」と抽象的に書いてきましたが、その「ナビゲーション」は具体的にどういうものを指すのか。本などを参考にしながら、以下のように分類してみました。

モックアップを作る

言葉でいろいろ言っていても伝わらないと思うので、試しにモックアップを作ってみました。なお、このプロトタイプはあくまでも表示の一例であって、実際にはこれと異なった他の表示方法も考えられます（例えばページ分割リンクや関連文書をブラウザ側にではなくコンテンツ直下に表示するなど）のであしからず。

モックアップ例：Apple

今回はAppleのKeyNoteの紹介ページを土台に作ってみました。Appleは割とナビゲーションや構造がしっかり出来ているページですが…

サイト構造をファイラーのように表示してみた例。ページの目次も下部に表示。

サイト構造をデスクトップアプリケーションのメニューバーのような感じに表示してみました。ただ、両者は機能が全く違うので、これも単純に移植するわけにはいきませんが。

ノートPCのページを見たいということで、Appleサイト内を「ノート」で検索。

構造がわかるのであれば、パンくずリストとして表示することも出来るでしょう（現実的にはグローバルナビゲーションなどと両方表示する必要があるでしょう）

分離の恩恵を最も受けるのは、画面領域が限られるモバイル機器かもしれません。ただ、どのように表現するかは工夫が必要ですね。

グローバルナビゲーションは初期状態で展開されているべきと言うことであえて分離していません。ただ、初期状態では小さすぎて構造の把握や移動が難しいので、どうにかしたいは思っています。サイト内検索は検索バーに統合、ウェブ検索と適宜切り替えることができます。

下の目次ボタンか、二本指で左方向にスワイプ（右から左へ指を滑らせる）することで、ページの構造を見ることが出来ます（目次をポップアップさせても良いかも）

視覚化してみましたが、ちょっと微妙かな…

モックアップ例：Liner Note

おまけで当サイト中の記事をでも作ってみました。

記事の一覧は時系列、タグ別、あいうえお順、被ブックマーク数順、被コメント順でそれぞれ表示可能です。スペース的に記事を一覧するというより、前後リンク（コンテキストナビゲーション）の拡張という意味合いで設けました。

サイト内を「サイドバー デザイン」で検索した例

モックとしては作りませんでしたが、その他のUA…例えばプリンターなら印刷用CSSをわざわざ作らなくとも、本文領域だけを印刷することが出来るでしょうし、音声ブラウザはナビゲーションをより効果的に利用することが出来るなどといった効果があるでしょう。

まとめ

繰り返しになりますが、要するにブラウザにサイトナビゲーションを担わせることで、ウェブサイトはハイパーテキストアプリケーションとしての柔軟性・相互運用性を向上できるんじゃないかということが言いたかったのでした。分離まで受け入れられるかは別として（例えばHTML5のように）個々の情報をグローバルスタンダードな意味で明確化して、ブラウザがそれに応じてユーザに適切に提示するくらいの方向性はそろそろ見えてきてほしいと思うところです（上記のナビゲーションは部分的にrel/rev属性で表現可能なわけで、そこから何か始まらないかな）。

その他参考にした記事

• ウェブデザインとは何か（Jintrick Archives）
• サイトのナビゲーションとしてサイドバーを採用すべきでない理由 (agenda)
• 我的春秋: link 要素をナビゲーションに利用することの注意点（改訂）
• link要素覚書
• Webアクセシビリティの未来が見えない（関連記事）

1. Webはハイパーテキストのアプリケーション＝応用、実装例としてのWebという点をど忘れしていたのでしょう‥
2. このような考え方をDevice Independence（機器に依存しない）といいます（神崎さんによる参考情報）
3. この定義だと、ブログパーツやら広告やらはどちらにも属さないのだけど、とりあえずそれはここでは触れないでおく

Webアクセシビリティとは

まず、Webアクセシビリティとは何かというのを、普段の知識やインフォアクシ内のページ、あるいはこのPodcastを聴いて感じたところをまとめてみますと、まず下図のように新聞・雑誌などの紙媒体のコンテンツは制作者が作ったようにしか見ることは出来ないのだけれど、ウェブ媒体のコンテンツは文字サイズを変えたり、反転させたり、色を変えたりと、利用者が読みやすいように利用方法・形態を変えて利用することが出来ます。また、ウェブは必ずしもPCから見られるわけではありません。紙に印刷してみられることもあれば、携帯電話で見ることもあります。WiiなどTVで利用することもあるし、機械に読み上げさせている人もいるでしょう。

Webコンテンツの特性／基礎知識 － Webアクセシビリティポータルサイト『infoaxia(インフォアクシア)』

そのように多様なアクセス方法・表示方法が可能になるのがウェブという媒体の特性で、そうしやすいようにコンテンツ制作者側がきちんと作ったり、ブラウザ（広く言えばユーザエージェント）が機能面でサポートしましょうと。そうした多様なアクセスを考えるときのコンセプトがアクセシビリティ（accessiblity）であると、そういう風に理解しました。

Webアクセシビリティの末にあるもの

ただ、Podcastを聴いていて思ったのは、なんとなくビジョンが見えないなと。

アクセシビリティにはWCAG2.0を始め、いろんなガイドラインがあったりするわけですけど、例えばそれに準拠することで…

• 情報がより伝わるようになります
  • 高齢者が（適宜文字サイズを変えるなどして）コンテンツが読みやすくなります
  • 一般の読者にもより内容が伝わりやすくなります
  • 検索エンジンに内容を拾ってもらいやすくなります（SEO）
• デバイスのアクセス性が向上します
  • PC以外のブラウザ（携帯電話・スマートフォンやTVゲーム機のブラウザなど）でも読めるようになります
  • 弱視者、全盲者の方が（非視覚系UA¹ を用いて）情報を得られるようになります

といったように多様な環境から利用できるようになると言うメリットがあると。しかし、逆に言うとそれだけ？とも思ってしまうわけです。このサイトでは十分ではありませんが、ある程度適切なマークアップに努めているつもりですから、内容もそれなりにアクセシブルになっているでしょうし、携帯電話やiPhoneなどの機器にはその環境に応じた最適化を行い、読みやすい環境で提供しているつもりです。つまり、全てとはとても言えませんが² 、ある程度の水準まではできていると思っています。つまりWebアクセシビリティはすでに前提となったルールであって、これから何を考えていけばよいのかなと思うわけです。

Web標準が当たり前な世の中になった時の戦略 | Web標準Blog | ミツエーリンクス

この話に近いなと思いました。つまり、Podcastで言われていたようにWebアクセシビリティという言葉が無くなった時には、どのような部分にエネルギーを向けるようになっているのかということです。

例えば、ユーザビリティには3つの水準があることがいわれています（図にされたものを引いておくと以下のようになります）

ユーザービリティとユーザー中心設計の発表資料 – ウェブユーザビリティ.JP

この図で言うと、アクセシビリティはこの第一水準をやっとクリアして、第二水準について議論されているように感じて、まだ第三水準のことが話されていない…ビジョンというか未来が見えないというのはこういうことを言うのかなと感じています。

Webアクセシビリティのビジョン小考

では、具体的にどのようなビジョンがありうるのかということを、UA側がどういう機能を持つとよりアクセシブルになるかということを意識しながら少し考えてみました。

普遍的に利用できるサイトナビゲーションバーの実用化

嬉しいこと

サイトをより簡単に移動できるようになり、個々のサイト構造設計の善し悪しに関わらず目的のコンテンツにたどり着きやすくなる

Netscape7 や Opera7beta 以降では、コンテンツ制作者がlink要素を適切に記述しておけば、それに従って
サイトの主要な場所にリンクが貼られたナビゲーションバーがブラウザ側で利用できるようになります。

現状、対応ブラウザが少ないため、制作者側も積極的にlink要素を配置しようというインセンティブもあまりない状況なのですが、対応ブラウザの広がりによってブログツールの対応など実装例も増えていくのではないかと思います。検索ページが明示されれば、ブラウザ側から直接サイト内検索を行うこともできるようになるでしょう。

また、この発展形としてパンくずリストなどの現在の位置を示すナビゲーションもブラウザ側に組み込んでいけばいいのではないかと考えています。

Podcastでも、文字サイズ変更機能はサイト側ではなくUA側で対応する機能と言っていましたが、それと同じ意味で今あるナビゲーションも、サイト独自で行うよりもブラウザ側で普遍的に扱えるようにすることで、よりサイト内での迷子が減らせるようになるかと思います。

利用者自身がウェブサイトを簡単に再設計できるように

嬉しいこと

サイト構造が明確になることで、情報にアクセスしやすくなる

単に反転するとか、文字サイズを変えるという単純な調整ではなく、例えばサイドバーや本文、フッタなどをモジュール化して、それを利用者が好みのレイアウトで閲覧できるように設定できるというものです。

HTML5（現在は草案段階）ではmenu要素やheader要素/footer要素、nav要素などコンテンツをより明確に構造化するための専用の要素が設けられていますが、これを利用して利用者がどのサイトも同じデザインで閲覧できるようにもできるでしょう。

また、通常の縦スクロールに加えて横スクロール読みや、縦書き読みなどが利用者側で選択できるようになれば、個に応じたウェブの読まれ方が広がるかもしれません。

サイドバーにはどんな情報を載せるべきかもよろしければご覧ください。

コンテンツのきめ細かい調整

ただ、そうした大きい意味での調整だけではなく、細かな調整（文字サイズ調整など）にも気を払う必要があると思います。

ところで、このサイトにはレイアウト調整機能を設置していて、文字サイズや行間を変えられるようになっているのですが、その対象範囲は基本的に本文＋コメントだけにしています。

それはタイトルやナビゲーションを拡大してしまうと、全体のレイアウトが崩れてしまって、リンクなどにアクセスできなくなることを考慮してのことです。

先のHTML5の話に関連していえば、本文部分がきちんと構造化されていますから、例えば文字サイズを調整する際は本文の文字サイズだけ拡大、全体を拡大（ズーム機能）などが選べるようになるわけです。よって、大きいサイズで見た結果レイアウトが崩れて情報に気づかない・アクセスできなくなるという事態をある程度回避できるようになるではないかと思います。

まとめ

Webデザインというのは制作者の技量によってバラツキが多いところで、Webアクセシビリティもそれに大きく影響されてきたと思います。構造整理が不完全なナビゲーションなど目的の情報にアクセスするまでに頭を抱えてしまうようなサイトもあるでしょう。優れてアクセシブルな所もあれば、そうでないところも多い。

ナビゲーションやレイアウトをユーザエージェント側から普遍的にアクセスできるような環境を整備することで、Webアクセシビリティのバラツキが無くなるでしょうし、何よりもこれによってユーザ自身がウェブの見方をコントロールできるという考え方が定着すれば、ウェブデザインへの考え方も大きく変わるでしょう。

多様な人・機械が多様な環境から多様な見方が出来るようになる。細かな違いはあれど、Webアクセシビリティのビジョンはこの語の定義を徹底したものになるのだろうと思います。

参考にしたサイト

• 基礎知識 － 『infoaxia(インフォアクシア)』
• ［Web標準の日］資料公開ーセッションD（植木 真さん）
• ハンディがあっても利用できるページづくり：Webアクセシビリティについて

ブックマークコメントへの応答

その前提がまだ低くね？とは思う。その品質はもっと高められるはず。加えて俺らは本当に障害者のニーズを取り入れているのかっていうのもギモン。デベロッパーの虚像とかになってないかな。

id:aratako0さんのブックマーク

前段、突き詰めれば一例として画像の代替テキストをより詳しく記述したり、動画に音声キャプションを付ける必要があるでしょう。しかし、これは、画像置換問題の時にも結論したように、完璧を求めるのではなく、ある程度どこかに一線を設けないといけない話だと思っています（それで飯を食っているわけでもない限りは）。いくらコンテンツがアクセシブルであっても、コンテンツ自身がつまらなければアクセスする価値はありませんよね³ 。

そうではなくて、まだまだ手近な範囲でやってないことがこんなにあるじゃないかということであれば、その旨お知らせいただければ助かります。

後段、確かに障害者がウェブをどのように見ているかというのも総務省の「みんなの公共サイト運用モデル」というコンテンツを見て始めて具体的に知りましたし、直に障碍者の方がウェブを利用していることを観察したことがありません。

そういう意味では仰るとおり、デベロッパーの虚像を基にデザインしてアクセシブルだと言っている可能性は大いにあります（こんなハッキリしない言い方をしているのがその印ですね）。

1. 音声ブラウザ、スクリーンリーダー、点字ピンディスプレイなど
2. alt属性値なんか時々不十分だなーと思いつつ、面倒くさいので少し手を抜いた記述をしたりしますし。今回の記事でも不十分な所もあるでしょう。
3. 別に、俺って面白いコンテンツ書いてるよねという意味ではなくて

巷では、HTMLとスクリプトを分離しようなんて話が盛り上がってます¹ が、その理由の一つとして、javascriptを動作しないようにしている環境でも利便性を確保しようということがあるようです（参照："#" onclickをYahoo UI Libraryを使ってどうのこうの）

同様にjavascriptの利便性に関することで気になるのは、javascript付きのリンクを新規タブ/ウィンドウで開くと空白になってしまい、ほぼエラーに近い状態になってしまうことですね。テストケースで試してみてもわかりますが、a要素のhref属性にURLがセットされていないものは空白になってしまいます。もっとも、これは制作者側がどうこうできる話ではないのでブラウザベンダの対応をお願いしたいところですが。

主要ブラウザのほとんどがタブブラウザとなり、以前よりもタブを使うケースが増えてきたかと思いますが、なんとかしてほしいところです。スクリプトのスの字も知らない方がこういった動作を見るとブラウザが壊れているのだと勘違いしてもおかしくないでしょう。

求められる動作としてはリンク先にURLが書かれている場合は、そのリンク先を新しいタブ/ウィンドウで開いた上で、javascriptを動作させ² 、書かれていない場合はリンク先がスクリプトであって新規タブでは開けないこと、そして現在のタブでスクリプトを実行するか問うダイアログを示す事だと思います。ちなみにFirefoxだと同様の動作を実現するSmart Middle Clickというアドオンがあります。

この辺でUAに求められる動作って仕様に書いてあるんでしょうかね。

1. どうでもいいけど、この問題って不定期に盛り上がりますよね
2. もっとも原則ステートレスなWWWでそんなことをするべきなのかということはあるかと思います

まず、前提としてミツエーリンクスの記事で解説されているとおり、仕様としては非推奨というわけではありません。その上で、リンク先の別ウィンドウオープンに反対する理由は同じ記事中で以下のようにまとめられています。

• 同ウィンドウで開くリンクと別ウィンドウで開くリンクの区別がつけられていないため、ユーザの意図しない動作が起こる可能性があるため
• ユーザがリンク先を同ウィンドウで開く選択権が与えられないため

また、いまさらながら target=”_blank” について – まちゅダイアリーでは新しいウィンドウを開くように指定されていて嬉しいことよりも嬉しくない事の方が大きいと言っていて、その嬉しくないことの一つとしてパソコンに慣れていない人は、ウインドウが複数開くのに慣れていないということを挙げていますが、これは結構大きい理由だと思います（これについては使いやすさを考えてみる（アクティブシニア・シルバー層の現場から）の記事が詳しいです）

ちなみに、PCに割と詳しい層からは個人の使い勝手の観点（リンク集はリンク先は別ウィンドウで開いてくれた方が嬉しいetc）から別ウィンドウを支持するケースもあるようです。

とはいえ、ユーザがリンク先を同ウィンドウで開く選択権が与えられないことがそれほど悪いことでしょうか。

例えば、ECサイトで買い物をしていて、決済中に送料を確認したくなることはよくあります。その時にリンクが同ウィンドウで開けば、決済をもう一度はじめからやり直さなければならない場合もあります（この場合、システムの設計もあまりよくないでしょうが）

もちろん、そういうことを習熟しているユーザは別ウィンドウで開けばよいのですが、一方で別ウィンドウで開くことを知らないユーザもいるわけです。そのようなユーザもいる中で、ユーザにストレスフルな結果を招くリンクを貼ることは危険でもあります。

ですから、ユーザにリンク先を同ウィンドウで開く選択権を与えないことがかえって良い結果をもたらすこともあり、必ずしもそれ自体が悪だとは言い切れないと思います。

この場合、別ウィンドウで開くことがユーザを混乱させることも当然考えられますが、ウィンドウを分けて情報を見分けることもできるのだという考え方自体を学んでもらうのも、そう悪くはないでしょう（もし、ウィンドウを分けること自体が悪であるのならブラウザベンダは新しくウィンドウを作ることを禁止するのが自然でしょうし、ウィンドウのそうしたシステム自体はいずれ学ぶことです）

関連リンク

高齢者のサポート無くしてネットに将来はないんじゃないかな

私の結論としてはmachuさんの言うように、デフォルトでは _blank を指定しないほうが良い。 _blank を指定するのは訪問者の大部分が幸せになれると確信できるときに限るにほぼ同じです。その上で次のようなケースは「リンク先の別ウィンドウオープン」を設定しておくのが良いだろうと思います。

リンク先を別ウィンドウで開くよう設定しておいた方がよいリンク先

• 同じページに戻ることができない不可逆な操作中（ECサイトで決済をしているときなど）における、その一連の操作とは異なるコンテンツ（送料・連絡先など）へのリンク先
• 用語集（＝文中の用語を解説しているページ）へのリンク先
• リンク集¹ など一度に多くのリンク先を開くことが想定される場合のリンク先

このケースにあてはまれば必ず「リンク先の別ウィンドウオープン」を使えばいいと言っているわけではありません。例えば用語解説などは、その情報量が多くない限りは同ウィンドウ内にポップアップする形でヘルプを出すのがユーザのコスト（別ウィンドウの場合、ウィンドウを移す→閉じる→視線を移すというコストが発生する）的にも適切な手法だと思います。

どちらか微妙な場合は、リンク先を同じウィンドウで開くように設定し、別窓で開くことがわかることアイコンに別ウィンドウで開く設定したリンクを併設すればいいんじゃないでしょうか。こんな感じで。

ちなみに、F’s Garageで触れられていますが、ブラウザは別ウィンドウを同ウィンドウで開くように設定できるような機能は積極的に実装していくべきだと思います（Firefox 2.0.1.4は実装してます）

参考リンク

• target=”_blank”に関する議論 – 徒委記
• いまさらながら target=”_blank” について – まちゅダイアリー (2007-06-02)
• target属性の利便性 (kuruman.org > 駄的HTML改善計画)
• 使いやすさを考えてみる。(アクティブシニア・シルバー層の現場から): 別ウィンドウは何故いけないのか
• target=”_blank”は非推奨? | Web標準Blog | ミツエーリンクス

1. 単にあるテーマに基づいて集められたページへのリンク集だけではなく、カカクコムの店舗先リンクなどのようなケースも含みます

レイアウト名	固定レイアウト (Fixed Layout)	可変レイアウト (Liquid/Fluid/Flexible Layout)	弾力的レイアウト (Elastic Layout)
定義	コンテンツの横幅がピクセル値で固定されたレイアウト	コンテンツの横幅が%値で決められ、読者のブラウザ幅によってコンテンツ幅が変化するレイアウト	コンテンツの横幅が文字サイズ（em）で決められ、読者の文字サイズ設定によってコンテンツ幅が変化するレイアウト
サンプル画像
サンプルCSSコード	#container{ width: 800px; }	#container{ width: 80%; }	#container{ width: 50em; min-width: 45em; max-width: 60em; }
メリット	横幅が閲覧者のブラウザ幅に依存しないので、大幅にデザインが崩れることがない	横幅が閲覧者のブラウザ幅に柔軟に変化するので、固定レイアウトに比べるとより多くの環境で読みやすくなる	固定・可変レイアウトでの文字サイズで問題を解消 横幅が閲覧者の文字サイズに従って全体のレイアウトが変化するため、全体としての統一感が増す
デメリット	閲覧者のブラウザ幅が想定したものより狭い/広いと読みやすさを損なう 閲覧者のフォントサイズ環境が想定したものより小さい/大きいと1行の文字数が多すぎ/少なすぎる結果となり読みやすさを損なう	閲覧者のブラウザ幅が広いと1行の文字数が多くなりすぎてしまい、圧迫感が生まれて読みづらくなる 閲覧者のフォントサイズ環境が想定したものより小さい/大きいと1行の文字数が多すぎ/少なすぎる結果となり読みやすさを損なう	閲覧者の文字サイズが大きいと、コンテンツ幅がブラウザ幅を超えてしまい、水平スクロールバーが出るので、極端に読みづらいレイアウトになってしまう 画像サイズが固定値なので、全体のサイズに対して画像が小さすぎたり、大きすぎたりする

要するに、どれも一長一短なわけです。ちなみにエラスティックレイアウトの前者の問題についてはElastic layout – wrong term? > AlastairCで解決法が示されていますし、2xupさんは可変レイアウトにエラスティックレイアウトの手法を織り交ぜて、両者のいいとこ取りをしているようです。

過去の私案

で、私はどうしたか。基本は可変レイアウトベースですが、以下のような工夫を加えています。

1. 最小・最大文字数を設定することで閲覧者のブラウザ幅や文字サイズによって極端に読みづらくなるケースを回避した
2. 横幅に応じて自動的に段組をくむようにして、閲覧者のブラウザスペースを有効活用するようにした（現在は中止しています）
3. ユーザが表示部分を微調整できるように、スライダーで動的に1行の文字数と文字サイズを変更できるようにした

これが当時の解決策でした。でも、本当にこれでいいのかなとは思っていたのですよね。

先日、読者の方とチャットした時に指摘してもらったんですが、まず2点目については幅に応じて段組するというのは読みやすいとは限らないということです。例えばブラウザ幅が広いと2段組、3段組になったりするわけですが、これは現在のウェブページが上から下への一方的な視線移動をするように設計されている中で、上下移動を何回も繰り返すことととなってしまい、手間が増えるのではないかと言うことです。

一方で、段組をせずに最大文字数を設定しておくと、ブラウザ幅が広い場合に余白が大きく出てしまって、画面に大きく無駄な領域が出来てしまいます。もちろん空の領域がないほどいいわけではありませんが、なにか有効活用できないかなとは思いますよね。

そして3点目については、まず私が懸念していたこととして「初めてこれを見た人はこれが何か理解できるだろうか」ということと「果たしてユーザはこれを使っているのか」ということがありました。この辺はユーザテストもしていないので、かなり不安を持っていたところです（ウェブデザインの基本はPDCAサイクルによる改善ですから）。加えて、読者さんには「カスタマイズパネルが邪魔である」という指摘もいただきました。

しかし、これら以前のそもそもの問題として「ユーザによる微調整が必要なのか」という問題もあるのです。つまり、そもそもこういった作業は、ブラウザ側がやるべきことであって、サイト側がやることではないと。なので、私は将来的にはこうした微調整バーは撤廃しようと考えています。

考え中の私案

読者さんとのやりとりの中で考えた結果、現在よりもよりよいデザインをということで考えているのは、閲覧者のブラウザ環境（横幅や文字サイズ）を取得して、自動的にその環境に沿って全ての人にベストとはいかないけど¹ なるべく多くの人にベストである環境を提供するレイアウトです。一言で言うと最適化レイアウト（Optimized Layout）でしょうか。

幸いなことに、Javascriptを使用すれば横幅も、文字サイズも取得できるようです² 。

具体的には可変レイアウトをベースにし、最小・最大文字数を設定することで一定の環境に対応しつつ、そのような技術で閲覧者環境を取得して、自動調整を進めていくことでデザインの柔軟性を高めていこうと思っています。もっとケースに分解すると以下のような感じです。

閲覧者のブラウザ幅が狭い場合（600px程度）

文字サイズをやや小さめに設定することで、1行の読みやすい文字数を確保する（もちろん、閲覧者のブラウザで文字サイズが切り替えられるようにしておく）

閲覧者のブラウザ幅が通常程度の場合（900px程度）

特に自動調整無し

閲覧者のブラウザ幅が広い場合（1200px程度）

• 文字サイズを大きめに設定することで、1行の読みやすい文字数を確保する
• サイドバーの領域をやや広めに取る

閲覧者のブラウザ幅が広すぎる場合（2000px程度）

• 文字サイズを大きめに設定することで、1行の読みやすい文字数を確保する。
• サイドバーの領域をやや広めに取る
• 視線の上下移動を伴わない範囲で段組を組む

最初に手間をかけるのは少し大変かもしれませんが、一度WordPressのテーマなどのようにテンプレートにしてしまえば、そのテーマの利用者は手間をかけることなく利用者に読みやすい環境を提供できるので、問題無いと思います。

ちなみにFirefox 3ではwidthプロパティが追加されるようで、より柔軟なレイアウトが可能になりそうです。

これからは今の最適幅は何ピクセルかなどという話ではなく、どんな解像度でも快適にご覧頂けますといったような解像度非依存デザインの考え方を基本・前提としてウェブデザインを進めていきたいと思います。

調査の時に見つけたページ

• COULD：固定か可変かそれが問題だ
• ウノウラボ Unoh Labs: エラスティック・レイアウトのご紹介

1. 弱視の方などアクセシビリティ上、配慮すべき方もいらっしゃると思うので
2. 必然的にJavascriptに依存することになりますが、当然ながらJavascriptを利用しなくても一定の環境をサポートできるようにしておかないといけませんね

1. 画像置換問題とは
2. 想定ユーザ像
3. アクセシビリティ確保における優先順位の付け方
4. おまけ

画像置換問題とは

ウェブ技術に詳しい方には耳にタコができるくらい聞いた話ではありますが。

これはミツエーリンクスで解説されている通り、HTML文書でマークアップしたテキストを、CSSで画像に置き換えて表示させる手法で、具体的にはテキストはdisplayプロパティで隠したり、あるいはtext-indentやpositionプロパティを使って画面外に追いやり、画像を親要素の背景画像として表示させる感じで実現します。

このテクニックに対する問題点も同ページで指摘されていて、CSSが有効かつ画像は非表示という閲覧環境において（中略）適用箇所については一切の情報が得られなくなることです。

この功罪については、画像置換の問題点 – てんぽという記事に表でまとめられていて、わかりやすいです。

想定ユーザ像

で、そうしたデメリットに対しての毎度の反論が「どこにそんな特殊なユーザがいるのか」「そんな特殊なユーザは考慮していない」というもので、前者について具体的に考えられるユーザ像を検討してみると、

• ダイヤルアップなどのナローバンドでインターネット接続を利用するユーザ
• モバイル環境などのナローバンド環境でインターネット接続を利用するユーザ
• 印刷時に画像表示を無効にして印刷するユーザ

一番下については、通常読み込むCSSをscreenやhandheldメディアのみに限定して、printメディアには読み込ませないことが対策になるでしょう、また印刷用CSS（media=”print”なCSS）も積極的に使っていくべきです。

前二者は、つまり、表示が崩れないために¹ CSSを有効にするけども、帯域節約のために画像はオフにしておくというユーザです。

このへんはGoogle Analyticsを使っても、そういったユーザがどのくらいいるのか定量化できないので、なかなか議論しづらいところではあります。

また、木達一仁さんは、そのような設定変更を「わざわざ」行う程の知識を持ったユーザは、アクセシビリティが損なわれる危険性をそもそも承知しているはずとの意見を紹介しています。

アクセシビリティ確保における優先順位の付け方

さきの反論の後者のものとも関連しますか、なんというか、これはアクセシビリティ確保に対する優先順位の付け方の問題のような気がするのですね。

というのは、私自身もこうした画像置換の問題は確かにあると思うけども、他にもっとアクセシビリティ確保すべき優先順位の高いものがあるんじゃないかと² 。つまり、全ての環境にアクセシビリティを確保するというのはお題目としては言えても「完璧に確保しようか」となると自ずと限界があります。

だから、比較的技術的に貧弱なUAに対して、配慮すべき一線（あるいは妥協）をどこに設定するかという決断が必要になります。その一線まで優先順位に従って対策を講じて、できる限りのアクセシビリティを確保していくことになるでしょう。

なので、この話からいくと、こうしたユーザに配慮しようというウェブ管理者は、前提としてこれより上位にある対策を既に講じていることになります。

その上での対策ですが、まず(X)HTMLをいじらないというのが大前提です。span空要素やらを付加する方法もありますが、構造記述言語としての(X)HTMLという性格に反しますので。

それで、カラクリエイト：JavaScript-enhanced image replacementを試してみたという記事では、javascriptで画像表示が有効か無効かを判定して、無効の場合、要素に施したプロパティを無効にすることで、テキストを表示させるという手法を提案しています。

記事でも触れられているように、javascript無効の環境ではダメポという問題は含んでいますけども、現時点では有効な対策だと思います。

また、ちょっとマシな画像置換 – てんぽという記事では、絶対配置と配置順序に関するプロパティを利用してなんとかしようという方法もあります。

ちなみにこのサイトでも画像置換を多用していますが、私としては、現時点ではこのようなユーザは一線の外にありますので、なんらかの策を施してアクセシビリティを確保しようという気はありません。ただし、その一線の中では最大限アクセシビリティやユーザビリティを確保していると自負してはいます³ 。

おまけ

ところで、帯域節約のために画像オフにしているユーザに、逆に伺いたいのですが、画像オフってそれほど帯域節約になるんでしょうか？

というのは、例えばうちのトップページは300KBほどあるんですが、そのうち画像は86KBあり、全体からすると30%程度です。多いと思われるかもしれませんが、javascriptはなんかかんやライブラリを読み込んで150KBほどあるのでこちらはおおよそ半分程度あります。

あくまでうちのサイトのことなので一般化はできませんが、画像オフがどれほどの帯域節約になるのかなとは思うところです。

1. テーブルレイアウト+CSSなんてサイトも多いので。mixiなんかはCSSをオフにすると紹介文欄が縦にものすごく伸びます
2. X 8341等に書いてあることなど。もっと言うなら出典のアクセス性を確保するとか、ケータイブラウザなどのUAに適したUIを用意するとか
3. そうでないと思う部分があればコメントかブックマークでお知らせ下さい