Web Archive

ブログでは大言壮語な私ですが、実は現在無職です。昨年3年ほど勤めた制作会社を退職し、フリーの仕事を請ける傍らで転職活動の準備を進めてきました。いくら準備万端にしても、100年に1度の不況と形容されるほどですから、そう簡単に事が運ぶとは思えません。そこで自分自身の振り返りも含めて、この不況を乗り越えるにはどのような能力が必要になるのかを考えてみようと思います。

得意を見つける

実力主義なWeb業界で生き残るためには、何かしらの武器を持っていなければ厳しいですが、逆に仕事さえできれば学歴や資格の有無などは大して影響しないということもいえます。教育環境が整っていて、新卒採用を行う企業もありますが、いわゆる制作会社と呼ばれる企業の多くが即戦力を求めています。最近では、一定期間募集枠を設けるというよりは一年中募集をかけて本当に優秀な人材が見つかった場合に採用を検討するという方式が主流になってきているように思います。

理由は単純に、無駄な人件費を増やしたくないというのと、2004年に労働基準法の解雇条項が改正されたことで、そう簡単に解雇が行えないというリスクもあります。広い裁量権が認められている試用期間であっても、本採用の拒否には正当性が求められるので、企業側も慎重になるはずです。もしあなたがWeb業界への就職、或いは転職を考えているのなら、何か一つでも得意なことを見つけてください。デザイナーであれば、グラフィックデザインが得意、イラストが得意、映像制作が得意、フロントエンド技術が得意など、それだけは誰にも負けないというものを身に付ければ、必ず人事の目に止まるはずです。後はその得意がどのように企業の利益になるのかを上手く伝えることができれば良いと思います。

ノリシロを持つ

以前「Webサイトをつくるコンセプト ～FLASH vs HTMLについて～」でも述べた内容ですが、自分の分野だけに固執せず、広い視野を持って、相互補完しながら取り組もうということです。なぜならWeb制作者は職域が広く、他の職種と深く関わっているからです。それに、プロジェクトという単位でモノが作られる以上、通常一人で完結するということはまずありません。

仕事を受注してから実装されるまでに、あらゆる分野の専門家が関わりますが、『誰のためにどのようなことをどのように伝えるのか』という提供価値、即ちコンセプトとなる部分が明確でなければ、伝わるコンテンツなど出来るはずもありません。『伝えるべきこと』『伝えたいこと』を『伝わる』ようにするには、プロジェクトに携わるスタッフが同じ目的意識を持って取り組まなければ成り立たないのではないでしょうか。

Webサイト構築におけるプロジェクトであれば、要件定義、分析フェーズ、戦略フェーズ、設計フェーズ、実装フェーズ、運用フェーズという具合に、全てのプロセスが時系列に進んでいきます。もしコンセプトがメンバー間で共有されていなければ、次フェーズに進む段階で必ず齟齬が生じてしまいます。では具体的に図を用いて考察しましょう。

以下の図はユーザーエクスペリエンスを構成する要素です。Webサイトは『テクノロジー』『ビジュアルコミュニケーション』『情報アーキテクチャ』という3つの要素によって作られます。

それぞれの要素が独立するとプロセスが『点』になり、次フェーズに進む段階で齟齬が生じ、無理な軌道修正を強いられてしまいます。実装フェーズになって仕様変更や、帳尻合わせが発生し、苦労した覚えのある方は多いのではないでしょうか。例えそのような状況下で形にしても、それはハリボテのような、中身がない『伝わらない』コンテンツになってしまいます。

理想的なのは、プロジェクトに関わるメンバーが相互補完を行うことで、Webサイトの提供価値であるコンセプトが共有され、プロセスが『線』になることです。ユーザーエクスペリエンスを構成する3つの要素が互いに依存し、相関があるように、私たちWeb制作者も互いに補完し合うべきです。先日の「CSS Nite LP, Disk 9」で羽田野氏が『HTML5が出て来たらFLASHがなくなるという議論はナンセンス。得意分野で相互補完』とおっしゃっていましたが、まったくその通りで、お互いを理解する前に技術ありきの考え方をしてしまうのはスマートとはいえません。

コンセプトが重要であるというのを再三述べているのは、そこが明確でなければ『何が必要で何が不要なのか』が分からないからです。また、仮にコンセプトが明確であっても、メンバー同士がお互いの役割を理解していなければ、それこそ好き、嫌いという不毛な議論が発生してしまうでしょう。『最適な選択』を行っていくためには、明確なコンセプトを共有した上で、お互いの役割を理解し、相互補完を行っていく必要があるのです。

一人で全てのことを理解するなんて不可能だと思われた方もいるかもしれませんが、それは当たり前のことで、だからこその『補完』です。プロジェクトで関わるスタッフとコミュニケーションを円滑に取り、かつお互い価値観や考え方、技術に関することまでを積極的に共有することで、お互いが苦手とする部分を補え、かつ認識のずれを早期に解消することができます。

とはいえ、現在ほとんどの企業で『作業効率化のための分業』が取り入れられています。分業すること自体は良いのですが、そのあり方というのは企業によってまちまちで、序盤からプロジェクトメンバー全員でブレストなどを行うところもあれば、設計はディレクター、実装はデザイナーという具合に完全分業しているところもあります。個人的に、後者のやり方はナンセンスだと思っています。なぜなら、最初に述べた通り、Web制作者は職域が広く、他の職種と深く関わっているためです。

運用など、大量生産が必要になる業務においては効率的だと思いますが、1から作る性質の案件に効率を求めすぎても良い結果は生まれないでしょう。転職活動をするにあたり、色々な企業のホームページを拝見しますが、やはり一番重要視しているのはポートフォリオ(ホームページ含)です。Webサイトというモノがユーザエクスペリエンスを提供するメディアである以上、どのようなインタラクションがなされていて、そこにエモーショナルなものがあるか、何をどのように伝えようとしているのか、そしてそれが『伝わるものであるか』という観点から、どのような環境でどのような人達が作っているのかを推測することができます。

食べ物であれば噛み締めて確かにおいしいと判断するように、自己満足であっても、それは自分の動機として十分なものになるのではないでしょうか。少し話が反れてしまいましたが、一つの概念や手法に捕らわれることなく、最適なユーザーエクスペリエンスを導き出すためにはノリシロを持つということが重要になります。そして、それは作品に大きく影響するということだけ覚えておきましょう。

継続する

継続力があるというのは、それだけで十分な武器になり得ます。特にWebという分野はまだ歴史が浅く、新しい考え方や技術が次から次へと出てくる流動的な業界なので『普段から何かを学ぼうとしているか』という部分は重視されることが多いようです。プロダクト業界などでは面接の前に課題をこなすのが当たり前のようですが、Web業界では型にはめられるような判断基準が確立していないため、実績に加えてブログなどのプラスαをアピールできると良いでしょう。

ただ、アピール材料として有効というのは二次的なメリットであって、Web業界で生き残るためには継続力そのものが必須だと考えています。デザイン一つとっても毎年トレンドが変わりますし、フロントエンドにおいては過渡期ともいえる重要な時期に差し掛かっています。そうした時代の変化に合わせて最適なユーザーエクスペリエンスを提供していくには、常に時代のトレンドを把握しておく必要があるので、自分なりにアウトプットする機会を設けるのはとても有意義なことだと思います。

また、Web業界は実力主義であるため、常に同業者＝ライバルという構図があります。認められれば仕事を任されますし、そうでなければずっと泥臭い作業を任されたりもします。そういうところで差をつけるのはやはり継続力に伴う、忍耐力だと思います。物事を継続するにはかなりの忍耐が必要になるので、継続力がある人は大体忍耐力も備えています。例え認められずに泥臭い作業ばかり任されても、そこで腐ってはいけません。何故ならそれを任されたのにはそれ相応の理由があるはずですから、まずはそれを受け入れて、誰よりもその仕事を完璧にこなすことです。三流と言われようとも、全ては『誰にも負けない三流』になってからです。そうすれば誰もあなたを放ってはおかないでしょう。

仕事を楽しむ

得意を見つけるにしても、ノリシロを持つにしても、継続するにしても、やはり楽しんでいるかどうか、それを見出そうとしているかというのはモチベーションを保つ上でも重要なことです。Webサイトの提供価値であるコンセプトを決めるのと同じで、自分が誰のために、何のために仕事をしているのかが明確であれば、『どうするべきか？』という行動力の根源になるものが見えてきます。将来好きな仕事をするために頑張るのでもいいですし、好きな仕事を探すことに頑張るのでも良いですが、とにかく自分が楽しいと思える仕事、環境を見つけることは素晴らしいことだと思うのです。

何だか精神論的な話になってしまいましたが、やはり仕事は人生の大きな割合を占めるわけですから、楽しいに越したことはありません。これはあくまで個人的な感想ですが、いわゆる公務員の方々と比べると我々はプライベートよりも仕事に対して価値を求めてる職種だと思うのです。もっと言うと、仕事を充実させることでプライベートも楽しくなると、そう無意識的に信じている方が多い気がします。少なくとも私はそう信じています。理想はあるけど、現実そう甘くないよというのは誰もが言いますが、何か重要な決断をする時には、自分のことを信じ続けるほかないのです。本当にこの仕事が好きなのか？自分がしたいことは何だろう？と自問自答して、正直な気持ちを受け止めてください。後で後悔することが一番悲しいことです。

最後に、「奇妙な国日本で、これから社会人になる人達へ」という記事で、スティーブ・ジョブスが祝賀式で卒業生に向けて行ったスピーチの内容が掲載されており、非常に素晴らしい内容だったので引用して締めたいと思います。

3つ目は、死に関するお話です。

私は17の時、こんな言葉をどこかで読みました。確かこうでした。
「来る日も来る日もこれが人生最後の日と思って生きるとしよう。そうすればいずれ必ず、間違いなくその通りになる日がくるだろう」。

それは私に強烈な印象を与える言葉でした。そしてそれから現在に至るまで33年間、私は毎朝鏡を見て自分にこう問い掛けています、「もし今日が自分の人生最後の日だとしたら、今日の予定は、本当に私のやりたいことだろうか？」。それに対する答えが"NO"の日が幾日も続くと、そろそろ何かを変える必要があるなと、そう悟ります。

自分が死と隣り合わせにあることを忘れずに思うこと。これは私がこれまで人生を左右する重大な選択を迫られた時には常に、決断を下す最も大きな手掛かりとなってくれました。何故なら、ありとあらゆる物事はほとんど全て...外部からの期待の全て、己のプライドの全て、屈辱や挫折に対する恐怖の全て...こういったものは我々が死んだ瞬間に全て、きれいサッパリ消え去っていく以外ないものだからです。そして後に残されるのは本当に大事なことだけ。自分もいつかは死ぬ。そのことを思い起こせば自分が何か失ってしまうんじゃないかという思考の落とし穴は回避できるし、これは私の知る限り最善の防御策です。

君たちはもう素っ裸なんです。自分の心の赴くまま生きてならない理由など、何一つない。

最低限のアクセシビリティを確保し、高水準ブラウザのパフォーマンスを最大限に発揮させようという『プログレッシブエンハンスメント』という考え方があります。私はこれについて、IEなどの低水準ブラウザでは最低限の見栄えが確保されていれば良いだろうと述べましたが、現実的にそうした考え方を浸透させるのは困難であり、それこそ「単なる理想論」で終わってしまいます。そこで、今一度「現実的な実装案」について考えてみたいと思います。

誰にとっても重要なこと

「どのような人にどのようなことをどのように伝えるか」というユーザエクスペリエンスに基づいて『表側のコンテンツ』は作られます。それは私たちWeb制作者にとっても、クライアントにとっても大変重要なことであり、それが明確でなければWebサイトを作る意味すらないと思います。しかし、人間が十人十色であるように、専門分野が違うもの同士では考え方の違いや齟齬などがどうしても生じてしまいます。こちら側のエゴを相手に押し付けるのも、相手の要望を鵜呑みにするのもあまりスマートとはいえません。現時点で理想が叶わないのなら、実情を把握し、妥協点を見つけることから始めましょう。

私たちにとって重要なこと

