ユーザーエージェント非依存

モバイルファースト/コンテンツファーストを実践するということは、ユーザーの閲覧環境を選ばない (どのユーザーエージェントを使っていても、コンテンツを閲覧し利用することができる) ということを意味します。

ブラウザを介さなくても (Web ページとしてデザインされた体裁でなくても) コンテンツが利用可能になっているので (コンテンツだけを切り出して、RSS リーダーや「Instapaper」「Readability」といったサービスでも閲覧できる)、自ずと、スクリーンリーダーをはじめとする各種支援技術にとっても親和性が高いと言えます。

情報のリニアライズ (線形化)

モバイルファースト/コンテンツファーストに則ってスマートフォン向けに Web サイトを設計すると、ディスプレイサイズの制約から、基本的に情報配置はワンカラム (一列) で構成されることでしょう。「above the fold (スクロールせずに閲覧できる領域)」に収まりきらない場合は縦方向にのみスワイプさせることが多いと思います。

これはすなわち、情報 (コンテンツやナビゲーション) の構造がリニアライズ (線形化) されることを意味します。リニアライズされた形でも情報がうまく伝わるということは、情報をシリアルに (逐次的に) 受け取る視覚障碍者 (スクリーンリーダーユーザー) にとっても、理解しやすくなっていると言えます。

情報のシンプル化 (認知負荷の軽減)

モバイルファースト/コンテンツファーストに則ってサイトを設計すると、ユーザーインターフェース (UI) やコンテンツを極限まで (本当に必要不可欠なレベルまで) 削ぎ落とすことにあるので、結果、情報がシンプルになり、認知負荷の軽減につながります。

一言で「シンプル」と言っても、障碍の種類によって個々のコンテンツに求められるシンプルさの形は異なるかもしれません (文字情報中心でシンプルにするのがよいのか、文字をできるだけ使わずビジュアル主体でシンプルにするのがよいのか、など…) が、サイト全体の構造やナビゲーションを含め情報アーキテクチャが総体的にシンプルになると少なくとも言えるので、肝心なコンテンツに集中しやすくなるという点で、幅広いユーザーにメリットがあると思います。

データサイズの軽減

モバイルファースト/コンテンツファーストに則ったサイト設計では、閲覧環境 (通信速度やデバイス性能) が劣る場合も当然想定することになりますので、データサイズの軽減もスコープに入ってきます。

上記「情報のシンプル化」とも関係しますが、データサイズを軽くするということは、不必要にリッチな演出 (無駄な画像やアニメーションなど) を盛り込む余地が無いということでもあるので、コンテンツがアクセシブルな形になりやすいと言えるでしょう。

もちろん、モバイルファースト/コンテンツファーストの実践が、すなわちアクセシブルな Web サイトの実現と必ずしもイコールなわけではありません。ですが、PC 画面で閲覧すること (だけ) を想定してデザインされた旧来の複雑な (情報が盛りだくさんの) サイト設計に比べると、モバイルファースト/コンテンツファーストという考えかたは、アクセシビリティと親和性が高そうです。そんな視点からも、モバイルファースト/コンテンツファーストの広まりに注目してゆきたいと思います。

たしかにスマートフォンでは PC 用サイトを閲覧することができます。ただ、画面が小さいので、ピンチ＆ズームを繰り返さなければならず、かなり面倒だったりします (途中でユーザーが投げ出してしまうことも十分あり得るでしょう)。実際、PC 用サイト (フルサイト) をスマートフォンで利用した場合、モバイルサイトを利用するよりもタスク達成率が下がるという調査もあります (参照 : Jacob Nielsen の Alertbox の記事「Mobile Usability Update」)。

モバイル用の Web サイトには、モバイル機器での閲覧/操作に最適化されたデザインが必要だというのは、異論のないところだと思います。

モバイル Web サイトは別に作らない

そこで問題になるのが、モバイル用のサイトを PC 用サイトと別に用意するかどうか、です。既存サイトが PC での表示を前提に「がちがちに」作られている場合は難しいかもしれませんが、たとえば下記のような不便を避けるためにも、サイトは別々にしないほうがよいと考えます。

• モバイル機器を使っていて、検索エンジンから PC 用サイトのページにランディングする。
• SNS などでたまたまモバイル用ページが紹介 (シェア) されている場合、そのリンクに PC を使ってアクセスしたら、大きな PC 画面に「いかにも携帯用に作りました」的なページが開く。

PC 用とモバイル用との間を行き来できるリンクを設けたり、ユーザーエージェントを自動判別してリダイレクトさせたり、といった解決方法もありますが、あまりスマートとは言えません。Web サイトはひとつにまとめて、アクセスするのに使われるデバイスに応じて、見せかたを変えるのがよいでしょう。

最近の流行は「レスポンシブ Web デザイン (Responsive Web Design)」という手法です。Ethan Marcotte 氏が「A List Apart」に寄稿して有名になりましたが、CSS3 の Media Queries を用いて、閲覧端末のディスプレイの大きさ (画面解像度) に合わせてデザインをフレキシブルに変更するテクニックです。具体的な事例は、その名もズバリ「Media Queries」というサイトでも日々紹介されているほか、日本でも、この手法を用いたサイトが増えています。

ただ、レスポンシブ Web デザインも、表面的に Media Queries を用いるだけではユーザビリティの面で不十分だったりします。ブランディング画像やナビゲーションメニューが「above the fold (スクロールせずに閲覧できる領域)」を占拠してしまい、肝心な情報が遥か下のほうに追いやられる…といった具合に、使いにくいサイトが後を絶ちません。

モバイルを第一に考える (モバイルファースト)

レスポンシブ Web デザインを採り入れるうえで併せて意識したい考えかたとして、「モバイルファースト (Mobile First)」がここ数年、注目を集めています。Luke Wroblewski 氏が提唱した概念ですが、これまで普通であった「メインは PC 用サイトであって、モバイル用サイトはサブな存在である」という思考を改めて、「まずはモバイル (スマートフォン) での利用を第一に考えて Web サイトを設計/デザインする」というものです。

