シャンディ・ガフを飲みながら

先日、内定通知をいただきました。
晴れて6月1日からWEBデザイナーとして再出発です。

エンジニアだった私が本来志望していたデザイナーに転職できたのは、ブログの執筆やコンテストへの取り組みなど、日々の積重ねを目に見える形で明示化できたこと、ポテンシャルが伝わるようなポートフォリオを作成したこと、誰かのアドバイス、ダメ出し、ケチでさえも一意見として受けとめ、自分なりに答えを出し、次に生かしたことなどが起因 していると思います。

もちろん全てはこれからですが、この転職は自分にとって大きな門出なることは間違いありません。イラスト、映像、グラフィック、CG‥やりたいことがたくさんあります。そしてそれらのスキルを適材適所に使い分け、誰かの心を打つエモーショナルなものづくりをしていきたいと考えています。

引き続き当ブログは執筆していきますので、 今後とも宜しくお願い致します。

以前「効率的にデザイン力を身につける方法」という記事で、デザイン力とは単純なグラフィックスキルのことだけを指すのではなく、そのデザインである必然性を見て取れる"目利き"の能力であると述べました。そして、デザイン力を効率的に高める手段として『模写』をお勧めしました。

色使いからグラデーション、ホワイトスペースに至るまで、全てを忠実に再現し、『なぜそのデザインなのか？』をあらゆる観点から自分なりに分析することによって、デザインに必要な『考える力』を養うことができます。今回はその模写をするにあたり、活用すればさらに効果が見込めるリソースをご紹介します。

20 High Quality Photoshop Web Design Tutorials

模写を行うには当然元となるデザインが必要になりますが、前回の記事では玉石混交の中から玉を選び出す手っ取り早い方法として『アックゼロヨンアワード』の受賞作をチェックするということをお勧めしました。デザイン力を身に付けるにはそれだけでも十分なのですが、模写を行う以上Photoshopというツールの使い方はマスターする必要があります。いくら模写によって効率的にデザイン力が身に付くとはいえ、ツールの使い方がよく分からない、面倒くさいということになってしまうと先に進めなくなってしまうからです。

『20 High Quality Photoshop Web Design Tutorials』ではタイトル通り、クオリティの高いWebデザインのチュートリアルが20例紹介されています。ひとつひとつが詳細に解説されていて、初心者の方でも手順通りにやれば再現できるように作られています。英語に抵抗がある方でも多少Photoshopの理解がある人であればキャプチャを見るだけで操作方法は把握できるでしょう。

これで初心者の方に優しいということがお分かりかと思いますが、実は私を含め実務レベルでPhotoshopを使用している人であっても、痒いところに手が届くレイヤースタイルの使い方や、美しくレイアウトするためのガイド機能の使い方など、「今まで非効率なやり方をしていた」「この機能はこういう使い方も出来るのか」といった新しい発見があることは間違ありません。

ただし、今回のリソースはあくまで模写をするという前提で、有効に活用すればツールの使い方における効率化もできるよという話で、最初から答えを見ながらやるのはもはや『模写』ではなくなってしまいます。自分なりに試行錯誤し、制作者の意図を汲み取る、デザインの息遣いを感じ取ることを意識しなければデザイン力を身に付けることは出来ません。まずは自分で消化してから、「答え合わせ」をするようにしましょう。

ブログでは大言壮語な私ですが、実は現在無職です。昨年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"の日が幾日も続くと、そろそろ何かを変える必要があるなと、そう悟ります。

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

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

先日行われたCSS Nite LP, Disk 9「Coder's Higher」で開催された第2回コーディングコンテストで『入賞』という評価をいただきました。優秀賞は逃してしまいましたが、全体的にレベルの高い内容だったということなので個人的には大健闘かなと思っています。

第2回コーディングコンテストの結果発表

「HTML5×CSS3の実装で抑えておくべきこと」は当コンテストでの経験に基づいて書いた記事です。結果が出たので公開しようかと思いましたが、6月5日に再演版のCSS Nite LP, Disk 9.2（reprise）が開催され、コーディングコンテスト受賞作の解説もあるということなので詳細はあえて伏せておくことにします。作品は本サイトの方でも間もなく公開されるはずなので、興味のある方はご確認いただければと思います。