プログレッシブエンハンスメントといえば「新しい技術を最大限に生かす」という側面が注目されがちですが、「コンテンツそのものに重きを置き、Web本来の能力を最大限に生かす」という側面も持ち合わせています。Webの世界はグーグルボットに代表されるクローラーというプログラムが、Web上にある文書や画像などの情報を周期的に取得し、データベース化、インデックス化することで成り立っています。要するに彼らはコンテンツだけを求めています。

HTML5では、section、nav、aside、header、footerなど、セマンティックなタグが追加され、より論理的なマークアップが可能になります。これらのタグを利用することで、単純に構造が分かりやすくなるという表面的なメリットだけではなく、クローラーが文書の内容をより正確に収集できるようになり、検索の精度が格段に向上するという恩恵を受けられます。コンピュータにやさしいマークアップは最終的に人間にとってもやさしいものになります。

また、駅に設置されているエレベーターが高齢者や車椅子を利用されている方々だけではなく健常者にとっても便利なものであるように、多様な環境で利用されるWebという世界では、環境に依存しないアクセシブルなコンテンツが求められています。Webサイト上で、情報を発信、普及、収集、要求したりするのには、コンテンツというレベルでの情報提供は必須なのです。

このように、HTML5というテクノロジーを活用してマークアップの精度を高め、アクセシブルなものにするといった『裏側のコンテンツ』が最も重要であると私は考えています。それらを導入することで、すぐに変革がもたらされるわけではありませんが、将来的にWebという媒体が最大限に力を発揮するためのいわば投資のようなものです。皆さんがどうお考えになるのかがとても知りたいのですが、ここではHTML5を活用することを最優先事項として話を進めたいと思います。

一企業にとって重要なこと

TML5やJavaScriptなどの標準技術に基づいて開発されたアプリケーションは、あらゆるデバイスで互換性を持ち、クロスプラットフォームの基盤を作る重要な鍵となります。これが実現するのは随分先のことになるとは思いますが、一部の企業にとっては今すぐにでも取り組むべき重要な課題だと思います。それとは別に、多くの企業では直接収益に影響がでるSEO/SEM、Webパフォーマンスの方に力を入れているように思います。SEO/SEMに関しては、具体的にどのような対応しているのかは分からないのですが(すいません‥)、WebパフォーマンスについてはGoogleが検索ランキングアルゴリズムにサイト応答速度を取り入れるという発表があったこともあり、今後はより専門的な分野として発展していきそうです。

クロスブラウザに関しては重要視しているというよりも、IE6の対応を行うのが当たり前という認識なのだと思いますし、現実問題としてIE6を切り捨てるのは難しい状況にあります。シェアが下がり続けそのまま消えてゆくと思われたIE6ですが、聞いた話によると、ある一定の状態を維持し、それがまだ無視は出来ないシェアを占めているということなのです。単純にIE6以外のブラウザを使うことができない、何らかのシステムにIE6のエンジンを採用している、IE6を拘って使用しているという強者もいるかもしれませんが、とにかくそのような低水準のブラウザでも「高水準ブラウザと同等の見栄えを確保する」という需要はまだまだ根強く残っているのです。

依存する技術とアクセシビリティサポーテッド

では、実際にHTML5を活用するためには、どのようなことに留意しなければならないのでしょうか。まず、IE6ではHTML5で追加された新しい要素を認識しないため、レンダリングが行われずスタイルも適用されません。これを解決するためにはRemy Sharp氏が公開した『html5.js』というライブラリを使用します(適用方法などは「HTML5×CSS3の実装で抑えておくべきこと」へ)。つまり、IE6の環境で見栄えを確保すること即ち、JSに依存するということになります。

2010年に改定されたJIS規格では、『依存しているウェブコンテンツ技術』という章が明示化されました。簡単に言えば、利用者が(JSやFLASHなど)特定の技術を有効にしていることを前提にして制作をしてもよいというものです。では、何を基準に依存する、しないを決めるのでしょうか。そこで同時に明示化された『アクセシビリティ・サポーテッド』という概念があります。

【アクセシビリティ・サポーテッドを満たす条件】

• WCAG2.0やJIS X8341-3に適合していること
• 実装技術、ユーザーエージェント、支援技術の折り合いをつける
• 全方位的なアクセシビリティを確保する

第一に規格で定められた要件を満たす必要があります。ただし、規格には適合レベルというものがあり、最低でもレベルA、可能であればレベルAA、余裕があるならレベルAAAというくらいの感覚で良いと思います。この時点で、JSが無効の場合でもコンテンツが問題なく取得できるように配慮する必要はありますが、基本的に適切なマークアップがなされていればCSSが無効の状態でも正しくカスケードされるはずです。

第二にHTMLやJSなどの『コンテンツ側の実装技術』と、ブラウザなどの『ユーザーエージェント』、音声ブラウザなどの『支援技術』とを鑑みて、依存するかしないかを検討する必要があります。なぜこのような過程が必要なのかというと、規格に適合していても、要件によっては相応しくないケースがあるからです。

例えばIE6での閲覧環境を第一優先にする場合や、障がい者や高齢者の訪問が想定される場合は「依存しない」として従来どおりの方法で実装するべきです。前者はイントラネットを制作する場合などで、クライアント側がIE6をメインに使用している場合、後者は自治体のサイトなどで、スクリーンリーダーや音声ブラウザの利用が想定される場合などが挙げられます。もちろんそれらの支援技術がHTML5の新要素を正確に読み上げられるように改善されれば『依存する』と決定することができます。

第三はそれらの折り合いがついて初めてアクセシブルなコンテンツを提供することができるということです。この「折り合いをつける」という部分は非常に難しいところで、作り手である私たち制作者側とユーザーエージェント、支援技術のベンダー側が歩み寄って意識を共有していく必要があると思います。

CSS2.0でクロスブラウザを実現

アクセシビリティ・サポーテッドを満たし『依存する』と決まれば、JSを利用してIE6でも新要素を認識させることができ、スタイルの適用も可能になります。しかし、CSS3には当然対応していないため、『IE9.js』などのライブラリ駆使しても最低限の見栄えしか確保することが出来ません。上でも述べた通り、現時点ではクロスブラウザの需要が高いということもあり、ここを妥協点とさせていただきます。

私たちが最重要事項としているのはコンテンツの充実であり、進化であって、見栄えに関しては従来通りの方法で実装を行うのが得策だと考えます。妥協点というよりも、あらゆる選択肢の中から最適だと思われる方法を選択しているに過ぎず、時代の変化に合わせて柔軟に対応していくべきことであると考えています。

『html5.js』も日々進化しているようで、最近バージョンアップされたものでは、プリントにも対応しているとのことです。

高水準ブラウザへの対応

CSS3がお預けになり(´・ω・｀)ｼｮﾎﾞﾝﾇ となってしまった方々、ご安心ください。プログレッシブエンハンスメントの考え方に則るなら、今までの経緯は最低限のアクセシビリティを確保していたに過ぎません。CSS2.0で従来通りのコーディングを行う以上、CSS3.0のプロパティをフルに活用するのは難しいまでも、高水準ブラウザ向けに施せることはたくさんあるはずです。

モバイル版Safariしか選択肢がないiPhoneでは、事実上HTML5とCSS3が標準プラットフォームになっているわけなので、それ専用のCSSを用意するのも良いかもしれません。時間やコスト的に余裕がないのなら、ちょっとしたスパイスを加える程度でも良いですが、とにかくCSS3がまるで活用できないということはありません。

あくまで最後の楽しみにとっておく程度にはなってしまいますが、そう遠くない未来、それこそIE9のシェアがIE8を抜く頃には時代は変わっているでしょう。

最後に

ここまできたらお気づきの方もいらっしゃるかと思いますが、見栄えに関しては従来通りの方法で行うというだけで「最低限のアクセシビリティを確保し、高水準ブラウザのパフォーマンスを最大限に発揮させよう」という『プログレッシブエンハンスメント』の考え方にはちゃんと則っています。

私の知識量ではこの程度のことしか思いつかないのですが、もっと良い方法があるという方がいらっしゃればどうぞご教授ください。ご意見なども大募集です。

各々のブラウザがドラフトの仕様を実装している段階とはいえ、既にほとんどの機能が実装できる状態にあります。動向が注目されていたIE9もHTML5のサポートを正式に表明しているということですから、基盤は着々と整いつつあるようです。今回はHTML5でのマークアップ、CSS3でのコーディングを実装するにあたって、何に留意すれば良いのか、現状ではどのような対処をすれば良いのかというところに焦点を当ててみます。

Progressive Enhancement

今までは高水準のブラウザで表示確認を行い、下位ブラウザやデバイスの対応を個別に行うというやり方が主流でしたが、今後は最低限のアクセシビリティを確保した上で、高水準のブラウザ対応を行うという『Progressive Enhancement』の考え方に則って制作する必要があります。現状では、ブラウザによって対応状況が異なるため、全ての環境で新機能を活用することは難しい状況ですが、2010年の改訂版JISによって次世代Webの実現に向けてまた一歩進むことが出来そうです。

依存する技術

現状では、「最低限の見栄えを確保するということ」即ち、新しく追加されたセマンティックな要素が使用できず(低水準のブラウザでは新要素を認識しないため)、結局のところ「現実的な妥協案」にせざる終えなくなります。そこで私が目をつけたのが改訂版JISで明示された『依存しているウェブコンテンツ技術』という章です。

「JIS X 8341-3 改正原案（2009年1月公開レビュー版）」

簡単に言えば、利用者が(JSやFLASHなど)特定の技術を有効にしていることを前提にして制作をしてもよいというものです。ただし「依存している」とするには『アクセシビリティ・サポーテッド』を満たしている必要があります。

アクセシビリティサポーテッド

アクセシビリティ・サポーテッドとは、作成したコンテンツが標準仕様に沿っていて、利用するユーザーがアクセシブルに利用できるかということを指します。これは単にJISに適合していれば良いという話ではなく、コンテンツ側の実装技術とユーザーエージェント/支援技術側の折り合いをつけるという部分が強調されています。

article要素やheader要素などを使用してもIE6ではレンダリングされないため、スタイルを適用することができません。そうしたHTML5の新しい要素やJavaScript(以下JS)などの "コンテンツ側の実装技術" と、ブラウザなどの "ユーザーエージェント" 、音声ブラウザなどの "支援技術" とを鑑みて、依存するかしないかを検討する必要があります。コンテンツを重視するのであれば『依存する』として、JSを有効にしていることを前提に下位ブラウザの見栄えや動作を確保することも可能になります。

現実的な実装案

ここまでは今まで考えてきたことのおさらいでしたが、では実際に使えるJSライブラリが存在するのか、CSS3はどの程度まで使用可能なのか等について、私が得た経験から紹介してみます。

HTML5でのマークアップ

アクセシビリティサポーテッドを満たした上で『依存する』とし、JSの使用を前提にするのであれば、DOM ScriptingによってIE6,7でもHTML5の新要素を扱えるようにすることができます。有名なのはRemy Sharp氏が公開した『html5.js』というライブラリです。実装方法は、以下のようにIE向けに設定するだけで済みます。

<!--[if lte IE 8]>
<script src="./js/html5.js" type="text/javascript"></script>
<![endif]-->

条件分岐の意味は「利用しているIEがバージョン8.0以下のとき」となります。IE9ではHTML5が実装されるということなので、含める必要はないでしょう(皮肉)。

CSS3でのコーディング

こちらも同様、JSの使用を前提にするのであれば対応方法はあります。以前「次世代Web 7つのポイント」で紹介させていただいたCSS3の擬似セレクタに対応するライブラリ『ie-css3.js』は実際試してみるとHTML5.jsと競合してしまうのか機能しなかったので(試用せずに紹介してしまい申し訳ありません)、変わりに『ie9.js』というライブラリを紹介させていただきます。

2年ほど前に、Internet Explorerの動作をW3C標準仕様に準拠させる『ie7.js』というライブラリが公開されましたが、それの最新版が『ie9.js』ということになります。IE5.5からIE6までのHTML/CSSの解釈を調整し、IE7との互換性を確保してくれる『ie7.js』と同様、『ie9.js』はIE5.5からIE8までの互換性を確保してくれるという強力な機能を備えています。ざっと機能を列挙すると、以下のようになります。