モバイルファーストを実践しようとすると、デバイスの持つ表示上の制約から、ユーザーインターフェース (UI) やコンテンツを極限まで (本当に必要不可欠なレベルにまで) 削ぎ落とさざるを得なくなることでしょう。それこそが、サイトに必要なもの (あとは無くても構わないもの) と考えます。さらに大事なのは、PC で閲覧する場合もモバイル機器で閲覧する場合も、利用できる情報や機能は同等であるべきという考えかたです (モバイルといっても、必ずしも利用コンテキストが外出時や移動時に限定されるわけではなく、むしろ家の中、リビングやベッドルームなどで PC の代わりに使われることも多いからです)。PC での閲覧に対しては、画面の大きさ、通信環境、マシンスペック、などを勘案して「あったら便利 (nice-to-have)」を適切に付加する…というのが、モバイルファーストのあるべき姿とされています。

モバイルファーストはコンテンツファーストでもある

利用できる情報は PC でもモバイル機器でも同等であるべき、という意味で、モバイルファーストは「コンテンツファースト (Content First)」と表現されることもあります。その背景には、ユーザーの Web 閲覧方法が多岐にわたっていて、もはや Web サイトの制作者/運営者の側がコントロールできない、という現状があります。

これは単に、PC かモバイル機器か？というだけの話ではありません。「Web サイト」という形式でなくても Web コンテンツは閲覧できるようになっていて (以前からある RSS リーダーはもちろんのこと、Safari の「リーダー」機能、さらには「Insapaper」や「Readability」といったサービスもあります)、どの閲覧方法を選ぶかという主導権は完全にユーザーの側にあるのです。

当然のことながら、Web コンテンツの閲覧方法は今後もどんどん変化 (進化) し、より多様化してゆくことでしょう。未来を正確に予測するのは不可能です。モバイルファーストを提唱した Luke Wroblewski 氏を含む有志が、「Future Friendly」という概念を掲げています。これは「Future Proof」という言葉 (「なんとか proof」という表現には、たとえば「防水」を「water-proof」、「耐震」を「vibration-proof」と言うように、「完全に防ぐ」というニュアンスがあります) に対抗して、未来に対してあくまで「Friendly」な姿勢で行こう、つまり、未来に登場してくるであろう様々な閲覧環境を逐一予測して「がっちりと」対応するのではなく、根幹となるコンテンツを重視し (適切な情報セマンティクスを維持し)、変化に柔軟に対応できるように準備しておこう、という考えかたです。モバイルファースト/コンテンツファーストをサステナブルに実践するうえで、共有しておきたい、面白い価値観だと思います。

まずは本質の検討を

大事なのは、「モバイルアプリを作ることありき」ではなく、まずは本質的な問いかけとして、下記について熟考することだろうと思います。

• 目的およびゴール。モバイルを使ってどんなビジネスゴールを達成したいのか。
• ターゲットユーザー像。およびそのユーザーの利用コンテキストや利用シナリオ。
• 提供したいユーザーエクスペリエンス (UX)。モバイルを使ってユーザーにどういう体験をしてもらいたいのか。また、どういう感情/印象/評価を持って欲しいのか。

現実的には、上記に加えて、開発や運営に割けるリソース (コストやマンパワー) も含めて総合的に判断することになります。

基本はモバイル Web サイト

多くの企業においてモバイル対応は、(無理にアプリを作らなくても) 基本的にモバイル Web サイトで十分可能なのではないか？と考えています。このように書くとなんだか消極的な印象を持たれてしまいそうですが、「モバイルアプリを作ることありき」な話が案外多いので、上記の「まずは本質の検討を」に立ち返る意味で、少なくとも初めはこのくらい慎重でもよいのかな、と思います。

「基本はモバイル Web サイト」と考えるのは、下記のメリットがあるからです。

• モバイル Web サイトは、インターネット上に公開することによって、検索エンジンにインデックスされたり、ソーシャルメディアなどから直接被リンクを受けたり、といったことが期待できます。Web エコシステムから独立した形で存在するモバイルアプリよりも、集客がしやすい (多くのユーザーに使ってもらいやすい) と言えます。
• モバイル Web サイトは、アプリと違ってインストールが不要なので、ユーザーの手間を減らすことができます。また、アップデート (バージョンアップ) もユーザーの手を煩わせずに済ませることができます。
• モバイル Web サイトは、ブラウザという標準的な (多くのユーザーが慣れ親しんでいる) アプリの中で展開されます。基本的なユーザーインターフェース (UI) やインタラクションはブラウザ側に既に用意されている状態なので、コンテンツのデザイン (設計) に集中することができます。
• モバイル Web サイトは、Web 標準仕様に則って適切に制作されたものをひとつ用意しておけば、様々な OS やデバイスに汎用的に対応させることができます。一方、モバイルアプリは OS ごとにネイティブアプリケーションとして開発する必要があります (対応する OS の数だけ、アプリを開発しバージョンアップ対応することになります)。
• Web サイト制作の汎用的なフロントエンド技術 (HTML5、CSS、JavaScript) でも、リッチなインタラクションを作り込むことが可能になってきています。
• モバイルの強みのひとつと言える位置情報の活用についても、リンクによって別途地図アプリを起動し、ユーザーの現在位置から目的地へのルートを案内する程度であれば、わざわざアプリを作らなくてもモバイル Web サイトで可能です。また、ブラウザも OS 標準のものであれば位置情報サービスに対応しているので、現在位置を自動取得して情報を送信させるといった程度のインタラクションであれば、モバイル Web サイト内で可能です。

モバイルアプリを作るほうがよいケース

「基本はモバイル Web サイト」であるにせよ、上記「まずは本質の検討を」で挙げた観点で熟考した結果、やはりモバイルアプリを作ったほうがよい、という判断に至るケースも当然あることでしょう。下記に該当する場合は、モバイルアプリを作ることも一考です。

• GPS やカメラなど、モバイル機器ならではの機能を、シームレスにアプリ内で提供する必要がある。
• ブラウザ内で標準的に用意されている UI が「足かせ」になる。たとえば、ブラウザのツールバー (「戻る」「進む」「ブックマーク」「新規ウィンドウ」などのボタンが並ぶバー) では機能的に不十分/不適切で別途オリジナルのツールバーが欲しい、使用中の「没入感」が重要なのにブラウザのツールバーが邪魔である、など。
• ブラウザでは不可能なインタラクションを盛り込む必要がある。
• プッシュ通知が必要である。
• インターネット接続が無いときの使用 (いわゆる「ローカル」での使用) を想定している。
• 有料課金したい。
• …など。