反省点としては不要なアニメーションを適用してしまったこと、一部JSをHTMLにべた書きしてしまったこと、もっと丁寧に作るべきだったなど挙げたらキリがありません。受賞された方の解説や審査員の方々のコメントを拝読し、改善点を見つけては「こうすれば良かったのか‥」と少し悔しい気分になる反面、次回は必ず最優秀を狙ってやろうという野望も芽生えています。また、中には私(Shoon_Miyamoto)の作品を高く評価して下さっている方々もおり、とても光栄に思います。

サイバーガーデン

第2回 コーディングコンテスト、個人的な総評

エスカフラーチェブログ

CSS Nite LP9 & 第2回コーディングコンテストレポート

頑張れば報われるということを身を持って体験できたとても素晴らしい機会になりました。
関係者の方々、参加者の方々、本当にお疲れ様でした！！

最低限のアクセシビリティを確保し、高水準ブラウザのパフォーマンスを最大限に発揮させようという『プログレッシブエンハンスメント』という考え方があります。私はこれについて、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を引っ張っていく者の役割なのではないかと考えています。最も私などはペーペー中のぺーぺーですが、今回そうした機会を与えて下さった方々にはとても感謝しています。私も少しずつ精進ていきます。

僕はデザイナー駆け出しで、大した実績もありませんが「効率的にデザイン力を身につける方法」で書いた模写という勉強方法を続けたおかげで、何がそのデザインを美しくしているのかを感覚的に見極めることは出来るようになりました。最も、その根拠については自分の感性を信じるしかないのだけど。今日はグラデーションに焦点を当てていくつかのサイトを紹介してみようと思います。

グラデーションは、デザインを美しく見せるためのテクニックとして僕が非常に重要だと思うテクニックの一つです。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へ向かって歩を進める時ではないでしょうか。

先日、ナビゲーションのロールオーバーについて以下のようなご質問をいただきました。

グローバルナビゲーションをJSで制御しているサイトもあれば、CSSの背景で制御しているサイトもあるけど、結局どれがベストなの？

まず、テキストは元より、画像であっても代替テキストを指定すれば『コンテンツ』というレベルで情報は確保できるので、テキストが良いか、画像が良いかということについては個人的にどちらでも良いと思っています。マークアップの観点では、グラフや地図、写真イメージなど、テキストでは補えない性質の情報を提供する場合はimg要素でマークアップするべきだと思いますが、ナビゲーションはあくまでサイト内を遷移するための"機能"であるため、その役割を果たすことが最も重要なのではないかと思います。

また、ナビゲーションにはサイト内を遷移するという役割のほかに、現在位置を把握するという役割も担っているので、ロールオーバーやカレント表示などの機能も備わっていなければなりません。どの手法がベストなのかを検討するには、画像を非表示にするユーザやCSSを無効にするユーザへの配慮がなされているかといった『見栄え』による部分と、JSを無効にしているユーザへの配慮がなされているかといった『ふるまい』の部分を把握した上で考慮する必要があります。では、実際にいくつかの手法を再現しながら検証していきましょう。

CSSで画像置換を行う

テキストをtext-indent:-9999pxで飛ばして背景画像を表示させる手法で、しばらくの間主流になっていました。しかし、画像を非表示にした環境下でテキストが表示されなくなるという問題は、モバイルでの閲覧や回線状況、テキストブラウザや音声ブラウザなどの閲覧環境においてアクセシビリティ上、致命的な問題を生じる可能性があります。また、テキストを飛ばす、或いは消して画像に置き換えるという手法上、SEOスパムと判別される可能性があります。画像置換にはメリットも色々とあるのですが、それを上回るデメリットがあるため、現在では使用が控えられている傾向にあるようです。

JSをオフにした場合

CSSで制御しているため、問題なく機能する

画像をオフにした場合

テキストが表示されず、環境によってはナビゲーションとして機能しない

CSSをオフにした場合

適切にマークアップされていれば最低限のアクセシビリティは確保されるので問題なし

画像をJSで入れ替える

img要素で定義されているため、画像を非表示にした環境でも代替テキストが表示されます。これで、画像置換で起こる「テキストが表示されなくなる」という問題は解消されますが、JSを無効にすると今度はロールオーバーが機能しなくなります。よくJSでロールオーバーさせるメリットとして「CSSが無効の環境でも画像が保持される」ということが挙げられているのですが、おそらくCSSを必要としない環境下では画像そのものよりも適切な代替テキストが指定されているかの方が重要なのではないかと思います。その考え方に基づくと、CSSを無効にした環境下でJSによる挙動が本当に必要なのかという疑問も生じます。ロールオーバーが機能しないことは、差したる問題ではないとは思いますが、先に挙げたような"副作用"と天秤にかけて使用を検討する必要があるかもしれません。