• 擬似クラス対応
• 属性セレクタ対応
• 透過PNG対応
• position:fixed対応
• margin:0 auto;対応
• max-height,width対応
• min-height,width対応>
• IE5/6のバグを修正>

実際どうだったかということについてですが、十分使えるというのが個人的な感想です。『ie7.js』が公開されたときは、話題になっているほど万能ではなく、JSを無効にしている場合などが懸念され現場で使用されることは先ずありませんでした。しかし『プログレッシブエンハンスメント』の最低限のアクセシビリティを確保するという考え方に則り、『アクセシビリティサポーテッド』を満たし『依存する』とするのなら問題ありません。高水準のブラウザと同じ見栄えというわけにはいきませんが、最低限の見栄えを確保するのには十分貢献してくれます。実装はhtml5.jsと同様、以下のように設定します。

<!--[if lte IE 8]>
<script src="./js/ie9.js" type="text/javascript"></script>
<![endif]-->

ブラウザ対応

ライブラリによって最低限の見栄えを確保できるとはいえ、HTML5、CSS3の新機能をフルに活用できるかというと現時点ではそうはいきません。要素をアニメーションさせるというのは高水準向けの対応なので論外ですが、要素を横並びにし、高さを調整してくれるboxプロパティや、複雑なグラデーションを画像なしに表現できるgradientプロパティなどが機能しないとレイアウトや見栄えに大きな影響を与えてしまいます。

これについては不本意ながらブラウザ対応という形で対処するしか方法はありません。例えばカラムレイアウトについては、以下のようにie向けのCSSを作成しfloatプロパティを適用する必要があります。

<!--[if lte IE 8]>
<link href="./css/ie.css" rel="stylesheet" media="screen,all" /></script>
<![endif]-->

既存のCSS

body #sampleArea div{
	display:-webkit-box;
	display:-moz-box;
}

IE用のCSS

body #sampleArea div{
	float:left;
}

また、グラデーションについては近似する色をIE向けに指定します。