モバイル Web サイトとモバイルアプリの境目が曖昧に

「モバイル Web サイト」vs「モバイルアプリ」のような構図で話をしましたが、今後は、サイトとアプリの境目は、下記のように次第に曖昧になってゆくと予想されます。

• モバイル Web サイトは、よりスムーズなインタラクションや豊かなユーザーエクスペリエンスの提供が求められ、次第に「アプリ化」してゆくことでしょう。
• モバイルアプリは、従来のネイティブアプリケーション開発技術 (OS 指定のプログラム言語＋SDK) だけでなく、より汎用性の高い Web 制作技術 (HTML5 + CSS + JavaScript/jQuery Mobile など) が使われるようになってゆくと思います (PhoneGap のように、標準的な Web 制作技術で作られたものをネイティブアプリケーションとしてオーサリングできるツールも出てきています)。

モバイル Web サイトとモバイルアプリの境目の曖昧化という意味で象徴的だなと思うのは、Facebook のモバイルアプリです。以前は、iPhone のホーム画面 (アプリのアイコンが縦横に整然と並んでいる) のごとく、Facebook 内の各機能がアイコン化されダッシュボード表示されていたのですが、現行バージョンでは、画面左側からメニューをスライドさせて開く UI になっています (これは、Facebook のモバイル Web サイトと同じです)。トレンドになりつつあるデザインパターンかもしれませんが (「Gmail」「Path」など、このようにメニューをスライドさせて開く UI を採用するアプリが増えています)、多様な OS/デバイスで共通の UI を提供できるメリットを重視した結果、とも言えそうです。

ちなみに、「Facebook におけるモバイル機器からの投稿数は、モバイル Web サイト (m.facebook.com) がもっとも多い (Android、iPhone、その他のモバイルアプリからの投稿数トータルよりも多い)」というレポート (2011年5月) があります。また、「Financial Times (英国の一流経済紙) は、モバイルアプリよりモバイル Web サイトのほうが多く閲覧されている」というレポート (2011年9月) もあります。上記の「まずは本質の検討を」の観点に立ち、「なぜ、敢えてモバイルアプリを作るのか？」という問いに対して明確な理由を持つことが、モバイルアプリの開発/運用において今後より一層重要になってくることでしょう。

支援技術の大半はセクション間移動が可能 (あとは一般ブラウザでも可能になれば…)

すでに、スクリーンリーダーの大半は (無料で入手できる「NVDA」や「VoiceOver」を含め)、キーボード操作による見出し要素間の移動ができるようになっていますし、WAI-ARIA ランドマーク間を移動できるものも珍しくなくなっています。以前「スキップナビゲーションを実装する」という記事で、「日本で使用されている音声読み上げツールには、見出しナビゲーション機能を持たないものも少なくないので、アクセシビリティの観点から、特にナビゲーションメニューのボリュームが大きいサイトでは、念のためスキップナビゲーションを実装しておくほうがよい」と書きましたが、その後、日本において大きなシェアを持つ「PC-Talker」も、見出しナビゲーション機能を持つに至っています。

情報認知や操作において (視覚のみならず) 音声読み上げにも頼ることができない、という場合は、点字ディスプレイを使うなどの手段がありますが、スクリーンリーダーの機能と併用できることが多い (スクリーンリーダーのショートカットキーを使って操作できる) ため、セクション間移動は十分に可能と考えてよいと思います。また「ブレイルセンスプラス」のようなスタンドアローンの点字入出力デバイスでも、今では機能拡張によって見出しナビゲーションができるようになっています。

もちろん、他にも考慮すべき支援技術はあるかもしれませんし、より確実なアクセシビリティの実現を考えると、今の時点ではスキップナビゲーションを実装しておいたほうが「現実的」と言えるかもしれません。ただ、すでに大半の支援技術においてセクション間移動 (少なくとも見出しナビゲーション) が可能になっている現状、一般ブラウザでキーボード操作によるセクション間移動がもし可能になれば、もはやスキップナビゲーションの存在意義は無くなってゆくのではないか…と考えてみるのも、悪くないと考えた次第です。

スキップナビゲーションを実装する際に考えるべき「煩わしさ」からの解放

ちなみにスキップナビゲーションについて真面目に考えると、実は下記のように、意外と色々なことを考える必要があります (あまり深く考えずに、「他のサイトでやっているから」という感じで実装されてしまうケースもあるとは思いますが…)。もし仮に、スキップナビゲーションの存在意義が無くなれば、これらを考える「煩わしさ」からも解放されることになります。

• スキップナビゲーションは、視覚的に隠すべきか/表出させるべきか？あるいはフォーカスが当たった時だけ表出させるか？
• スキップナビゲーションを視覚的に表出させる場合、Web サイトのビジュアルデザイン (ルック＆フィール) との折り合いをどう付けるか？
• スキップナビゲーションは「グローバルナビゲーションを飛ばしてメインエリアにジャンプする」だけでよいのか？ローカルナビゲーションなどにも飛べるほうがよいのではないか？
• スキップナビゲーションのリンク先 (着地点) は、ユーザーの利用コンテキスト (文脈) 上、問題ないか (ユーザーのスムーズな認知/理解を妨げていないか) ？
• スキップナビゲーションのリンクラベル (リンク元とリンク先の両方) をどうするか？誰でも理解できる平易な表現が可能か？
• 「どこにジャンプするか」だけでなく「何をスキップしたか」という情報も提示する必要もあるのではないか？
• …など。

JIS X8341-3:2010 (WCAG 2.0) における「ブロックスキップ」との兼ね合い

ところで、JIS X8341-3:2010 の達成基準 7.2.4.1 (WCAG 2.0 の 2.4.1) には、「ブロックスキップ」、つまり複数の Web ページ上で繰り返されているコンテンツの塊を何らかの方法で読み飛ばせるメカニズムが利用可能でなければならない、という規定があります。これは、必ずしも「スキップナビゲーションを Web コンテンツ内に記述しなければならない」という意味ではないと思っています。「Web コンテンツが適切にマークアップされて (セクションや見出しがセマンティックに明示されて) いれば、あとはブラウザや支援技術といったユーザーエージェントの側がすべからくそのセマンティクスを解釈し、セクション間を任意にジャンプ移動できる」… そんな利用環境が整っていれば、自ずとこの達成基準は満たされていることになると考えています。