JSをオフにした場合

JSで制御しているため、ロールオーバーが機能しない

画像をオフにした場合

代替えテキストが表示されるので、適切なAltが指定されていれば問題なく機能する

CSSをオフにした場合

適切なAltが指定されていれば最低限のアクセシビリティは確保されるので問題なし

画像をCSSで入れ替える

こちらもimg要素で定義を行うのですが、JSは使用せずにCSSだけでロールオーバーを実現しています。概要としては、img要素を囲うブロックにロールオーバー時の背景画像を適用させ、マウスオーバー時に画像を非表示にするというものです。JSを無効にした状態でもロールオーバーが機能し、かつ画像を非表示にした状態でも代替テキストが表示されるので、決定版はこれだ！と言いたいところなのですが、ロールオーバー時に背景画像を指定しているため、画像を非表示にした状態でマウスオーバーすると何も表示されなくなってしまいます。代替テキストが表示されるためサイト内での遷移は問題なく行えると思いますが、マウスオーバー時やカレント時に色が変わるなどといったユーザビリティが確保できないため、ユーザーに無駄なフラストレーションを与えてしまう可能性があります。

JSをオフにした場合

CSSで制御しているため、問題なく機能する

画像をオフにした場合

代替えテキストが表示されるが、ロールオーバーやカレント表示の際にテキストが表示されなくなる

CSSをオフにした場合

適切なAltが指定されていれば最低限のアクセシビリティは確保されるので問題なし

新・画像置換

上記では、画像置換にはメリットを上回るデメリットがあるため、使用を控えるという話でした。しかし、もしそのデメリットが解消されたらどうでしょうか。『DKIR』という手法を使えば、画像が非表示の状態でもテキストが表示され、かつCSSで制御しているため、JSを無効にした状態でもロールオーバーが機能します。デザイン変更などがあった場合、マークアップに手を加えることなく画像の差し替えが行える、『CSS Sprite』を利用してhttpリクエストを減らせるなどといった、画像置換の恩恵のみを受けられることになります。SEOスパムについては、その定義の曖昧さや判断基準が明確でない以上、結論が出せないのでここでは棚上げにします。少なくともDKIRという手法はテキストを飛ばすわけでも、消すわけでもなく、背景画像の背面に隠すという手法であるため、画像置換におけるアクセシビリティの問題は解消できるはずです。しかし、そんなDKIRも万能というわけではなく、要素を重ねるという手法上、背景画像に透過PNGが使用できないという制約があります。

詳しくは「これで決まり？な画像置換 - DKIR | CSS-EBLOG」をご覧下さい。

JSをオフにした場合

CSSで制御しているため、問題なく機能する

画像をオフにした場合

代替えテキストが表示されるので問題なく機能する

CSSをオフにした場合

適切にマークアップされていれば最低限のアクセシビリティは確保されるので問題なし

4つの手法を紹介しましたが、どれがベストであるということはあえて明言しません。なぜなら、どれがベストであるかは時と場合によって異なるからです。JSを無効にした場合、画像を非表示にした場合、CSSを無効にした場合について検証したのは、それぞれの手法の長所と短所を明確にするためであって、優劣を決めるためではありません。一つの手法しか知らなければ何を疑うでもなくそれだけを使用し続けることになりますが、他の手法を知っていればそれだけ引き出しが増えることになり、時と場合によって相応しい選択が行えるようになります。

1つだけ個人的な意見を述べるとしたら、ナビゲーションというのは"機能"としての役割を全うしてくれればそれで良いと思います。例えば、一つタグなどを挟まないとその機能が実現できない、というならば躊躇せずに挟むべきだと思います。「spanタグが入ると気持ち悪い」というのはとても分かりますが、そのTPOにおいて何が必要で、何が不要なのかを判断するには、やはり相応の知識が必要になります。これは何にでも言えることだとは思いますが、あらゆる手法や考え方を"身に付ける"まではいかなくとも、"知っている"だけで全然違います。一つの手法や考え方に固執するのではなく、広い視野を持って取り組みましょう。