body{
background-color:#00abeb; /* IE向け */
background:-moz-linear-gradient(top, #00abeb, #fff); /* FireFox向け */
background:-webkit-gradient(linear, center top, center bottom, from(#00abeb), to(#fff)); /* Safari向け */
}

これだけの対応だけ忘れなければ、十分な見栄えを確保することが出来ます。今回はちゃんと試したので間違いありません^^;。もしかしたら近い将来CSS3のプロパティにも対応したライブラリが登場するかもしれませんが、その時はこうした対応も不要になりますね。念のため確認したブラウザは以下になります。

• FireFox 3.6
• FireFox 3.x
• Safari 4
• Google Chrome
• Opera 10.5
• IE6
• IE7
• IE8

最後に

Google Chromeを代表する新時代のモダンブラウザ、既存ブラウザのバージョンアップ、そしてモバイルコンテンツの流行、ネットブックの普及、そしてiPhoneを始めとするスマートフォンの出現など、ここ2年の間に状況は一変しました。そうした時代の流れに合わせて新しい考え方や技術を把握し、あらゆる選択肢の中から最適と思われるプランを最初に実行していくことが次世代Webを引っ張っていく者の役割なのではないかと考えています。最も私などはペーペー中のぺーぺーですが、今回そうした機会を与えて下さった方々にはとても感謝しています。私も少しずつ精進ていきます。

HTML5でマークアップをする機会があったので、まず新しく追加された要素を「HTML5.JP」で調べ、次に「HTML5 Gallery」というサイトでどのように実装されているのかを確認しました。その中でIE6を代表する下位ブラウザへの対応を行っているサイトが多く見受けられたので自分の解釈も含めつつアウトプットしてみます。

ライブラリ

前回「次世代Web 7つのポイント」という記事で述べましたが、いくら「IE6の葬式」が行われたとはいえ、(現段階では)最低限の見栄えは確保する必要があります。HTML5の実装を進めているというIE9の実態は謎に包まれており、IE6～IE8は言わずもがな対応していません。このような状況化で、最低限の見栄えを確保するということはHTML5で追加されたセマンティックな要素が使用できず、結局のところ現実的な妥協案にせざる終えなくなります。そこで私が目をつけたのが改訂版JISで明示された『依存しているウェブコンテンツ技術』という章です。簡単に言えば、利用者が(JSやFLASHなど)特定の技術を有効にしていることを前提にして制作をしてもよいというものです。ただし「依存している」とするには『アクセシビリティ・サポーテッド』を満たしている必要があります。

アクセシビリティ・サポーテッドとは、作成したコンテンツが標準仕様に沿っていて、利用するユーザーがアクセシブルに利用できるかということを指します。これは単にJISに適合していれば良いという話ではなく、コンテンツ側の実装技術とユーザーエージェント/支援技術側の折り合いをつけるという部分が強調されています。

技術をアクセシビリティ・サポーテッドな方法で用いるというのは、支援技術（AT）および OS、ブラウザ、その他のユーザエージェントのアクセシビリティ機能と連携するということを意味する。技術は、アクセシビリティ・サポーテッドな方法で用いられている場合のみ、WCAG 2.0 の達成基準を満たすために依存することが可能である。ただし、何らかの達成基準を満たすために用いられていない（つまり、同じ情報あるいは機能が、アクセシビリティ・サポーテッドな他の方法でも利用可能である）かぎり、その技術をアクセシビリティ・サポーテッドではない（支援技術などと連携しない）方法で用いることができる。

ウェブコンテンツ・アクセシビリティ・ガイドライン (WCAG) 2.0

現状では、ブラウザによって対応状況が異なるため、全ての環境で新機能を活用することは難しい状況です。article要素やheader要素などを使用してもIE6ではレンダリングされないためスタイルを適用することができません。そうしたHTML5の新しい要素やJSなどの"コンテンツ側の実装技術"と、ブラウザなどの"ユーザーエージェント"、音声ブラウザなどの"支援技術"とを鑑みて、依存するかしないかを検討する必要があります。コンテンツを重視するのであれば「依存する」として、JSを有効にしていることを前提に『HTML5.js』を使用し、下位のブラウザの見栄えを保持することができます。逆に下位のブラウザの対応が必須なら「依存しない」として今まで通りの対応をするということになります。

以前「Webという世界ではコンテンツというレベルでの情報提供が必須である」と述べましたが、HTML5で追加されたセマンティクスな要素を使用すれば、情報をより意味のあるものとして定義することができます。それらを導入することで、すぐに変革がもたらされるわけではありませんが、将来的にWebという媒体が最大限に力を発揮するためのいわば投資のようなものです。それに比べてユーザーエージェントや支援技術において問題とされているのは「古いブラウザがあるから導入できない」「新しい要素はまだ対応していない」ということばかりが注目されています。「依存」という考え方が生まれたのも、コンテンツの重要性が認められ、将来的なWebの姿が明確になってきたからだと思いますし、個人的には一歩踏み出していこうよ！という心境です。

やっと本題ですが、IE6～IE8向けの対応として『HTML5.js』を使用しているサイトがほとんどでした。IE9では対応しているものとして扱い、以下のように「IE8以下に適用」という指定をすれば良いと思います。

<!--[if lte IE 8]>	
<script src="./js/html5.js" type="text/javascript"></script>
<![endif]-->

またCSS3の擬似セレクタに対応するスクリプト『ie-css3.js』を使用しているサイトもありました。これも『DOMAssistant』というスクリプトと併用し、先ほどのコメント内に追記するだけです。

<!--[if lte IE 8]>	
<script src="./js/html5.js" type="text/javascript"></script>
<script src="./js/DOMAssistantCompressed.js" type="text/javascript"></script>
<script src="./js/ie-css3.js" type="text/javascript"></script>
<![endif]-->

メッセージ

YouTubeがIE6を代表する下位ブラウザのサポートを終了したのは記憶に新しいですが、最近ではGoogleまでもが段階的に終了することを明らかにしています。さらにTwitter上では「IE6 Must Die」というIE6の撲滅運動が展開されています。サポートを終了することには何の異存もありませんが、使用するユーザーがいる限り、何かしらの対処を施す必要はあると思います。実際に「HTML5 Gallery」で見たサイトのほとんどが下位ブラウザ向けにメッセージを添えています。

<!--[if lte IE 6]>	
<h2>What the…</h2>
<p>Woah—it looks like you’re using Internet Explorer 6 or below. While I salute you for being so staunchly old school, you gotta know that IE6 just can’t display modern sites like this properly. You’re still most welcome here—just be aware that this isn’t how it’s <em>meant</em> to look.</p>
<![endif]-->

日本語では以下のように設定すれば良いと思います。ブラウザのロゴなどを使用して、各ベンダへの直リンクを貼ってあげるとより親切です。

<!--[if lte IE 6]>	
<p id="caution"><strong>あなたは旧式ブラウザをご利用中です</strong>このウェブサイトを快適に閲覧するにはブラウザをアップグレードしてください。</p>
<![endif]-->

サポートしないということ

@import命令を使用して、NN 4.xやIE5.xにCSSを適用しないといった手法はよく知られていますが、これらの対処は表示崩れを回避するために施されているわけですから、サポートしているといえます。つまり、コンテンツ側の技術が有効で、問題なく機能することが前提で作られているので、機能しない下位ブラウザはもう知りません、特別な対処は施しませんというのがサポートしないということになります。「HTML5 Gallery」では以下のようにIE6向けのスタイルを適用しているサイトもありましたが、おそらくこうした対処もされなくなっていくのでしょう。

<!--[if IE 6]>	
<link rel="stylesheet" href="/css/ie6.css" type="text/css" media="screen" />
<![endif]-->

先日、立て続けにセミナーに参加し、改めて今後のWebのあり方について考えさせられました。「これからのWebのあり方について考えてみた。」を書いた時にはまだ知らなかった事実もあるので、要点のみにフォーカスして、もう一度まとめてみます。

新しい技術への姿勢

Developers Summit 2010「次世代web標準 html5 最新動向」では、HTML5に関する初歩的な内容から実践的な内容まで、広く深く学べる貴重な時間を過ごせました。とくに矢倉氏が話されていた「勧告が先だからといって諦めるのではなく、実装されている機能を活用していこう」というお話はとても共感できました。私も以前「私たちがWeb世界を作っているということ。」という記事で「ただ普及するのを待っているだけではなく、新しい技術や考え方があるのなら、どんどん取り入れていこう」と述べましたが、やはり今のWebにはそうしたアクティブな姿勢が求められているのだと思います。

整ってきている条件

これは単なる理想論なんかではなくて、実際にSafari(モバイル含む)のWebKitエンジンでは、HTML5、CSS3の新機能がほぼ完全に実装されています。つまり、モバイル版Safariしか選択肢がないiPhoneにおいては、事実上HTML5とCSS3が標準プラットフォームになっているということになります。それを踏まえると、iPhoneを代表するスマートフォンの普及、iPadという新基準デバイスの出現、これだけでもかなりのインパクトがあります。

また、「When can I use...」というサイトで「HTML5の実装状況」や「CSS3の実装状況」を見て分かる通り、Internet Explorer(以下IE)を覗くモダンブラウザではほとんどの新機能が実装されていることが分かります。Microsoftの次期ブラウザである『IE9』が標準技術に積極的な意向を示していること、IE6のシェアが下がる一方であることを加味すると、新機能を実装するための"条件"が整いつつあることが分かります。

IE6への対応

しかし、現実問題としてIE6などの古いブラウザを無視できないというのも事実です。以前「CSSのあり方について考えてみた。」という記事で「ターゲット外のブラウザでも最低限の見栄えを確保する配慮は必要になるでしょう。」と述べましたが、この時はまだ「Gemination」のように最低限の見栄えは確保し(このサイトの場合は全く異なるデザインを適用していますが)、高水準のブラウザ向けに一部のスタイルを上書きするようなイメージを抱いていました。IE6などの古いブラウザを対象に含める以上、新機能を余すところなく活用するというのは困難と思われるからです。

しかし、先日の「CSS Nite vol.44」で、植木 真氏による「アクセシビリティ」の講演を聴き、もしかしたらすぐにでも動き出せるんじゃないかという可能性を感じました。

依存する技術、しない技術

「2004年版 vs 2010年改定版」というテーマで、10つの要点を話されていましたが、JISがどう変わったのかということは基より、全体の構成がどうなっているのかということまで把握することができ、原案と睨めっこしていた私にとしてはとても身になる講演でした。『WCAG 2.0』を踏襲していること、あえて抽象的な達成基準にしていること、達成等級が取り入れられていることなど、JIS改定の詳細については公開されているスライドを音声を合わせてご覧下さい。

• スライド（PDF、100ページ、1.9MB）
• 音声（MP3、57:01、54.9MB）

「JIS X 8341-3 改正原案（2009年1月公開レビュー版）」も併せてどうぞ。

お話の中で特に印象的だったのは『依存しているウェブコンテンツ技術』という章です。今まではJSやFLASHなどが無効にされている場合の配慮として、代替コンテンツを用意する必要がありました。それは最低限のアクセシビリティ対応として当然のことですが、ここで言いたいのは、特定の技術に依存したコンテンツがNGとされているということです。例えば、JSを使用するのであれば「JSが無効の場合の対応」が必須でした。

しかし改定版JISでは、利用者がJSやFLASHを有効にしていることを前提にしても良いという内容が追加されたのです。特定の技術が利用できる前提とすることを「依存している」といい、前提としないことを「依存しない」といいます。つまり「依存している」とする場合は、JSなどが有効になっていることを前提にコンテンツを作成してもよいということになります。

JavaScriptの活用

現在、先行実装は進んでいるとはいえ、ブラウザによって対応状況がことなるため、全ての環境で新機能を活用するというのは難しい状況にあります。articleやheaderなど、新たに追加された要素を使用しても、IE6で悲惨な表示崩れが起こることは目に見えています。しかし、もし「依存している」としてJSの利用を前提にするのであれば、DOM ScriptingによってIE6,7でもHTML5の新要素を扱えるようにすることが可能になります。有名なのはRemy Sharp氏が公開した「html5.js」というライブラリです。

以下のようにIE向けに適用するだけで済みます。

<!--[if IE]>
<script src="html5.js" type="text/javascript"></script>
<![endif]-->

つい最近までは、このような後方互換のための対応をしても「JSが無効にされていたら元も子もないだろう」という話になってしまい、結局現実的な妥協案にせざる終えない状況にありました。しかし、改定版JISで新たに追加された「依存」という規定によって、新たな展開が期待できるのではないかと思っています。ただし、それには『アクセシビリティサポーテッド』を満たしていることが大前提となります。

アクセシビリティサポーテッド

アクセシビリティサポーテッドとは何ぞやということになりますが、簡単に言えば作成したコンテンツが標準仕様に沿っていて、利用するユーザーがアクセシブルにコンテンツを利用できるのかどうかということです。それには、ブラウザなどのユーザーエージェント、スクリーンリーダーや音声ブラウザなどの支援技術に対して適切なサポートがなされているかということまで含まれます。これについて「アクセシビリティ・サポーテッドという考え方｜ウェブユーザビリティ向上を支援するWebsite Usability Info」で非常に分かりやすい説明がされているので引用します。

1. Webコンテンツ自体が、標準仕様（WCAG 2.0 や JIS X8341-3）で定められたアクセシビリティに優れた方法で制作されていて、
2. ユーザーエージェント（Webブラウザなど）や支援技術（スクリーンリーダーや音声ブラウザなど）がそのアクセシブルな制作物（コンテンツ）を適切に理解、解釈、出力できて、
3. ユーザーがWebコンテンツをアクセシブルに利用することができる。

つまり、コンテンツ側の実装技術と、ユーザーエージェント/支援技術側の対応状況の折り合いがついて、初めてアクセシビリティが実現する、という考え方です。

植木氏も話しておられましたが、JISというのはあくまでガイドラインであって、それに適合していることがアクセシブルであるということではありません。標準仕様に適合しても、ユーザーエジェントや支援技術によって差異が生まれてしまうからです。JSなどの実装技術に依存することなく、またIE6などのエージェントなどに縛られることなく、サイトの要件によって、何が必要で、何が不要なのかを臨機応変に対処していくことがこれから求められていくのではないでしょうか。ガイドラインは、あくまで迷った時に立ち返るところとして、また世界共通のルールとして認識することが大切だと思います。そしてその考え方というのは『プログレッシブ・エンハンスメント』に通じるところがあります。

これからはプログレッシブ・エンハンスメント

以前「Progressive Enhancementという考え方」という記事を書きましたが、この考え方がこれからのWebを象徴していると改めて思います。"Progressive"という言葉には「前進する、進展する」という意味があります。前進する為には、まず目的地を決める必要があります。次世代Webの理想像を思い描いてください。そうしたら、そこにたどり着くにはどうしたらいいのかを考えます。今、何をすべきか。私自身はこういうふうに考えて自分の行動に納得しながら日々を過ごしています。このブログだってそうです。なぜなら、目的地が分かってなければ当然たどり着くことはできませんし、適当に決めて効率よく進んだところで、それは間違った目的地に進んでいることになります。

今こそ、次世代のWebへ向かって歩を進める時ではないでしょうか。

「これからのWebのあり方について考えてみた。」で述べたように、今後のWeb世界において『コンテンツ』が重要な役割を果たすということに変わりはないのですが、だからといって「FLASHは必要なくなる」とか「全てのコンテンツはHTML5でマークアップしておけばいい」ということにはなりません。最近「HTML5 vs FLASH」のような記事やお話を見聞きするのですが、どちらが生き残るのかという観点そのものに疑問があります。

クロスプラットフォームにおいては、HTML5が独占しているわけではないので、"競争"という捉え方もできます。しかし、すでに次世代プラットフォームとして注目されている『WebKit』は言わずもがなHTML5が基盤になっていますし、『Google Chrome OS』はもちろん、Adobe『AIR』、Microsoft『Silverlight』もHTML5に対応する見通です。つまり、HTMLはFLASHを代表するリッチな技術の対抗勢力になるのではなく、アプリケーションを開発する上での標準技術になるというが正しい認識なのではないかと思います。

FLASHも『Flash for iPhone』というプロジェクトを発表していますが、それは「基盤」と「手段」という意味で全く異なる次元の問題です。それはFLSAHが優れていないと言いたいわけではなく、そもそも白黒つけようとすることが誤りなのではないかと思うのです。ここでWebサイトを作る目的について考えてみてください。「私たちがWeb世界を作っているということ。」で述べましたが、誰もがインターネットを持ち歩く時代、もう一つの"世界"といっても過言ではないWeb世界を、私たちが政治家として執政にあたっています。私たちの役割は、率先して市民の声に耳を傾け、ニーズを汲み取り、執行機関の施策に反映していくことです。

つまり「どのような施策を反映させ、国民を満足させるのか」ということが重要であって、FLASHやHTMLというのは、それに応える為の手段でしかありません。先に述べた通り、HTMLはリアル世界でいう国民保険のようなもの(意思に関わらず、住所を有する者であれば必ず加入しなければならない)になりつつありますが、現時点ではFLASHと同様、一つの手段として然るべき役割を担っているといえるでしょう。どちらかがという狭い視野で捉えるのではなく、それぞれの特性を理解して、また共有し合って『ユーザーエクスペリエンス(以下UX)』を創り出すことが本来の目的ではないでしょうか。

ユーザーエクスペリエンス

User Experienceの"Experience"という単語は「経験、体験」という意味合いがあり、直訳するとユーザー体験になります。つまり、ユーザーが製品やサービスなどを利用する際に得られる体験のことをいいます。Donald A. Normanによって提唱されたということもあり『ユーザー中心設計』が基盤になっているUXは、ヒューマンインタフェースやユーザビリティなどよりも広い概念を示すための造語として提唱されました。

どのような違いがあるのかというと、インタフェースにおけるレイアウト設計、色彩計画というのはあくまで"一つの構成要素"であって、それ自体が「体験」を提供しているわけではありません。例えば、ある製品に対してユーザーが形が格好いい、操作が分かりやすいと思っても、それが購買に結び付くかどうかは別の話です。ユーザインタフェースがそうした機能的なものに対してUXは、そもそもその機能がユーザーにとって必要なものであるのかという観点なのです。

大型ショッピングセンターには、カレーを作る為にカレールーや野菜を買いに来る人もいれば、電化製品を買いにくる人など、様々な目的を持ったユーザーが訪れます。カレーの材料を買いに来たユーザーが電化製品を買うということはまず考えられません。仮に電化製品売り場を通りかかる機会があって、いつか欲しいなとは思っても「カレーのついでに買っちゃおう」という人はそうはいないでしょう。かなり無理がある話ですが、もしカレーの材料を買いに来たユーザーに電化製品を買わせたいという目的があるのなら、その場合においてどのような「体験」を与えればユーザーの購買意欲を発起できるのかということを検討する必要があります。

さて、ではカレーの材料を買いにきたユーザーに対して、どのようなインタラクションを提供すれば良いのでしょう。頻繁に訪れている顕在ユーザーであれば迷うことなく目的の商品を見つけることができると思いますが、初めて訪れるユーザーには、何かしらのインタラクションを提供しなければなりません。例えば、普通のスーパーでは商品ごとにカテゴライズがなされており、指標となる目印が設けてあります。その他にもユーザーの購買意欲を発起する為の「体験」として、試食・試飲、医薬品や美容化粧品などのサンプルの提供などが挙げられます。また、ユーザーの性質に関わらず、レジの前に必ずと言ってよいほど置いてあるお菓子や日用品は、誰もが日常的に必要するものばかりが並べられています。

この例でのユーザーインタフェースが、ユーザーを誘導する為の目印や、購買意欲を高める為のサンプル品のことで、UXはユーザーが訪れてから目的を達成するまでの「体験」そのもののことをいいます。どのようなユーザーがいるのか、どのようなニーズがあるのか、何を伝えたいのかなどを把握した上で、どのようなインタラクションを提供すれば満足してもらえるのかという一連のシナリオを組み立てること、上の例でいえばカレーの試食をさせて購買意欲を発起しようなど、「ユーザーが認知する体験のこと」をUXといい、その設計を『ユーザエクスペリエンスデザイン(以下UXD)』といいます。

ユーザーエクスペリエンスの構成要素

先ほど冒頭で「HTMLもFLASHもUXを創りだす一つの手段に過ぎない」と述べましたが、UXを構成する要素について解説したいと思います。以下のモデルは「IA100 ユーザーエクスペリエンスデザインのための情報アーキテクチャ設計」で採用されているものを使用しています。Webサイトは「テクノロジー」「ビジュアルコミュニケーション」「情報アーキテクチャ」という3つの組み合わせでコンテンツが企画され、UXDで一連のユーザー体験を組み立てます。

ユーザーエクスペリエンスの構成要素

【テクノロジー】

テクノロジーは、PCやモバイルといったデバイスを含む「プラットフォーム」、データベースや会員システムなどの技術を含む「サーバーサイド」、そして文書構造を司るHTMLや見栄えを司るCSS、インタラクションを司るFLASHやJavaScriptといった表現技術を含む「フロントエンド」に分けられます。今までも考察してきた通り、今日のテクノロジーにおける進展には目を見張るものがあり、ユーザーに与える体験をより快適なものにしてくれるでしょう。

【ビジュアルコミュニケーション】

ビジュアルコミュニケーションは、サイトの印象や感覚的な表現を司る「アートディレクション」とレイアウト設計や色彩計画などのグラフィカルな表現を司る「グラフィックデザイン」に分けられます。企業ブランドやコンテンツなどを、どのようなモチーフやトーンで伝えるのか、またそれをどのように表現するのかというWebサイトに限らず全ての媒体に必要不可欠な要素です。

【情報アーキテクチャ】

ユーザーが情報探索を行う上で、どのように情報を整理すれば、理解しやすく、利用しやすいものになるのだろうか？という複雑な情報を分かりやすく伝えるための技術です。具体的にはサイトストラクチャ、ラベリング、ナビゲーションの設計によって「情報の組織化/構造化」を行います。Webサイトを作るということは、言い換えれば情報をデザインするということであり、いわゆる『IA』と呼ばれる専門家だけが考えれば良いことではなく、Webに携わる全ての人に必要な要素です。

見つけやすさの重要性

以下の図はPeter Morville氏が提示した「ユーザーエクスペリエンス・ハニカム」です。UXを性質という観点から見た構成要素で、いくつかの性質を同時に満たすことでユーザーの琴線に触れることできると言われています。どの性質を優先するのか、或はさせないのかということを、ビジネスゴールとコンテクスト、ユーザーニーズと行動、コンテンツの有用な混合という観点から鑑みて、バランスの良いコンテンツ作りを目指します。例えば、高齢者のアクセスが想定されるWebサイトでは「好ましさ」よりも「アクセスしやすい」を優先しようなど、避けられない妥協は無意識にではなく意識的にさせなければなりません。

ユーザーエクスペリエンス・ハニカム

役に立つ

図的になされなければならないその商品やサービスが本当に役に立つのか、商品知識や専門的知識を深め多くのユーザーに訴えかける

好ましい

イメージ、アイデンティティー、ブランドが持つ力と価値はバランスを保つことでユーザーの関心を引く

アクセスしやすい

障害を持つユーザーであってもアクセスできることで、より多くのユーザーにリーチする

価値がある

利益を上げ、顧客満足を満たす。利害関係者すべてに価値をもたらす

信頼できる

多くのユーザーに信頼感を与えるデザインである

見つけやすい

ユーザーが欲する情報を迷う事なく即座に見つけられる構造である信頼できる

使いやすい

Man-Machine Interfaceの観点からユーザビリティを考慮する

この性質の中でも、数十億の項目が様々な形で分散して集積しているWebにおいて、「ファインダビリティ(見つけやすさ)」は非常に重要です。どのようにしてユーザーの興味を発起するかというインタラクションや、快適な操作性を提供するユーザビリティの重要性は広く認識されていると思いますが、ファインダビリティはあまり注目されていない節があります。これからさらに情報過多が進み、あらゆるデバイスでインターネットが利用され、Web世界が膨張し続けるということを考えれば、ユーザーのニーズとサイト固有の戦略とを結びつけ、双方のバランスを取り、最適なファインダビリティを提供することがどれほど重要なのかが分かると思います。何故なら、分かりやすさも、使いやすさも、好ましさも、全て見つけられなければ意味をなさないのです。

そういう意味においてサイトのファインダビリティを高めるということは、『SEO(検索エンジンの最適化)』という分野にまで及びます。一部のSEO業者では姑息な手段を使って検索エンジンを騙す手法を適用していますが、検索エンジンが進化し続ける生き物であるということを忘れているのではないでしょうか。一時的に効果があっても、後で取り返しのつかないことになる可能性があります。本質的にSEOを向上させるにはどうすれば良いのかを考え、今ある資源の中から有益なものを活用するしていくという方が、合理的であるといえます。

ノリシロを持つということ

ここまでUXについて述べてきましたが、FLASHやHTMLがUXを創りだす一つの要素でしかないということがご理解いただけたかと思います。私たちがWeb世界を執政するにあたり、一つの概念や手法に捕われてしまっては、物事の本質を見失ってしまいます。何が必要で、何が不要なのかを判断をするには現状を汲まなく把握し、そして把握する為にノリシロを持つ必要があります。「ユーザーエクスペリエンス」で述べた3つの要素では、それぞれのスペシャリストがいるはずです。「テクノロジー」であればマークアップエンジニア、フロントエンドテクノロジスト、フラッシャー、システムエンジニアなど、「ビジュアルコミュニケーション」であればグラフィックデザイナー、アートディレクターなど、「情報アーキテクチャ」ではインフォメーションアーキテクトなどが挙げられます。

もう一度「ユーザーエクスペリエンスの構成要素」の図を見ていただければ分かると思いますが、それぞれの要素は独立して成り立っているわけではなく、それぞれに依存し、また相関があります。つまり、理想的なUXを提供する為には、それぞれのスペシャリストが全体を俯瞰しながらUXDを行う必要があります。例えば、グラフィックデザイナーがパーツを作成する際に、マークアップの知識があればビジュアルと論理構造の相違はなくなるはずです。もう少し噛み砕くと、「資料請求」というボタンを作成するにあたり、論理的意味合いでは重要な意味付けを行っているのにも関わらず、デザイン的な見た目はまるで目立たせていないといった問題は避けられるはずです。また、プロジェクトで進めている場合、スペシャリスト同士のコミュニケーションは不可欠なものであり、それを円滑にさせるにはお互い価値観や考え方、技術に関することまで、認識のずれを出来る限り解消できるに越したことはありません。

構成要素のうちどれか1つを無くしてもUXは成り立ちません。プロジェクトとして1つのサイトを作り上げるのに、全員でUXを創っているという意識があれば、そしてよりユーザーの満足を得られるサイトを作るという意思があれば、自ずとお互いを理解し合える素晴らしい環境が築けると思います。そして、例外なくそうしたプロジェクトは成功しているのではないでしょうか。フラッシャーの人はHTMLの役割を理解し、マークアップエンジニアはFLASHの役割を理解することで、何が必要で、何が不要なのかをお互いの内で共有することができるはずです。繰り返し述べているように、UXは「どのような体験を与え、ユーザーを満足させるのか」という云わばWebサイトの「提供価値」を考えるコンセプトです。FLASHが、HTML5が、という狭い視野ではなく、広い視野を持って取り組みましょう。

「これからのWebのあり方について考えてみた。」で"コンテンツ"の役割を、「CSSのあり方について考えてみた。」では"見栄え"の役割を考えてきました。そして、最後に「JavaScipt」による"ふるまい"について考えていきたいと思います。

クリエイティビティの可能性

Webサイト制作におけるJavaSciptというのは、いわゆる「DOM」と呼ばれるAPIを利用して簡単なギミックを実装する程度のもので、リッチなインタラクションを提供するというのにはほど遠いものでした。しかし、JavaScriptエンジンの高速化が進み、表現力の向上が進展すれば、より"ふるまい"としてのクリエイティビティは格段に進化することになるでしょう。「これからのWebのあり方について考えてみた。」で述べた通り、JavaScriptでネイティブアプリケーションと同等のクオリティを発揮するということは、それだけの「体験」を提供できるということを意味します。Flashを代表するリッチコンテンツ専用の規格と大きく異なる点は、Web標準に準拠した上でリッチなインタラクションと表現力を発揮するということです。

【JavaScriptエンジンの高速化】

JavaScriptは2000年頃に、ECMAScriptの標準化作業に伴ってバージョンアップをするという動きがあり、去年の12月に「JavaScipt 2.0」の仕様策定が完了しました。GoogleやAppleを初めとする代表的なベンダがプロトタイプとして実装を行い、仕様の最終確認、相互の互換性、旧バージョンとの互換性などの検証を経ているので、ブラウザ間の非互換性が大きく改善されると思われます。その他にも「JSON」のサポートが強化され、セキュリティの強化が行われているそうです。

そして最も注目すべきなのは、JavaSciptエンジンの高速化による表現力の向上でしょう。先に述べた通り、Microsoft、Yahoo!、Adobe、Mozilla、Opera、Googleは標準化プロジェクトに取り組みつつも、JavaScriptエンジンの高速化にも余念がなく、事実上の「JavaScript高速化競争」が起きています。AppleはSafari 4で「Nitoro」というエンジンを実装し、Operaは「Carakan」というエンジンを実装中、Firefoxは「TraceMonkey」というエンジンを実装中、そしてGoogle Chromeは「V8」と呼ばれる独自のエンジンを搭載し、その性能の高さは実証されています。

【新しいプラットフォーム】

次世代プラットフォームとして最近注目を集めているのは「WebKit」です。WebKitはすでにHTML5の機能を取り込んでいて、WebブラウザのGoogle CromeやSafari、iPhoneでも採用されているし、Symbian陣営もWebKit搭載に動いているそうです。これが何を意味するかというと、これからはPCがWeb標準を背負ってきた時代は終わり、他のプラットフォームが主流になる可能性すらあるということを示唆しています。

表現力やWebアプリケーション開発フレームワークが貧弱であるHTMLの代わりに、「Adobe AIR」や「Silverlight」、「Flash」などが活躍しているわけですが、オーディオやビデオといったマルチメディア関連機能、Webアプリケーション向け機能が充実しているHTML5がWebKitによって普及すれば、それらの技術は不要になるかもしれません。単純に"ふるまい"という意味でも、「CSS 3」の表現力向上やJavaSciptエンジンの高速化などの発展が進めば、セマンティックでありながらクリエイティビティ溢れるコンテンツを作ることも夢ではありません。

コンテンツと表現の相互作用

では、Web標準に準拠しているということにはどのような意味があるのでしょうか。HTMLが骨格、CSSが外装であるなら、JavaScriptは「体験」を提供します。過去、ブラウザベンダの独自拡張が相次ぎ、意味のないアニメーションやUIを実装したサイトが乱立した関係で、JavaScriptによるインタラクションを苦手とするユーザーは少なくありません。今でもそのようなWebサイトはありますが、それは体験を与えているのではなく、制作者側のエゴをユーザーに押し付けているに過ぎないのです。

体験というのは、ユーザーのニーズや利用状況を把握し、心理状態を理解するという「人間中心設計」と呼ばれるアプローチを行い、その上でどのような体験を与えれば響くのかということを考えて導きだされるものです。これはWebサイト全体を設計する際に必要になる行程ですが、狭義な意味での体験として、いわゆる「ユーザインタフェース(以下、UI)」にも同じことがいえると思います。例えば大型マーケットなどにあるエスカレーターは、ユーザーのニーズや利用状況を把握した上で設置されています。もしもエスカレーターが「動く階段」として飾られているだけなら誰にとっても意味のあるものに成り得るでしょう。これはあまりに極端ですが、そのようなUIが数年前のWeb世界では当たり前のように存在していたのです。

そして、エスカレーターの素晴らしいところは仮に動かなくなっても「人を移動させる」という目的をしっかりと果たすということです。そうしたコンテンツと表現を相互に作用させる操作能力を提供するのがJavaScriptのもう一つの役割であり、Web標準に準拠するということの本質的な意味です。Progressive Enhancementという考え方に基づいて言い換えれば、JavaScriptが機能しなくてもユーザーがWebサイトを利用できるような配慮をしつつも、より快適なUIを提供するということになります。

JavaScriptの実際

CSS以上に利用環境に依存してしまうJavaScriptですが、実はずいぶん前から「unobtrusive JavaScript(出しゃばらないJavaScript)」という考え方がありました。HTMLの要素などに直接JavaSciptを記述せず、外部JSからHTMLソース上の要素に結びつけるという手法です。これによってHTMLの保守性が高まる、JavaSciptがオフのブラウザでも動作する、再利用が容易になるというメリットがあり、ブラウザ対応の振り分けも容易になります。つまり、JSをオフにしているユーザーには最低限のインタラクションを提供し、高水準のブラウザを利用しているユーザーや高機能デバイスを利用するユーザーには、よりリッチなインタラクションを提供するということが可能になるのです。

「Graceful DegradationとProgressive Enhancementの実践 | Web標準Blog」で、オンラインショッピングの決済画面などによくある「印刷するボタン」をProgressive Enhancementなアプローチで実装するという事例があるので、引用します(この辺りは他力本願で申し訳ありません；)。

Progressive Enhancementは、最低限提供したい機能や目的を「ベースライン」として設定します。印刷リンクは「ページを印刷したいというユーザーのニーズに答える」ことが目的ですから、まず「ページの印刷について言及する」ことをベースラインとしましょう。

まずは、最低限提供するべき内容を定めています。ここでは以下のような形で「印刷して保管できます」ということを文章で伝えています。

<p id="printthis">Thank you for your order.
 Please print this page for your records.</p>

では、次に実現したいことをどのように実装するのでしょうか。以下のようなスクリプトで、ブラウザが必要な機能を満たすときのみ、印刷ボタンが表示されるようにしています。

<p id="printthis">Thank you for your order.
 Please print this page for your records.</p>
<script type="text/javascript">
(function(){
  if(document.getElementById){
    var pt = document.getElementById('printthis');
    if(pt && typeof window.print === 'function'){
      var but = document.createElement('input');
      but.setAttribute('type','button');
      but.setAttribute('value','Print this now');
      but.onclick = function(){
        window.print();
      };
      pt.appendChild(but);
    }
  }
})();

</script>

この手法は、印刷リンク(ボタン)だけではなく、文字の拡大縮小インターフェースなどにも利用することができるでしょう。まずブラウザーの文字サイズ変更機能について言及し、インターフェースをあとからJavaScriptで組みこむのです。

矢倉さんが述べている通り、まずはその機能が本当に必要なのか？を言及する必要があります。「コンテンツと表現の相互作用」で述べた通り、「体験」とは必要なことだけを考えていれば良いということではなく、提供しなくて良いことも明確にした上で、どのような体験を与えれば響くのかを考えることに意味があります。つまり、制作者側がやりたいだけのエゴを押しつけるのではなく、ユーザーを理解した上で必要な機能を提供するということが大切なのです。ユーザーが理解出来ているのなら、「何が必要か」だけではなく「何が不要であるか」も明確になるはずだからです。

最後に

3回に渡って「○○のあり方について考えてみた。」について自分なりに考察してきましたが、ただインプットを行うのと、アウトプットをするためにインプットするのとでは、全く意味が異なるということが分かりました。前者はインプットすることが目的なので、一時的に満足はするもののすぐに忘れてしまいます。後者はアウトプットをするためにインプットを行うので、一度頭の中で情報を整理し、まとめるという作業が必要になります。色々な記事を参考にしながら書かせていただきましたが、自分の血肉となった感じがしています。今後も定期的に更新をしていこうと思いますので、よろしくお願いいたします。

Web標準について思うところがあったので、自分の意思確認のためのアウトプットです。

Web標準とは

Web標準とは、W3Cによって規格化されている標準技術のことを指します。構造的かつセマンティックなマークアップ、見栄えをCSSで制御する手法で実装を行うことで「CSSのあり方について考えてみた。」で述べたような技術的なメリットが得られるだけでなく、ブラウザサポートの改善、ノウハウの普及、学習コストの低下などにも繋がります。

また、Webの利用者に占める高齢者やハンディを持つ方々の割合が高まり、Webアクセシビリティの重要性が広く認知されてきています。2008年12月に、草案の段階から多くのフィードバックが寄せられていた『WCAG 2.0』が勧告され、Webアクセシビリティのガイドラインとして広く利用されています。JIS規格もWCAG 2.0と調和するよう改訂が進められているそうです。

広義なWeb標準

このように、XHTML、HTML、CSSなどの標準技術をWeb標準とすることが一般的です。その通りなのですが、個人的にはもう少し俯瞰した捉え方もあるのかなと思っています。些か極論ではありますが、広義な意味でのWeb標準とは、Web世界で暮らす為のルールであるということがいえるのではないでしょうか。私たちが暮らすリアル世界では、信号が赤になったら止まる、青になったら進むというルールがあります。私たちは産まれたその時から、そうした「常識」の中で成長するため、当たり前のようにそれらを身につけていきますが、Web世界はまだ十数年しか存在していないため、ルールがなければ誰もが好き勝手に道路を渡り、事故が多発するような世界になってしまいます。

このまま、この例え話に興じるなら、Web世界の政情を司っているのがW3Cという国家組織で、学校で使われる教材が文部科学省の検定を受けているのと同じように、W3Cという組織では、仕様の策定が行われています。その中にはTim Berners-Leetという総理大臣がおり、Apple, Google, Microsoft, Mozilla, Operaといったブラウザベンダーを始め、幅広い分野の企業が閣僚として参画しています。そして、その国の執政にあたるのが国会議員であり、実際にWeb世界において権力を持っている方々はそれに当たります。彼らは率先して市民の声に耳を傾け、ニーズを汲み取り、執行機関の施策に反映していかなければなりません。

そうした地位にいる人はほんの一握りで、私を含め殆どの人は毎日のように政治家活動を行っている立場です。中にはいわゆる政治活動家として暗躍されている方もいるかもしれませんが、政治活動を行っていることに変わりはありません（語弊があると難なのですが、あくまで例え話です）。重要のは私たちがWebを生業としている限り、Web世界における政治家としての責任があるということです。以下、Wikipediaから「政治家に求められる資質」を引用します。

マックス・ヴェーバーは、「政治家の本領は『党派性』と『闘争』である」と指摘している。そのうえで、政治家に求められる資質として以下の3つを挙げている。

• 未来を構想しながら、現実を変革していこうとする情熱
• 現状をいまそこにあるままに、しかも一定の距離感覚をもって理解できる洞察力
• 政治がときには暴力を手段として選ばざるを得ないことを踏まえた結果責任への自覚

リアル世界でも政党があるように、Web世界でも様々な主張があります。HTML5に関する主張をする人もいれば、方やRIAに関する主張をする人がいます。個人で活動するタフな人もいるかもしれませんが、大体は同じ主張を持つ者同士が組織を作り、目標の実現に向けて切磋琢磨するはずです。私個人の話で言えば、Web制作者である以上、今ある現状を受け入れ、どうすればより良くなるのだろうか？と試行錯誤し、自分の判断が時には悪影響を及ぼす可能性があるという責任感を持って取り組み、未来を構想しながら現実を変えようとする姿勢を保ち続けたいと思っています。

とまあ、例えが分かりづらい上にかなりの極論になってしまいましたが、要するにWeb標準というのは、私たち次第でどうにでも変えられるということです。当時は理想論だと言われていた標準技術も、今ではWeb制作におけるデファクトスタンダードになっています。CSS 2.1においては、未だ勧告もされていないのにも関わらず、ブラウザで実装されているモジュールは積極的に利用され、IE6などの旧ブラウザのために、解釈の違いを逆手に取った『CSSハック』と呼ばれるテクニックなども生み出されていきました。CSSハックは標準技術ではありませんが、特定のブラウザのレンダリング処理を補うためには必要なものであり、Web標準が普及する上で暗躍してきました。

CSSハックや、こうしたクロスブラウザありきの考え方の善し悪しは置いておいて、ただ普及するのを待っているだけではなく、新しい技術や考え方があるのなら、どんどん取り入れていこうという姿勢が大事だと思うのです。Web標準はあくまで"標準"なので、決められたことは是が非でも守らなければならないというような厳格なルールではなく、ガイドラインとしての大まかな指針という認識で良いと思います。いわゆる「勧告」というのはISOやJISのような標準規格とは異なり、デファクトスタンダード(事実上の標準)という形式とっているため、勧告された時点で利用可能、もしくは既に普及しているということになります。そういった性質上、多くのエディターが議論を重ねながら段階を経て策定され、一般ユーザーからの意見を反映して改訂も行われるため、勧告されてから論争が起こるということはまずないでしょう。

Web標準に対する姿勢について偉そうに述べきましたが、伝えたいことは、私たちがWebという世界を作っているということです。そう思うとちょっと自信が沸いてきませんか？リアル世界と同じように政治を変えるにはそれ相応の主張が必要であるし、世界を動かす権力を持つには、それ相応の地位が必要になります。何にしても「政治家に求められる資質三ヶ条」は忘れずに可能な限り実行していきたいものですね。

「これからのWebのあり方について考えてみた。」で、多様な環境で利用されるWeb世界において、コンテンツが如何に重要であるかは理解を深めることができました。今回は見栄えを司る『CSS』のあり方について考えてみます。

見栄えを表現する手段としてCSSという技術が考案され、構造と見栄えを分離することで、メンテナンス性の向上、アクセシビリティの向上、ファイルの軽量化など大きなメリットが得られます。しかし、1998年頃に『CSS 2.0』が勧告された頃は、ブラウザ戦争の真っ只中ということもあり『Web標準』に懐疑的なブラウザベンダーは積極的に実装を進めてはいませんでした。実際に「懐疑的で積極的でなかった」のは私たち制作者側であって、ブラウザベンダーは凌ぎを削り合いながらも積極的に取り組んでいました。不適切な表現をしてしまい申し訳ありません。

私はというと、その頃は「Webっておいしいの？」程度の知識レベルだったのでリアルタイムな世代ではなかったのですが、先人の方々に伺ってみると「Web標準など理想論に過ぎない」と思っていた人が多かったのだとか。当時の状況を考えてみれば無理もないと思いますが、結果的に『CSS 2.1』は、仕様の改訂、フィードバックの反映を繰り返し、今日のWeb業界ではスタンダードな技術として広く普及しています。そのような時代背景から学べることは2つほどあります。

積極的にチャレンジする姿勢

当時は理想論だと言われていた標準技術も、今ではWeb制作におけるスタンダードになりつつあります。CSS 2.1においては、未だに最終勧告がされていないのにも関わらず、先行実装されている機能から積極的に利用されていき、IE6などの旧ブラウザに対応するために解釈の違いを逆手に取った『CSSハック』などのテクニックが生み出されました。つまり、W3Cの勧告や技術の普及を待つだけの受動的な姿勢ではなく、積極的にチャレンジしていく姿勢が大切なのではないかと思うのです。

今話題の『CSS 3.0』は草案段階でありながら、先行実装が始まっているモジュールもあれば、すでに実装がほぼ完了し、十分なフィードバックが得られるモジュールも存在します。以下「CSS3の実装状況│When can I use...」で列挙されているものを一部紹介します。見て分かる通り、IE9での実装も進んでいるようなので、これらの機能を惜しみなく使える日はそう遠くないかもしれません。

Box-sizing

widthやheightで指定した横幅や高さに、パディングやボーダーの大きさを含むかどうかを指定する

Web Font

サーバーから指定されたフォントがダウンロードされ、ユーザー環境に左右されない表示が可能になる

Text-shadow

ドロップシャドウやアウトラインの効果を表現できる

Media Queries

小型携帯端末向け、PC向けなどのデバイスに合わせてCSSを分岐できる

Border images

ボーダーでグラデーションや背景画像、エフェクトなどを表現できる

Multiple Column Layout

ユーザー環境によって2段組、3段組のレイアウトを表現できる

Flexible Box Layout Module

ボックスモデルを拡張し、より柔軟なレイアウトを行える

Multiple backgrounds

1つの要素に複数の背景画像を指定できる

Transforms

要素に対して拡大、回転、歪み、移動などの変形を行える

Transitions&Animations

要素に対してアニメーション処理を行える

パラダイムの転換

いわゆるブラウザ戦争というのは、1990年代に起きたInternet Explorer(以下IE)とNetscape Navigatorの『第一次ブラウザ戦争』、2004年以降Mozilla FirefoxやOperaがシェアを拡大し、IEに脅威を与え始めた『第二次ブラウザ戦争』が主なものとして挙げられます。これらのシェア争奪戦で共通しているのは、マーケットでシェアを独占していたIEに対して、ほかのブラウザが下克上を申し立てるという点です。そのような状況なので、IEへの対応は必須になり、クロスブラウザありきの『Graceful Degradation』という考え方が主流になっていきました。

しかし、2006年から水面下で続いている『ポスト第二次ブラウザ戦争』では、FireFox3.x、Opera9.x、Safari for Windows、そしてGoogle Chromeといった次世代ブラウザのリリースが相次ぎ、モダンブラウザがシェアを伸ばす一方、IEがシェアを減らしていくという傾向が続いています。Web標準に積極的でなかったIEも、さすがに準拠せざる終えないと判断したのか、IE7,IE8では積極的に仕様が取り入れられています。Net ApplicationsのBrowser market shareを測定結果では、IEのシェアは63％と表記されていますが、その内訳は以下「12月のブラウザシェア - ChromeがSafari抜く、Firefox 3.5は3位 | エンタープライズ | マイコミジャーナル」から引用します。

順位	バージョン別ブラウザ	シェア	推移
1	IE6	20.99%	↓
2	IE8	20.86%	↑
3	Firefox 3.5	16.32%	↑
4	IE7	15.53%	↓
5	Firefox 3.0	6.91%	↓
6	Chrome 3.0	3.75%	↑
7	Safari 4.0	3.45%	↑
8	IE8互換モード	2.80%	↑
9	Opera 10.x	1.58%	↑
10	Firefox 2.0	0.89%	↓
11	Opera 9.x	0.80%	↓
12	Chrome 4.0	0.75%	↑

これを見て分かる通り、FireFoxをはじめとする次世代ブラウザが上位に食い込み始めています。IE8は、シェアが下がり続けるIE6と拮抗状態にあり、IE8、IE9がメインブラウザになるのは時間の問題でしょう。そうなれば、今までIE6を理由に採用されなかった実装手法も利用されるようになり、CSSハックと呼ばれるテクニックは利用する必要がなくなります。そして、CSS3.0が主流になれば、文書にとって不要な要素やid/class属性を減らすことができ、よりスマートなマークアップが可能になる上に、意図した通りの視覚表現が多くの環境で統一されるので、品質保証にかかる工数も減らすことができます。

だからといってIE6は放置しても良いということではなく、ターゲット外のブラウザでも最低限の見栄えを確保する配慮は必要になるでしょう。その上で新しい技術への積極的な取り組みを行い、そうした試行錯誤が技術の進歩を促し、新しい手法や考え方が生み出されていくのです。こうした状況を踏まえると、クロスブラウザありきの考え方から新たな考え方へパラダイムシフトしているという実感が湧いてきます。今は未だ灯火ですが、自ずと『Progressive Enhancement』という考え方へのパラダイムシフトが、緩やかに、そして確実に起こっていくことでしょう。

CSS3.0の実際

CSS3に関する実例としては以下のようなものが挙げられます。この手の記事では必ずといって良いほど取り上げられているサイトですが、イギリスのデザイナーAndy Clarkeの個人サイト「Stuff and Nonsense」です。モダンブラウザで見るとフルカラーで表示されるのですが、IE6で見るとモノクロで表示されます。IEのCSSサポート状況を皮肉っているようにも思えますが、Progressive Enhancementの考え方を理解するには分かりやすい事例だと思います。

IE6での表示

モダンブラウザでの表示

もう一つの事例は、CSS Zen Gardenに投稿された「Gemination」です。モダンブラウザとIE6とで表示を分けているという点は同じですが、実装手法が異なるようです。前者は条件付きコメントを使用してブラウザ判定を行っているのに対し、後者は属性セレクタを使用してスタイルを上書きしています。CSSソースを覗いてみると以下のように全てのブラウザに対してスタイルが適用されるようにし、モダンブラウザには属性セレクタを使用して新たなスタイルを上書きしています。これは最低限伝えるべき機能を実装し、その上で高水準の環境下でよりリッチな体験を提供するというProgressive Enhancementの考え方に基づいた手法といえるでしょう。

IE6での表示

#container{
position:relative;
margin:0 auto;
border-right:3px solid #fff;
border-left:3px solid #fff;
padding:0 20px;
width:706px;
background:url(contentback.gif);
voice-family:"\"}\"";
voice-family:inherit;
width:666px;
}

モダンブラウザでの表示

body[id=css-zen-garden] #container{
position:relative;
margin:0;
border-top: 5px solid #fff;
border-right:0;
border-bottom: 5px solid #fff;
border-left:0;
padding:0;
width:100%;
height:350px;
background:url(longgarden.gif) repeat-x center right;
}

Progressive Enhancementの考え方に基づいたCSSのあり方、如何でしたでしょうか。コンテンツはもちろんですが、ユーザーエクスペリエンスにおいて見栄えというレベルでの情報提供は大変重要です。ただそれが、コンテンツありきであるということは忘れないようにしてください（くどい）。IE6のシェアが減っているとはいえ、しばらくはターゲットブラウザには含まれるとは思いますが、使えるものは使わな損々。トライ&エラーを繰り返しながらも積極的に活用していきたいですね。

前回、「Progressive Enhancementという考え方」で「Webを活用する環境が多様化したことにより、全方位的なアクセシビリティ、コンテンツの供給力が何よりも重要になってきている」ということを述べましたが、Webを取り巻く環境が変化すると共に、フロントエンドテクノロジーも日々進化を繰り返しています。今回は技術的な観点からどのようにWebのあり方が変わっているのかを考えてみます。

HTMLの軌跡

Tim Berners-Leeが提唱した「広くあまねくアクセシブルなWeb」がどのようなものなのかを知るには、HTMLについて理解する必要があります。1989年にWWWが開発され、文書に相互的な機能を持たせる『ハイパーテキスト』という概念が生まれました。以下、Tim Berners-Lee氏が「The「World Wide Web: Past, Present and Future」で述べた内容を和訳したものの一部です。

ウェブの到達目標は、人間とハイパーテキストの相互のやりとりが十分直感的に分かりやすいものとなって、コンピュータで読みとれる形の情報の空間が、人々の思考、やり取り、仕事のパターンの状態を適切に反映できること。

「コンピュータでも読み取れる形の情報」というのは、コンピュータが人間に代わって文書を適切に分析できるワークフレーム、つまりHTMLのことです。『HTML』とはその名の通り、文書を論理的にマークアップするための言語で、文書構造をコンピュータにも理解しやすいように論理的な意味付けを行い、それらを有益な情報として分析できるようにする役割を持っています。

そして、コンピュータに保存されている文書の『ハイパーリンク』を収集し、その構造を分析することによって、サーチエンジンによる検索データベースが実現しています。これが世界中のネットワークを司る仕組み、『WWW』なのです。

Semantic Web

ティムの思惑とは裏腹に、1993年にHTML1.0が公開されてからブラウザベンダーによる拡張が度重なり、見栄えを表現する要素や属性が追加され、本来の目的とはそぐわないWebサイトが乱立することになりました。そうした状況を踏まえ、『W3C』は標準化を本格的に推進し、HTML4.0では文書を論理的にマークアップする言語として本来の目的を果たすように改められ、見栄えを表現する手段として『CSS』が考案されます。

そして、拡張性、柔軟性に欠けるHTMLの弱点を克服するため、XMLにより独自の意味や構造を持ったマークアップを可能にする言語『XHTML』が開発され、『Semantic Web(セマンティック・ウェブ)』という分野が注目されるようになります。以下、「メタ情報とセマンティック・ウェブ」より引用します。

ウェブは人間が読むための「文書のウェブ」から、様々なデータを自在に発見して利用できる「データのウェブ」へと向かいます。メタデータを適切に与えることで、文書情報をこの「データのウェブ」に組み込むことが可能になります。

「文書のウェブ」は、情報の検索や活用が原始的で単純レベルに留まっているWebページを指し、「データのウェブ」は、その情報が持つ意味を表す『メタデータ』を付加することでコンピュータがより精度の高い分析を行えるようになるWebページを指します。いわゆるセマンティックなマークアップというのは、『XML(HTMLをXML標準に対応させたXHTMLを含む)』によって記述され、その中にメタデータの記述言語を用いて情報の意味付けを行ったものをいいます。

実際は、技術の標準化などに時間がかかることから、利用できるのは先になるだろうと多くの方が予想していたようですが、Webの発展に合わせてそのニーズが高まり『microformats(マイクロフォーマット)』と総称されるマークアップ方式が多くのサイトで採用されてきています。

そのように、W3CはSemantic Webを実現するために技術の標準化を順調に進めていましたが、期待していたほどは普及しませんでした。なぜなら『Ajax』に代表されるようなWebアプリケーションのニーズが、XHTMLによるマシンリーダブルなWebページよりもニーズが高まっているからです。こうした背景の基、新たにHTMLを進化させる仕様として策定されているのが『HTML5』です。

Webアプリケーション

HTML5ではこれまでの後方互換性を保ちながら、進化の土台となる重要な機能を加え、大きなバージョンアップが行われました。以下、主な新機能を列挙します。

Canvas

FlashやJavaのようにプラグインを使わずに、JavaScriptベースでグラフィックを描くことができます。「Chrome Experiments」でデモが公開されています。

Audio/Video

ブラウザで音声や動画の再生を可能にします。プラグインは必要としません。

Web Storage

データをブラウザ側に蓄積する仕組みです。クッキーとは異なり、より大きなデータを蓄積できるため、ユーザーエクスペリエスの向上、サーバー負荷の低減に役立てます。

Offline Web Applications

オフライン時でもWebアプリケーションが動作する仕組みです。ネイティブアプリケーションと同等の機能を提供します。

Webのストリーム化、コミュニケーションのリアルタイム化がトレンドになりつつある現状を考えると、このような進化は自然な流れであるといえます。すでに、グラフィック表現を可能にする『Canvas』は多くのブラウザで実装されていますし、リッチでインタラクティブな3Dアプリケーションを作成するAPI『O3D』という強力な機能も実装される予定です。

メーラーを代表とするネイティブアプリケーションと同等の機能を提供するには、インタラクションを司る『JavaScipt』の進化も必須になりますが、ほとんどのブラウザでJavaSciptエンジンの高速化が進められており、実現する日もそう遠くはないでしょう。

クロスプラットフォーム

Webアプリケーションがネイティブと同等になるのであれば、各々のデバイスに対応するよりも、標準技術を基に汎用性のあるアプリケーションの方が効率的です。今までもWindowsを代表とする様々なテクノロジーがクロスプラットフォームを実現しようとしてきましたが、ついにHTML5によって最大級のクロスプラットフォームが実現するかもしれません。

アプリケーションがハードウェアやOS、モバイルから電子機器などのあらゆるデバイスでサポートされるということは、それだけ開発がシームレスになるということであり、開発コストの低減、素早いサービス展開など、開発者だけでなくユーザーにとっても有益な結果をもたらします。

クロスプラットフォームは、HTML5だけが独占している話題ではなく、AdobeではFlashアプリケーションをiPhoneアプリケーションに変換する「Flash for iPhone」など、Flashをあらゆるデバイスに移植するというプロジェクトを発表しています。また、MicrosoftではPCとモバイル、テレビといったスクリーンをソーシャルサービスと繋ぎ、統一されたインタフェースを実現する「Three Screens and a Cloud」というプロジェクトが注目されています。

このように、ベンダーの戦略に共通するものがあり、改めて時代の変化を感じさせると共に、今後さらに加速化するであろうプラットフォーム競争の覇者となるのはどのベンダーなのか。しばらく目が離せそうにありません。

仕様による標準化

これまでの競争と違うのは、標準技術の仕様に準拠することが前提になっていることです。Windowsが普及した頃は、Windows仕様のアプリケーションを開発するのがスタンダードでしたが、HTML5やJavaScriptという標準技術に基づいて開発されたアプリケーションはプラットフォームに依存しないため、あらゆるデバイスで拡張性の高い開発が可能になります。

標準技術をベースにアプリケーションが開発され、OSやモバイルなど、デバイスに依存しないプラットフォームが普及すれば、市場競争が活発化することで実装の多様化が進み、目覚しいほどの進化が期待できます。

そのようなことから、今後はAdobe 『AIR』、Microsoft 『Silverlight』、そして『Google Chrome OS』上で動作するブラウザをターゲットに開発されていくと思われます。「AIR vs Silverlight vs HTML5」という構図が思い浮かびますが、調べてみたところAIR、Silverlightは共にHTML5に対応する見通しのようです。Google Chromeは当然対応しているので、HTML5はアプリケーションの標準技術として欠かせないものになっていくのではないでしょうか。

アクセシブルなWebへ

新時代のブラウザの登場、モバイルデバイスの普及などによって、Webのストリーム化、コミュニケーションのリアルタイム化が行われ、Webのあり方に大きな変化がもたらされています。そのような時代のニーズに合わせてHTML5という標準技術が公開され、Webアプリケーションの進化、クロスプラットフォーム、仕様の標準化が推進され、着々とTim Berners-Leeが意図したWeb本来の姿に変貌を遂げようとしています。この方向性はW3Cの多大なる努力の結果という見方もできますが、Webが進化する上ではごく自然な成り行きだったようにも思います。

ここまでくればTim Berners-Leeが提唱した「広くあまねくアクセシブルなWeb」の意味が掴めてくるのではないでしょうか。前回の記事で「全方位的なアクセシビリティ」と「コンテンツの供給力」が重要だと述べましたが、これまでのことを踏まえてそれぞれ解説してみます。

【全方位的なアクセシビリティ】

まず、アクセシビリティが何なのかをおさらいしましょう。以下、「JIS X 8341-3 高齢者・障害者等配慮設計指針 - 情報通信における機器、ソフトウェア及びサービス - 第3部:ウェブコンテンツ」より引用します。

基本方針として高齢者や障害者への配慮、多様な機器やディスプレイ、ブラウザで利用できること、これらを企画から運用に至るプロセス全体で常に考慮すること

簡潔にまとめると「あらゆる環境に配慮し、誰にとっても使いやすい方法で情報を提供すること」です。まず、ハンディのある方々への配慮というように、バリアフリーという観点では認知されてきていると思います。

ただし、高齢者や障がい者など身体に障害や不自由がある方々のための対応というよりは、最低限の使いやすさを確保するために必要な指標という方がしっくりきます。例えば、駅に設置されているエレベーターは、高齢者や車椅子を利用されている方々はもちろん、健常者にとっても便利なものです。それをWebの世界に還元すると、アクセスした誰もが容易に情報を共有できるようにするということになります。

多様化が進むWebの世界でそのような取り組みがより求められていることは既知の事実であり、その中心にいるのがW3Cです。W3Cの取り組みによって、あらゆるデバイスで共通化を行うクロスプラットフォーム、環境に依存しない技術の標準化が進み、全方位的なアクセシビリティが現実的なものになってきているのです。

【コンテンツの供給力】

前回の記事で「『Progressive Enhancement』は、コンテンツそのものに重きを置き、Webの本来の能力を最大限に生かそうという試みなのです。」と述べましたが、コンテンツとは何を意味するのでしょう。以下、「Webアクセシビリティについて」より引用します。

基本的要件として、視覚、聴覚、身体のハンディにかかわらずコンテンツを操作・利用できること

この引用分では、ハンディがある方への対応という捉え方をしてしまうかもしれませんが、上記と同様、誰か或いは何かのデバイスに特別な対応をするということではありません。「広くあまねくアクセシブルなWeb」とは、クロスプラットフォームや標準化によって、あらゆる環境下でWebを閲覧できるということも一つありますが、最も本質的な部分は『コンテンツ』にあります。

ここで以下のような階層で囲まれた円を想像して欲しいのですが、最も内側にある階層がコンテンツであり、それはセマンティックなHTMLでマークアップされたものだと思ってください。コンテンツを包み込んでいる真ん中の階層は、CSSによって"見栄え"を整え、さらに全体を包み込んでいる外側の階層はJavaScriptによって"ふるまい"を与えます。

Webアプリケーション及びWebサイトの土台として、基本的にこの3つ要素が関わっており、最も深く、中心にあるのがコンテンツです。Webの世界はグーグルボットに代表されるクローラーというプログラムによって成り立っています。Web上にある文書や画像などの情報を周期的に取得し、データベース化、インデックス化を行います。要するに彼らはコンテンツだけを求めています。

また、高齢者や弱視の視覚障害を持つ方、特に全盲の方は、当然視覚が確保できないので音声読み上げソフトを利用してWebサイトの情報を取得します。それでも画像や動画などの情報は読み上げることができないので、alt属性などに情報を付加したりするなどの配慮が必要になります。繰り返しになりますが、多様な環境で利用されるWebの世界では、コンテンツが全てです。Webサイト上で、情報を発信、普及、収集、要求したりするのには、コンテンツというレベルでの情報提供は必須なのです。

今後、技術の進展により様々な実装の登場とそれらの競争が予想されますが、コンテンツの供給においては、技術云々の問題ではなく私たち制作者側の意識によって良くも悪くもなります。より良い情報伝達を行うためには、Webアクセシビリティ確保の必要性を認識し、利用者側の立場に立つことが大切だと思います。それこそターゲット層云々の問題でもなく、私たちが例外なく空気を必要とするように、Webという世界で過ごすために必要なものは何なのか、もう一度振り返って考えてみる必要があるのではないでしょうか。

HTML5の実際

Webアクセシビリティの重要性が高まっていく世の中で、情報伝達すらも儘ならないようなWebサイトは、収益機会を逃すだけでなく、自社の信用を落とすことにも繋がります。では、コンテンツを供給するために必要な「セマンティックなマークアップ」とはどのようなものをいうのでしょうか。Webアプリケーションの項目で「Webアプリケーションのニーズが、XHTMLによるマシンリーダブルなWebページよりもニーズが高まっているからです。」と述べましたが、だからといってSemantic Webが切り捨てられるという訳ではありません。

HTML5では、section、nav、aside、header、footerなど、セマンティックなタグが追加され、より論理的なマークアップが可能になります。これらのタグを利用することで、単純に構造が分かりやすくなるなどといった表面的なメリットだけではなく、クローラーが文書の内容をより正確に収集できるようになり、検索の精度が格段に向上するという恩恵を受けられます。コンピュータにやさしいマークアップは最終的に人間にとってもやさしいものになるのです。

HTML5は2022年以降にW3C勧告に至ると言われていますが、「Browser support for CSS3 and HTML5 CSS3 and HTML5 feature support」というサイトでHTML5の対応状況を見る限り、それまで全く使えないということはなさそうです。新世代プラットフォームである『Google Wave』や『Web Kit』などがHTML5を駆使した仕様になっているということもあり、Firefox、Safari、Opera、Google ChromeなどのモダンブラウザでHTML5の実装が進んでいますし、Microsoftの次期ブラウザである『IE9』も標準技術に準拠するという意向を示しています。

また、JSライブラリを使用すれば、今すぐにでも以下のような機能を利用することができます。現状では、JavaSciptエンジンに依存していますが、プラグインが必要なくなるのも時間の問題だということです。

typeface.js

テキストをSVGに自動置換してフォントを表現するライブラリ

Bluff

Canvasを用いてグラフを描画するライブラリ

raphael

SVGでチャートグラフ、円グラフなどの曲線をベクターとして扱うことが可能になるライブラリ

280 Slides

280 Slides
PowerPointをWEBアプリケーションとして実現するライブラリ

Processing.js

Processing言語をJavaScriptに流用したライブラリ

cpick.js

色を選択するためのカラーパレットを表示するライトウェイトなライブラリ

progress.js

プログレスバーを表示するライトウェイトなライブラリ

border-radius.js

class属性に値を追加するだけで、ブロックボックス要素の角を丸くするライトウェイトなライブラリ

table.js

class属性に値を追加するだけで、テーブルの通常行の背景色をストライプ状にし、各行をクリッカブルにするライトウェイトなライブラリ

radar.js

canvas要素でレーダーチャートを描画するライブラリ

他のライブラリはJavaScipt ライブラリー - HTML5.JPからどうぞ。

最後に

Webが時代を終わらせ、Webが時代を作り始めている今日、あらゆる業界に多大な影響を与えていることと思います。時代の変化に合わせて新しい技術が生み出され、誰もがインターネットを持ち歩く世の中になりました。そうした時代の覇者になるべく、大手ベンダーは自社の技術を駆使し、凌ぎを削り合っています。そして、私たちWeb制作者はそうした変化に合わせて、パラダイムの転換を行わなければなりません。

ここにきてやっと、Tim Berners-Leeが望んだWebのあり方に時代が追いついたという感じがしてなりません。「Webのあり方」という地図があったとして、私たちはしばらく間違った道を半ば開き直りながら進んでいたのではないでしょうか。誤った道をどんなに効率的に進んでも、行き着くところは誤った目的地です。ティムの手元には何年も前から正確な地図があり、長い年月をかけて私たちを正しい道に戻してくれたのです。

しかし、進むべき道がが明確になったとはいえ、順風満帆にことが進むとは限りません。多くの誘惑が出てきて、道を塞ぐこともあるかもしれません。そうした中で心がけることは、正確な地図をなくさないということです。どんなに遅くても、寄り道しても、正確な地図さえあればいずれ目的地に到着することができるのです。『Progressive Enhancement』という考え方が広まっていることも、一つの道標です。迷子にならないようにしましょう。

* * *

頭の整理をしようとして、アウトプットをしていたらこんなに長文になってしまいました。何だか宗教の信者ｗのようになってしまいましたが、少しでもお役に立てれば幸いです。

ここ最近、HTML5を始めとするフロントエンドテクノロジーやプラットフォームに関する話題が絶えません。毎日その動向に注目していないとおいていかれてしまいそうです。Google Chromeを代表する新時代のモダンブラウザ、既存ブラウザのバージョンアップ、そして未だ残り続ける古いブラウザなどのソフトウェア、さらにはモバイルコンテンツの流行、ネットブックの普及、そしてiPhoneを始めとするスマートフォンの出現によって、Webを活用する環境が多様化しています。これを機にWebのあり方についてもう一度見直す必要があるのではないでしょうか。そんなわけで2010年一発目です。

HTML5やJavaScriptなどの標準化が進み、Google ChromeやFirefoxを始めとするWebブラウザが我先にとテクノロジーの進展に努めています。このまま表現力の向上、高速化が進めば、スタティックな文書を閲覧するだけではなく、ダイナミックなWebアプリケーションとして新たなプラットフォームを築く日もそう遠くはないでしょう。Webアプリケーションといえば、2004年頃に公開されたGMailを筆頭に、カレンダーやワードプロセッサなど、様々なアプリケーションがWebブラウザ上で活躍してきましたが、今やネイティブアプリケーションとほぼ同等というところまで技術が進化しているということなので驚きです。

それはつまり、標準技術を基に汎用性のあるアプリケーションをシームレスに開発できる環境が整うことを意味しており、PC、モバイル、家庭用電子機器など、あらゆるデバイスが共通のプラットフォームを持つということになります。そんな中、『Progressive Enhancement』という考え方が注目されてきています。

Progressive Enhancementとは

では『Progressive Enhancement』とはどのような考え方なのでしょうか。

以下、Graceful DegradationとProgressive Enhancement | Web標準Blogより引用です。

ターゲットとするすべてのブラウザーに対し、最低限伝えるべき機能を実装します。その上で、より高水準の環境（ブラウザー）では、高い機能を体験できるように機能強化をおこないます。

つまり情報やサービスへのアクセシビリティを確保し、高水準のブラウザ、デバイスにそれ相応のデザインやインタフェース、技術を実装しようという考え方です。それに対して今まで主流であったのは『Graceful degradation』という考え方です。

Webサイトで表現したい機能を、特定の水準にあるモダンブラウザーに対して提供します。しかし、低水準の古いブラウザーに対しても、同等ではないもののそつのない、または理にかなったかたちで機能を提供します。

クロスブラウザ＝どのブラウザでも同じようにするという考え方は、制作コンセプトとして当たり前のものになっています。高水準のブラウザで表示確認を行い、下位ブラウザやデバイスの対応を行うというフローが一般的なのではないでしょうか。

別段、それが悪いということではなく、どちらの考え方もWeb体験をより良く提供しようという前向きなアプローチが取られています。両者の違いは、制作コンセプトにおける観点にあります。前者は、コンテンツありきの考え方で、後者はクロスブラウザありきの考え方です。

では、『Progressive Enhancement』という概念が広がり始めた背景には何があるのでしょうか。文頭でも述べましたが、Webを活用する環境が多様化したことにより、全方位的なアクセシビリティ、コンテンツの供給力が何よりも重要になってきているのです。今までのように、クロスブラウザありきで制作しているのでは、実装できる技術が限定されてしまい、新しい技術の恩恵を受けられません。

また、あらゆるデバイスの基盤技術がWeb標準に統一化されていく中で(もちろんデバイスごとにカスタマイズする必要はありますが)、見栄えやふるまいに重きを置くのはスマートなやり方とは言えません。『Progressive Enhancement』は、コンテンツそのものに重きを置き、Webの本来の能力を最大限に生かそうという試みなのです。Tim Berners-Leeが掲げた「広くあまねくアクセシブルなWeb」がようやく実現に向けて走り出したということでしょうか。

次回から『Progressive Enhancement』の考え方に基づいて、技術的な観点からWebのあるべき姿について考えていこうと思います。