以上、「たられば」な話であることは承知していますが、スキップナビゲーションは本来であればしなくてもよい、小手先の「ハック」だと思っています。そんなハックをわざわざしなくても、本来なすべきこと (Web 標準仕様に基づいたセマンティックなマークアップ) をきちんとしていれば、自ずと Web コンテンツがアクセシブルになる… そんな理想めいたことを、ちょっと思ってみたのでした。

ところが意外なことに、一般的なブラウザ (支援技術ではないブラウザ、ここでは Internet Explorer、Firefox、Google Chrome、Safari、Opera を指します) では、キーボード操作によるセクション間のジャンプ移動ができません。これらのブラウザ (以下、便宜的に「一般ブラウザ」といいます) のユーザーはマウスを使うことが多いため、キーボード操作によるブラウジングはさほど重要視されていないのかもしれません。その一方で、目が見えて、かつマウスではなくキーボードによる操作のほうが好都合なユーザーも少なくなく (たとえば、手指などの障碍/怪我を持っていたり、ロービジョンであったり)、こうしたユーザーにとって現状は不便だと言えます。特にマルチカラムで情報量が膨大な Web ページの場合、読みたいコンテンツにアクセス (リンク) するために [Tab] キーを何度も何度も押さなければならない… という状況に陥りがちです。

この記事では、一般ブラウザにも対応してもらえたら嬉しいキーボード操作によるセクション間移動について、(スクリーンリーダーとも比較しつつ) 考えてみたいと思います。

見出し要素間の移動

Web コンテンツの見出しは、HTML の <h1>、<h2>、<h3>…要素でマークアップします。大半のスクリーンリーダーには、見出しナビゲーション機能 (<h1>、<h2>、<h3>…でマークアップされた箇所だけを辿って読み上げる機能) が既に用意されています。一方、ほとんどの一般ブラウザには、現時点では見出しナビゲーションの機能は用意されていません。

ひとつだけ、Opera は例外です。[S] キーを押すと次の (下の) 見出しに、[W] キーを押すと前の (上の) 見出しに、それぞれジャンプすることができます (こうして見出しにフォーカスを当てた状態で、 [Shift]＋上下矢印キーを押すと、そのフォーカス位置を起点にして近隣のリンク箇所にフォーカスを移動することができます)。このキー操作をするには事前設定が必要で、Opera メニューの「設定」画面で行ないます。「詳細設定」タブの「ショートカット」の中に「キーボード設定」というパラメーターがあるので、そこで「Opera 9.2 Compatible」を選びます。

WAI-ARIA ランドマーク間の移動

アクセシビリティに特化した Web 標準仕様として WAI-ARIA があります。もともと RIA (Rich Internet Applications) をアクセシブルにするために策定された仕様ですが、この中の「ランドマーク (Landmark Roles)」は、リッチな UI を持たない一般的な Web サイトでも採り入れることができます (<div> などの要素に「role=”xxx”」属性を記述することで、セマンティックにセクションの種類を明示するものです)。

スクリーンリーダーには、キーボード操作によってセクション (ランドマーク) 間をジャンプ移動できる機能が備わっているものが多いです。無料のスクリーンリーダー「NVDA (Windows PC)」や「VoiceOver (iOS)」も、ランドマーク間の移動に対応しています (具体的な使用方法については、記事「WAI-ARIA のランドマーク (Landmark Roles) を設置する」の「支援技術での利用例 (スクリーンリーダーで試してみる)」をご参照ください)。

一方、一般ブラウザには、現時点ではランドマーク間をキーボード操作で移動できる機能は備わっていません。

HTML5 セクション間の移動

W3C が策定する最新の HTML 仕様「HTML5」を用いると、<header>、<nav>、<aside>、<footer>…といった要素によって、ドキュメント (ページ) 内のセクションをセマンティックに明示することができます。

現時点では、HTML5 形式でマークアップされたセクションをそのまま認識できるスクリーンリーダーは無く、同等の WAI-ARIA ランドマークを併記するのが現実的のようです (<header role=”banner”>、<nav role=”navigation”>、<aside role=”complementary”>、<footer role=”contentinfo”>、といった具合)。ちなみに「NVDA」は (Firefox と一緒に使っている場合)、WAI-ARIA ランドマークの併記が無くても HTML5 形式のセクションを一応は認識してくれるようですが、便宜的に同等のランドマークと見做して解釈するようです。たとえば <nav> 要素は「ナビゲーション」として (role=”navigation” と見做す)、<aside> 要素は「補足情報」として (role=”complementary” と見做す)、>footer< 要素は「コンテンツ情報」として (role=”contentinfo” と見做す)、それぞれユーザーに提示されます。

一般ブラウザでも、現時点では、HTML5 形式のセクション間をキーボード操作で移動できる機能は、備わっていません。

一般ブラウザに期待したいセクション間移動の挙動

キーボード操作によるセクション間の移動について、見出し要素、WAI-ARIA ランドマーク、HTML5 形式のセクション、という3つの観点で見たわけですが、スクリーンリーダーはそれなりに対応できていても、一般ブラウザはまったくと言ってよいほど対応できていないことがわかります。アクセシビリティは視覚障碍者だけに対する配慮ではないので、一般ブラウザにおいてもキーボード操作によるセクション間移動が可能になることによって、アクセシビリティの裾野が大きく広がると思います。

その際、一般ブラウザに具体的に期待したい挙動としては、以下が考えられます。

上記の機能を実際に一般ブラウザに持たせるにあたっては、スクリーンリーダーとの様々なコンフリクトが課題になることが予想されます。使用可能なショートカットキーの組み合わせはもちろんですが、「一般ブラウザでの表示内容をスクリーンリーダーで読み上げる」という使いかたをする場合、ユーザーはどちらのショートカットキーを選んでセクション間を移動するべきか、という問題も出てきそうです。解決策として、一般ブラウザ側のキーボード操作 (ショートカットキーの機能) はオプションにする (またはベンダー公式のアドオンにしてユーザーの任意で提供する) という形も考えられますね。

• 初心者ユーザーやシニアユーザーは、別ウィンドウで開いたことに気づかないことが多い。特にブラウザを最大化表示している場合、ウィンドウが完全に重なった状態 (元ページが完全に隠れた状態) になってしまい、かつ、前面に出ている (別ウィンドウとして表示された) ブラウザ画面では [戻る] ボタンがグレーアウトしているので、ユーザーは「前のページに戻れない」と戸惑ってしまう。
• 視覚などの障碍や手指の怪我などでマウスが使えない (キーボードを使って操作する) 場合、別ウィンドウとして開いたページから元ページに戻ろうとすると、結構面倒である ([Alt] ＋ [Tab] キーを必要な回数だけ押して、アクティブにするウィンドウを順番に切り替えるが、ブラウザ以外のアプリケーションが開いている場合はそれらもアクティブにする順番として含まれるので、スムーズにウィンドウが切り替えられなかったり、ユーザーに余計な記憶負荷/認知負荷をかけることにつながる)。

その後のユーザー環境の変化

上記の記事を書いた当時は、PC の画面解像度が低く、ブラウザを最大化表示するケースがよく見られました。このため、リンク先ページが別ウィンドウとして開くと、リンク元ページの上に完全に重なることがしばしばでした。

その後、PC の画面解像度は飛躍的に高くなりました。また、いわゆるタブブラウザが「当たり前」になってきました (<a target=”_blank”> が指定されている場合、新規ウィンドウではなく新規タブで開くことがほとんどです)。これにより、リンク元ページが (別ウィンドウとして開いた) リンク先ページの下に完全に隠れて認識できない…といったケースはだいぶ減ってきたと言えます。

タブブラウザはアクセシビリティの面でも便利になっています。アクティブなタブを切り替えるキーボード操作 ([Ctrl] ＋ [Tab]) は、ブラウザ内で開いているタブだけが対象となるので、[Alt] ＋ [Tab] キーでアクティブなウィンドウ (ブラウザ以外の起動中アプリも含む) を切り替えるよりも、だいぶ楽になっています。

そして私自身、一個人としてタブブラウザを日常的に使用するようになってからは、むしろ複数ページを並列的に開く使いかたが増えたように思います。

こうした変化を鑑みると、「リンクを別ウィンドウで開かない」ことに固執する必要は、あまり無いのでは…？という意見が聞こえてきそうです。ちなみに HTML5 では、<a> 要素の target 属性は valid であると認められています。

それでも基本は別ウィンドウで開かない

上記のようなユーザー環境の変化はありますが、リンク先ページは別ウィンドウ (別タブ) で開かないことが、やはり基本だと思っています。少なくとも、リンク先が同一サイト内である場合は、原則として同じウィンドウ内で表示を切り替えるべきだと思います。

そのもっとも基本的な理由は、「開くウィンドウ (タブ) が多くなると、それなりにユーザーに認知負荷がかかる」からです。ユーザー自らの任意で別タブを開くのであればまだしも、自分の意思と関係なくタブが開いてしまうと、ユーザーは (本来の目的達成とは別の心理的エネルギーを割いて) 別タブが開いていること (あるいは開くかもしれないこと) を認識せざるを得なくなります。「今クリックしたリンクは別ウィンドウで開いたけど何か意図があるのか？」「ここにあるリンクはクリックすると、別ウィンドウで開くのかな？あるいは同じウィンドウで開くのかな？」といった具合です。

また、意外にありがちなのは、「まわりまわって同じページが別タブで開く」ことです。たとえば「ページ A」からリンク (<a target=”_blank”>) で「ページ B」を開いたとします。その後のページ遷移を経て再び「ページ A」にリンクすることがあると思いますが、そうなると「ページ A」が2つのタブで同時に開いている状態になります。同一ページが複数のタブで開いているというのは不自然な状況ですし、混乱の元にもなりかねません。

さらに、サイトをモバイル (スマートフォン) で閲覧している場合は、別タブではなく別ウィンドウで開きます (リンク元ページがディスプレイの表示範囲外に押しやられる形です)。PC のタブブラウザがワンクリックでページを切り替えられるのと異なり、モバイル環境ではユーザーに、より「モーダルな状態」を強いることになることも念頭に置いておくとよいでしょう。

個人的にはリンク先を別タブで開くこと (スマートフォンの場合は別ウィンドウで開くこと) に対する抵抗感は無く、むしろ便利だと思うこともあります。Web の利用に長けている皆さんも同様だと思いますが、ただそれは、個々人の使いかたのクセに過ぎないことを理解しておきましょう。別ウィンドウ (別タブ) で開くかどうかは、あくまでも個々人のユーザーごとに任せるべきです。PC の場合はリンク箇所を右クリックすることで、iOS や Android であればリンク箇所を長押しすることで、オプションを選択できます。数回学習すれば簡単に取得できる操作ですから、必要な人が必要に応じてやればよいだけの話です。

別ウィンドウで開くならルールを決める

どうしてもリンクを別ウィンドウで開くのであれば、自身が運営するサイトの中で、どういった類のリンクであれば別ウィンドウで開くのか/同一ウィンドウで開くのか、というルールを明確に決めておくことが求められます。特に複数のスタッフでコンテンツを更新している場合、スタッフの独自判断に委ねてしまうと、なし崩し的に、同一サイトでウィンドウが無秩序に開くという状況を招く恐れがあるからです。

ルールを決める際には、そのルールがユーザーのメンタルモデルに合致していることが重要です。メンタルモデルとの乖離があると、つまりユーザーの想定外にウィンドウが開くと、認知負荷の増大やフラストレーションにつながります。基本的にユーザーは「単にリンクしたいだけ」「目的の情報に辿り着きたいだけ」であることを意識し、本当に別ウィンドウで開かなければならないリンクなのか、慎重に判断したいものです。

許容されるケース

基本原則は (少なくとも同一サイト内へのリンクは) 別ウィンドウで開かないことですが、上述したユーザー環境の変化に伴って、リンクを別ウィンドウを開くことが許容されるケースも現実的にはあると思います。

ひとつは、PDF ファイルや画像ファイルがリンク先になっている場合です。サイト共通のナビゲーションシステム (グローバルナビゲーションやローカルナビゲーションなど) を適用できないから、という理由もありますし、特に PDF の場合、別途アプリケーション (Acrobat Reader) の起動に時間がかかるので、リンク処理中の「空白 (ユーザーが何もできない状態)」を作らないために別ウィンドウで開く、という判断はアリだと思います。

また、サードパーティが公式にリリースしているウィジェットを自身の Web ページに埋め込む場合、そのデフォルトの挙動として、リンク先が別ウィンドウで開いてしまう場合があります (たとえばソーシャルメディアのシェアボタンなど)。提供されるウィジェットのソースコードを改変できず妥協するという現実的な側面もありますが、そのウィジェットが多くのユーザーにとってポピュラーなもので、その挙動がデファクトスタンダードとしてユーザーのメンタルモデルに照らし合わせて問題なければ、許容範囲かな…と思います。

上記以外にも、ユーザー行動の観点から、リンクを別ウィンドウで開くのが妥当と言える場合があるかもしれません。いずれにしても、これらの許容については、できれば実際にユーザビリティテストを実施してみて、問題無いことを確認するのがよいでしょう。

Web コンテンツは、少なくとも初めは、じっくり読んでもらえない (斜め読みされる) ことが多いものです。このため、まずは見出しだけを一瞥してコンテンツの概要が把握できることが大事になります。逆に、見出しを読んでもユーザーが概要をつかめない (いまひとつ、何が書いてあるのかピンと来ない) ようだと、そのまま結局コンテンツを読んでもらえない恐れがあります (それがビジネス上、重要なコンテンツである場合は、結果的に「機会損失」につながります)。

また、大半のスクリーンリーダー (主に視覚障碍者が使用する音声読み上げソフト) には、見出しナビゲーション機能 (見出し要素、つまり<h1>、<h2>、<h3>…でマークアップされた箇所だけを辿って読み上げる機能) が用意されています。適切な見出しを付けることは、アクセシビリティの面でも有効と言えます。

見出しを書くコツ

コンテンツの概要が把握できるように、さらにコンテンツをじっくり読んでもらえるように、見出しを適切に付ける必要があるわけですが、実際に見出しを書くにあたっては、いくつかコツがあります。

• コンテンツの骨子を抽出し、見出しとして表出させる。
• ユーザーにとって意味のある、有益な内容の見出しにする。
• 下に紐づいている段落の、キーとなるメッセージをサマリーする。
• 当たり障りのない曖昧な見出し (たとえば「～とは？」「～について」など) はできるだけ避け、より具体的に書く。
• キャッチーであるよりも明解であることを基本的に重視する。
• ユーザーの使用語彙 (検索エンジンに入力するであろうキーワード) を盛り込む。
• ユーザーが理解できる表現にする (専門用語、隠語、略語など、ユーザーが理解できるかを注意する)。
• できるだけ簡潔に書く。
• 正しい階層構造にする (<h2> は必ず <h1> の下に、<h3> は必ず <h2> の下に…といった具合に)。
• 同階層の見出しは、同じスタイルで書く (パラレリズムを適用する)。

以上、参考になれば嬉しいです。これらはいずれも、基本として私自身普段から意識していることですが、Web サイトの要件によっては、これ以外にも色々なテクニックやノウハウが必要になることもあるかと思います (たとえば、魅力的なコピーライティングなど)。皆さんで工夫していることなどありましたら、ぜひコメントいただければと思います。

ソースコードの冒頭 (<head> 要素内) に必ず記述しなければならない大事な要素ですが、意外に無頓着な Web ページ (サイト) が少なくありません。この記事では、Web ページのタイトル (<title> 要素でマークアップされた情報) が「どんなふうに使われているか」を踏まえたうえで、「どう記述すればよいか」を確認したいと思います。

タイトルはどんなふうに使われるか？

タイトル (<title> 要素でマークアップされた情報) は、様々な場面で使われます。冒頭で述べたブラウザのタイトルバーやタブのほか、ブックマーク (お気に入り) や閲覧履歴のリスト表示に使われているのを見たことがあるでしょう。

また、スクリーンリーダー (音声読み上げソフト) を使っているユーザーの場合、ページを開いたときに最初に読み上げられるのがこのタイトルです。「自分がどこにアクセスしたのか？」を知るうえで、大切な手がかりになります。

タイトルは当該サイトの外にも提供されます。来訪していない人に対してタイトルを提示し、サイト (ページ) に誘導するという機能を持ちます。具体的には、以下が挙げられます。

• 検索エンジンにおける検索結果表示 (SERPs)
• RSS リーダー
• ソーシャルメディア (SNS、Twitter、ソーシャルブックマーク、など) での共有

タイトルはどう書けばよいか？

上記に挙げた例から考えると、タイトルの内容はユーザビリティやアクセシビリティの面で重要な役割を担っていると言えます (今アクセスしているページをユーザーに伝えるだけでなく、ユーザーを自サイトへ誘引する行動喚起要因 (Call to Action : CTA) にもなり得ます)。そう考えると、タイトルの記述は十分に気をつけたいところですね。具体的には、以下に留意するとよいでしょう。

• ページの内容 (主題や目的など) を明確に表現する。
• ユーザーにとって馴染みのある語句 (理解語彙よりも使用語彙が望ましい) をキーワードとして盛り込む。
• 重要な語句 (ページ内容を特徴づける/他のページと識別する手がかりとなる語句) はタイトルの最初のほうに置く。
• タイトルの末尾には、(ページに対する信頼性をユーザーに与えるため) サイト名/ブランド名/運営者名 (企業名) を明記する。
• なるべく少ない文字数でまとめる (ユーザーの使用する環境/ツールによっては、ごく小さな領域にタイトルが表示されるので)。

これらの留意事項に気をつけていると、自ずと各ページごとにユニークなタイトルになるはずです。くれぐれも、サイト内のどのページを見ても同じタイトルになっている…ということのないようにしましょう。

また、タイトルはできるだけ、そのページの大見出し (<h1> 要素の記述) と同内容にするのが無難です。たとえば検索エンジンの結果表示で目にしたタイトルに興味を持って、自サイトのページにアクセスしたとき、いちばん目につく大見出し (<h1>) が異なった内容になっていると、ユーザーが戸惑う可能性があるからです。多くの CMS (ブログ作成ツールを含む) では初期状態でそのような設定になっていると思いますが、念のため確認しておくとよいでしょう。

タイトルを書くのに適切な文字数は？

ところで、「タイトルを書くのに適切な文字数はどのくらい？」という質問を受けることが時々あります。一概に何文字以内ならベスト、とお答えするのは難しい…というのが正直なところです。一応の目安として (日本語/全角文字の場合) 30から35文字程度に収める、という説がよく聞かれますが、これは各検索エンジンの検索結果表示 (それも PC で閲覧した場合) から割り出されたもので、流動的と言えます。

検索エンジンの結果表示 (PC だけでなくスマートフォンも含めて)、ブラウザのタブ表示、ソーシャルメディアのウィジェットや各種アプリケーション (スマートフォン用アプリも含めて)、などユーザーがよく利用するツールで実際に検証してみて、限られた表示領域であってもファインダビリティを十分確保できるか (ページ内容をユーザーが識別できるか/ユーザーにアピールできているか) を確認するのがよいでしょう。

特に最近は PC と言えども Google Chrome のようにタイトルバーが無いブラウザも登場しており、タブにしかタイトルが表示されないケースが増えつつあります (Windows 版の Firefox や Opera もこのトレンドに乗っていて、初期状態では Google Chrome と同様、タイトル表示はタブのみになっています)。必ずしもタブの中に完全にタイトルが収まる必要性はありませんが (たくさんタブを開くと次第にタブが狭くなるブラウザもあるので、そもそも無理です…)、近年叫ばれているモバイル/スマートフォン対応とも相まって、簡潔かつストレートに伝わるタイトル記述が今後ますます重要になってくるのは確かだと言えそうです。

今回は久々の「Web ライティングのツボ」ですが、「簡潔な文章表現」に焦点を当ててみたいと思います。

簡潔な文章表現が求められる時代

近年、Web の閲覧環境が急速に多様化しています。従来であれば、PC (デスクトップ) からの閲覧が大半でしたが、スマートフォンの普及によって、モバイル端末からアクセスされることも普通になってきました。

PC (デスクトップ) 以外でも Web にアクセスできるようになると、ちょっとしたスキマ時間や移動中/歩行中のように「じっくり腰を据えていない」状況であっても、情報を素早く読み取りたい、というユーザーの欲求が高まります。もともと、Web の文章はじっくり読まれない (斜め読みされる) ものではありましたが、その傾向はますます顕著になりそうです。

また、Siri のような音声認識ユーザーインターフェースがにわかに注目されていますが、「目や手が離せない」状況で、音声読み上げされた Web コンテンツを「聞く」(シリアルに情報を読み取る) という行為も将来的には一般的になってゆくような気がします。

こうした状況を勘案すると、Web コンテンツの制作においては、簡潔に文章を表現するスキルが、今後より一層求められるようになるのは間違いないだろうと思います。

簡潔な文章表現のコツ

簡潔な文章表現を実現するためには、押さえておきたいコツがあります。

基本は、「テーマを絞って、そのテーマで本当に伝えたいことだけを書く」です (「当たり前」と思われるかもしれませんが… 自分の知見を誇示しようと、つい、あれもこれも書いてしまう、という罠に陥ることがあるので要注意です)。

そのうえで、いくつかテクニック的なことをご紹介します。上記に挙げた「Web ライティングのツボ」の各記事で触れているノウハウにプラスアルファして、私が個人的に気をつけていることです。

• すべての段落/センテンス/語句に、存在する必然性があること。仮に無くても文章の意味が変わらないような段落/センテンス/語句であれば、削除する。
• 形容詞や副詞を減らす。どうしても必要な形容詞/副詞であれば、適切な位置に配置する (形容詞なら係る名詞に、副詞なら係る動詞に、それぞれ近接させる)。
• 受動態より能動態で表現する。
• 否定形でなく肯定形で表現する。
• 一語で表現できるものは短かくまとめる。(例 : 「企業が運営するサイト」→「企業サイト」)
• 「～を行なう」「～をする」といった表現をしない。(例 : 「品質の検証を行なう」→「品質を検証する」)
• 無駄な冗長 (丁寧すぎる説明や繰り返し) を避ける。

加えて、意外に効果的だと感じているのは、見出し構成 (＋各見出しの本文内容のひとこと要約) 程度の粒度で構わないので、文章の概要を空 (そら) で言ってみることです (口頭で伝えるような感じで)。そこでスラスラと言えれば、その文章で伝えたいことが明確であると言えます。逆に、スラスラと言えず詰まる、あるいは何かしっくりしない感じがする場合は、どこかで論理矛盾を起こしていたり、テーマに無関係な内容が盛り込まれている可能性があります。また、空 (そら) で言えるということは、伝えたいことが短期記憶の範囲内に収まるということでもあるので、読み手がコンテンツ内容を理解する際の認知的な負荷を軽減できる、ということも期待できそうです。

以上、参考になれば嬉しいです。もちろん、簡潔な文章表現のためのノウハウは他にも色々あるかと思います。皆さんで工夫していることなどありましたら、ぜひコメントいただければと思います。

ちなみに「Pervasive」とは「至る所に広がる、行き渡る、まん延する」といった意味です。「Inforrmation Architecture (情報アーキテクチャ)」が対象とすべき範囲 (情報デザインの対象) は、顧客の消費行動全体に亘りますよ、というお話です。

情報アーキテクチャの対象の広がり

従来、情報アーキテクチャといえば、Web サイトの情報をどう設計するか、という議論が中心でした。もちろん、それは現在、そして今後においても、とても大事なことです。

ただ、実際の消費者の購買行動 (あるいはサービスの利用行動) を見ると、Web だけで完結していることは稀で、実店舗やコールセンター、紙媒体（チラシだったりカタログだったり）など、様々なチャンネルが顧客タッチポイントになっています。私たちが請け負う仕事のスコープが「Web サイトの」設計や制作に限定されるとしても、単に Web サイトのことだけを考えていれば済むというのではなく、クライアントの顧客である消費者の行動全体を視野に入れて、様々なチャンネル (顧客タッチポイント) も含めて一貫したユーザーエクスペリエンス (経験価値) を提供できるよう、デザインを工夫/改善してゆくことが求められるのです。

また、昨今のスマートフォンの普及によって、ひとくちに「Web」といっても、PC (デスクトップ) で見る場合だけでなく、モバイル環境で見ることも一般的になってきました。情報の利用がユビキタス (いつでも、どこでも…) になってきたばかりでなく、ユーザー自身の状況に応じたインタラクションも可能になっています (GPS/位置情報によって経路探索や周辺のおすすめを調べたりなど)。こうした Web の使われかたの変化を鑑みても、顧客の消費行動全体を視野に入れてデザインすることの重要性をうかがい知ることができます。

「Web サイトだけの情報アーキテクチャを考えていれば済む」わけではない、というのは私たち自身 (や家族/友人など) の普段の消費生活を振り返ってみれば「当たり前」と言えそうですが、情報アーキテクチャの専門書/啓蒙書で、こういう視点に立った議論が今まで (多分あまり) 無かったという意味で、本書は画期的と言えます。様々な顧客タッチポイント間をまたいで構築される (クロスチャンネルな) 情報アーキテクチャとはどういうものか？を体系的に考えるきっかけとして、とても面白い本だと思います。

ユーザーと情報の関係

クロスチャンネルな情報アーキテクチャを考えるにあたり、その前提として「ユーザーと情報の関係はどう変わってゆくのか？」「情報はどうデザインされ、ユーザーはどう行動するようになるのか？」について理解しておきたいところです。本書では、マニフェスト (声明) のような形で、次のようにまとめられています。

Information architectures become ecosystem

情報アーキテクチャは、多くのチャンネルや顧客タッチポイントを連携するエコシステムを形作るものになる。

Users become intermediaries

ユーザーは受動的な消費者ではなく、エコシステムの中で能動的な媒介として (自ら情報発信するなどして) 行動するようになる。

Static becomes dynamic

情報は (特定のチャンネルだけに存在するのではなく) 編集/加工されて様々なチャンネルで展開されるようになる。また媒介であるユーザーによって改変されるようになる。

Dynamic become hybrid

情報アーキテクチャは様々な違い (デジタルなデータか物理的なモノか、など) をまとめて取り込むようになり、異なるメディア間に存在していた垣根を低くしてゆく。

Horizontal prevails over vertical

特定チャンネル内部の階層構造よりも、異なるチャンネル間の関係性が重要になってくる。

Product design becomes experience design

ある特定の「モノ」をデザインするよりも、そのモノや関連するサービスを含めた「体験」をデザインすることが重要になってくる。

Experiences become cross-media experience

「体験」は単一のメディアよりはむしろ、クロスメディアでの体験が当たり前になってゆく。

5つのヒューリスティクス

上記のように今後、ユーザーと情報の関係が変わってゆくことは、受け入れなければならない事実だと言えます。では、これを受け入れたうえで、実際にどうデザインとして解決してゆけばよいのでしょうか。

本書では一貫して、「5つのヒューリスティクス (heuristics : 問題解決に役立つ知見)」が採り入れられています。これらは、pervasive な情報アーキテクチャを検討/設計するうえで意識すべきはたらき (the capability of a pervasive information architecture model) として、定義されています。

Place-making (場の創造)

the capability of a pervasive information architecture model to help users reduce disorientation, build a sense of place, and increase legibility and way-finding across digital, physical, and cross-channel environment.
方向感覚を失わないように支援し、場の感覚 (「そこにいる」感覚) を作り、どの環境/チャンネルを利用していても情報や道筋を見つけやすくすること。

Consistency (一貫性)

the capability of a pervasive information architecture model to suit the purposes, the contexts, and the people it is designed for (internal consistency) and to maintain the same logic along different media, environments, and times in which it acts (external consistency).
目的、コンテキスト、人に適合させ (＝内部における一貫性)、さらにそれを、異なるメディア、環境、時間にも適合させる (＝外部における一貫性) こと。

Resilience (復元力)

the capability of a pervasive information architecture model to shape and adapt itself to specific users, needs, and seeking strategies.
特定のユーザー、ニーズ、探求のしかたに適応するように、情報を形作ること。

Reduction (簡素化)

the capability of a pervasive information architecture model to manage large information sets and minimize the stress and frustration associated with choosing from an ever-growing set of information sources, services, and goods.
膨大な情報群を管理し、増え続ける選択可能性 (情報、サービス、モノ) によってもたらされるストレスやフラストレーションを極力小さくすること。

Correlation (相関関係)

the capability of a pervasive information architecture model to suggest relevant connections among pieces of information, services, and goods to help users achieve explicit goals or stimulate latent needs.
断片化して存在する情報、サービス、モノを関連付けて (つなぎ合わせて) 提示し、目的の達成や潜在ニーズへの気づきを支援すること。

具体的にどう実践するか？

本書で掲げられているマニフェストやヒューリスティクスをもとに、具体的に自分のサイト (あるいはサービス全体) でどう情報アーキテクチャを実践してゆくか。Web サイト以外のチャンネル (顧客タッチポイント) も含めトータルで考えるとなると、こればかりはケースバイケースで最適解がまったく異なると言えます。

情報アーキテクチャの古典的バイブルとして有名な「Web 情報アーキテクチャ」(Louis Rosenfeld 氏と Peter Morville 氏による、いわゆる「しろくま本」) には多くの具体的なハウツーが書かれているのに対し、どちらかというと本書は、考えかたのヒントを提示してくれる感じです (いくつか、参考になるケーススタディは載っていますが)。実際、本書は、その内容について「for discussion, not worship (あくまでも議論の叩き台であって、盲信の対象ではない)」と明言しています。

Web の情報設計に関わる身としては、本書によって得られる新しい視点をもって、改めて「しろくま本」などをベースに創り上げられてきた Web の情報アーキテクチャのありかたを見つめ直してみる (従来の情報アーキテクチャに対して、個々のプロジェクトなりの、建設的なフィードバックを返してみる) ことが、具体的な実践方法を見出すための第一歩になるかなと思っています。