「ウェブ解析士だより」の読者の皆さん、はじめまして。Website Usability Info というサイトで、ウェブのユーザビリティやアクセシビリティ、情報アーキテクチャ (IA) などに関する話題を発信しています土屋と申します。よろしくお願いします。
ウェブ解析士の資格をお持ちの皆さんは、日々の制作や運用業務の中で、あらゆるデータをもとにウェブサイトの改善に向き合っておられることと思いますが、きっとその根底には「ユーザーを第一に考える姿勢」があることでしょう。ユーザーが実際にサイトを利用し、スムーズに目的を達成したり自らの課題を解決したりすることで、KGI や KPI といった指標にもよい影響が出てくるからです。そのために、アクセス解析や A/B テスト、その他様々な手法を駆使して、ユーザーの行動や志向を予測したり仮説立てしたりして、様々な打ち手を講じているのではないでしょうか。
さて、この「ユーザーを第一に考える姿勢」を意識していただく中で、ぜひ気に留めてほしいのが「アクセシビリティ」です。もしかして耳慣れない方がいらっしゃったり、聞いたことはあってもよくわからない、自分の仕事には直接関係ない、とお思いの方もいらっしゃるかもしれませんね。しかしウェブの基本品質のひとつとして今後ますます重要になってゆく考えかたなので、ぜひ皆さんと一緒に考えてゆきたいと思います。
アクセシビリティとは？
「アクセシビリティ (accessibility)」とは、「access (アクセスする)」＋「〜ible (〜できる)」(の名詞形) であり、ウェブという観点で考えると、アクセシビリティとはすなわち「ユーザーがウェブサイト上の情報に接することができること (コンテンツが利用可能な状態にあること)」を意味します。
ISO 9241-20 では、「アクセシビリティ」は以下の通り定義されています。
the usability of a product, service, environment or facility by people with the widest range of capabilities. (様々な能力を持つ幅広い層の人々に対する、製品、サービス、環境または施設のユーザビリティ。)
上の定義は「ユーザビリティ」との絡みで記述されていますが、つまりアクセシビリティとは「ユーザーの多様性を尊重したユーザビリティ」と捉えることができます。多種多様な利用文脈 (置かれている状況や身体的特性など) を抱えたユーザーが、それでも問題なくウェブコンテンツを利用でき、自らのゴールを達成できることが、大事だと言えるでしょう。
アクセシビリティという言葉でよく抱かれるイメージとしては、障害者対応かもしれません。実際、ウェブコンテンツは様々な障害者でも利用可能であるという特性を備えています。以下の動画 (YouTube 総務省動画チャンネル) をご覧いただくとよくわかりますが、一見、視覚的な GUI と思われがちなウェブコンテンツも、実は様々なモダリティ (情報の入出力の形態) に変換しての入出力が可能であり、たとえ目が見えない/見えにくい人でも利用できる、というのは大変興味深いです。
視覚障害者（全盲）のウェブページ利用方法
視覚障害者（弱視）のウェブページ利用方法
しかしアクセシビリティは、いわゆる障害者対応だけには限定されません。健常者のウェブ利用のしかたの変化を見ても、たとえばスマートフォンの登場によって、モバイルでユビキタス (いつでもどこでも) なウェブ利用が当たり前になってきました。屋外の自然光がまぶしくて画面が見にくい、画面が狭くて認知/記憶負荷が高い、集中を阻害する要因がそこかしこにある、公共の場所で音が出せない、回線状況で画像が表示できない、などなど…。こうした利用状況の多様化も含めて、あらゆるユーザーがウェブを利用できるようにすることが、アクセシビリティなのです。
基本品質としてのアクセシビリティ
「ウェブの父」と呼ばれている、Tim Berners-Lee (ティム・バーナーズ – リー) 氏の言葉で、とても印象的なものがあります。
The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect. (ウェブが優れているところは、その広い汎用性である。障害があるか否かに関わらず、誰でもアクセスできるということは、ウェブにとって不可欠な特徴なのである。)
Tim Berners-Lee, W3C Director and inventor of the World Wide Web
この言葉が示すように、アクセシビリティはウェブというコミュニケーション手段ならではの強みであり、アクセシビリティを担保することは、ウェブコンテンツの基本品質であると理解できます。実際、W3C は WCAG (Web Content Accessibility Guidelines) というガイドラインを勧告していて、それが世界標準になっています。WCAG のバージョン 2.0 (*註) は正式に ISO/IEC 国際規格として承認されており (ISO/IEC 40500:2012)、その一致規格として JIS X8341-3:2016 が公示され日本でも以下のように多くのウェブサイトが対応しつつあります。
*註 : WCAG は、2018年6月5日にバージョンアップし、2.1 が勧告されました。ISO/IEC 国際規格や JIS X8341-3 への反映は、今後検討がなされてゆくと思われます。
基本品質という観点から考えると、法制面からの要求も見逃せません。日本の障害者差別解消法では、あくまで努力義務として合理的配慮が求められるに留まっていますが、海外では、ウェブアクセシビリティ担保の法制面での義務化が広まりつつあります (ご参考 : Web Accessibility Laws and Policies – W3C)。グローバルに事業展開をされているサイトを制作したり運用している場合は、注意が必要です。
なお、欧米ではメジャーな IT 系企業を中心に、アクセシビリティの選任担当者を置くところが増えています。たとえば Microsoft、Apple、Google、Slack、Facebook、Airbnb、… などが挙げられますが、面白いのは、アクセシビリティへの取り組みが、こうした企業のブランド価値向上にも寄与し得ることです。Apple の「アクセシビリティ」ページ冒頭の動画はとてもエモーショナルで、アクセシビリティとブランディングの融合の好例と言えるでしょう。
どう取り組めばいいの？
では実際に、皆さんが制作/運用しているウェブサイトのアクセシビリティを向上させるには、どうしたらよいのでしょうか。ウェブコンテンツの作りかたに関しては、上述のとおり WCAG という世界標準のガイドラインが既にあるので、それに倣うことでアクセシビリティを担保することができます。ただし WCAG は読み解くのが簡単ではありません。追々機会があれば、じっくりと解説させていただければと思いますが、ここではエッセンスをまとめてみました。
画像やアイコンの代替テキスト
画像やアイコンといった視覚的なコンテンツ表現は、晴眼者には理解可能ですが、視覚障害者、特に全盲のユーザーは内容や意味が理解できません。スクリーンリーダー (画面読み上げソフト) を使っている視覚障害者も理解できるように、画像 (<img> 要素) には alt 属性を付けて代替テキストを記述しましょう。また、アイコンなど alt 属性を持たせることができない要素の場合は、aria-label 属性を使って代替テキストを記述することができます。
見出し構造
ウェブコンテンツに見出しが適宜付けられていれば、飛ばし読みができるので、ユーザーの認知負荷の軽減につながります。スクリーンリーダー (画面読み上げソフト) を使っている視覚障害者も、見出しが適切にマークアップされていると (<h1>、<h2>、<h3> …)、見出しだけを飛ばし読みすることが可能になるので、コンテンツの概要をスムーズにつかむことができます。
見出しと言えば、テーブル (表) 内にも、各々の行または列の見出しとして機能するセルがあります。これらのセルは <th> 要素でマークアップしておくと、視覚障害者がテーブル内を回遊してデータを読む際に、大きな助けになります。
音声読み上げ順序
画面に視覚的に表示されるウェブコンテンツは晴眼者にとっては二次元的ですが、スクリーンリーダー (画面読み上げソフト) を使ってページを音声で読み上げる視覚障害者にとっては、一次元的な情報取得になります。スクリーンリーダーを使う視覚障害者は全盲とは限らない (弱視のユーザーも含まれる) こともあり、音声読み上げ順は、視覚的な画面レイアウトと合っている必要があります。音声読み上げ順は基本的にページの HTML ソースの記述順なので、CSS を適用する際に突飛なレイアウトにしないよう、気をつけましょう。「モバイルファースト」の思想で、ワンカラムで基本設計をするのがおすすめです。
色のコントラスト
薄い文字は、視認性が悪く読みにくいため、肝心な情報がユーザーに伝わらない恐れがあります。特に弱視のユーザーにとってはクリティカルな問題ですし、老眼のユーザーや、スマートフォンで屋外 (自然光の下) でウェブ利用をする人にとっても、読むのが厳しくなります。背景色と文字色の間には、十分なコントラストを保つようにしましょう。カラー・コントラスト・アナライザー のような無料のツールで簡単にチェックできます。
テキストによる文字表現
文字情報はなるべくテキストで表現し、文字画像は避けるようにしましょう。タイポグラフィにこだわりがある場合も、最近はウェブフォントが実用的に使えるようになってきているので、積極的に検討したいものです。
文字情報をテキストにすることで、以下のメリットがあります。
- ズームしても文字がきれいに表示される (ジャギーにならない)。
- ユーザーが独自に可読性を調整できる (色の反転表示、文字の拡大、など)。
- スクリーンリーダーに対応しやすい (文字画像だと、同等の代替テキストも記述しなければならず、手間がかかる)。
- 機械翻訳にも対応できるので、外国語話者のユーザーに喜ばれる可能性がある。
なお、テキストを用いる際は、読みやすいフォント選択、文字サイズ、行間の設定をスタイルシートで設定するようにしましょう。
識別しやすいリンクやボタン
リンクやボタンは、押されなければ意味がありませんが、実際にはユーザーに気づいてさえもらえないようなものも少なくありません。どこがクリック/タップできるのかを視覚的に明示したデザインにする必要があります。また、スマートフォンやタブレットのユーザーに配慮し、指でも誤タップしない程度に、十分な大きさを確保しましょう。
リンクやボタンのラベルも、具体的に記述します。たとえば「こちら」とだけ書いてあるリンクは、リンクだけを飛ばし読みするユーザーにとって使いにくいものになるので、リンク先が予測できるような記述をしましょう。
キーボード操作
ユーザーの中には、障害や怪我などの理由でマウスが使えず、キーボード操作に依存している人がいます。そのため、ウェブコンテンツは、キーボード操作だけで利用できるようにしましょう。具体的には、[Tab] キーによるフォーカス移動と [Enter] キーでの実行ができることと、フォーカスが当たっている箇所が可視化されていることが大事です。今流行のパララックス効果を採り入れたランディングページでは、なぜかフォーカスの可視化がまったく配慮されていない (どこにフォーカスが当たっているのかまったく見えない) ものが多く、残念なデザインと言えます。
なお、スクリーンリーダー (画面読み上げソフト) を使っている視覚障害者も、基本的にはキーボード操作でウェブを利用します。最近よくある、ページ遷移を伴わないインタラクション (折り畳み/展開など) を実装している場合は、その状況を音声でユーザーに伝える必要があります。WAI-ARIA という技術で可能なので、採り入れてみてください。
動画および音声コンテンツ
動画および音声コンテンツは、再生や停止をユーザーが自由にコントロールできることが大事です。ページの読み込みと同時に勝手に再生が始まったり、ユーザーの任意で止めることができないのは、以下の点で問題があります。
- 止められない動きは、ユーザーの認知 (見たいコンテンツへの集中) に悪影響を及ぼします。また閃光が含まれる場合、ユーザーの発作を引き起こす恐れがあります。
- 止められない音は、公共の場で困ります。ユーザーはスマートフォンで「いつでもどこでも」ウェブを利用することに配慮しましょう。また、スクリーンリーダー (画面読み上げソフト) を使っている視覚障害者にとっては、止められない音は情報取得の邪魔になってしまいます。
なお、動画コンテンツには、聴覚障害者向けの情報保障としてキャプション (字幕) を付けるようにしましょう。視覚障害者向けの情報保障として副音声による音声解説を付けることができれば、よりアクセシブルになります。音声コンテンツには、聴覚障害者向けの情報保障としてトランスクリプト (書き起こし文) を付けるようにしましょう。
色に依存しない情報識別
ユーザーの中には、色の識別が困難な人がいます。また、グレースケールでウェブページを印刷するユーザーもいるでしょうし、最近では、モノクロの電子書籍リーダーでのウェブ閲覧も考えられます。こうしたユーザーへの配慮として、情報識別の手がかりを色だけに依存することは避けるようにしましょう。
たとえば、グラフや図、文中のリンク箇所などは、色の違いだけが識別の手がかりとしてデザインされていることが多く、注意が必要です。色を効果的に用いつつも、色以外の要素も加えるようにするとよいでしょう。
フォームへの入力支援
ユーザーに情報を入力してもらうフォームでは、スムーズなインタラクションを実現するために、いくつかの配慮が必要です。たとえば、以下が挙げられます。
- 各入力項目に対して、ラベルを常に明示する (プレースホルダーをラベル代わりに用いてしまうと、入力中にラベルが見えなくなってしまうので避ける)。ラベルは <label> 要素でマークアップし、入力欄と紐付ける。
- 入力必須の項目は、ラベルに「必須」と明記する (抽象的な記号ではなく具体的な言葉で)。HTML5 であれば、入力要素に required 属性を記述する。
- 入力不備などのメッセージを、適切なタイミングで、わかりやすく提示する。メッセージは視覚障害者 (スクリーンリーダーの利用者) にも音声で伝わるようにする (WAI-ARIA を用いて)。
今後への期待
以上、アクセシビリティへの取り組みかたを挙げてみましたが、いかがでしたでしょうか。いずれも重要なことですが、もしかしたらどことなく「縛り」のような印象を受けてしまったかもしれません。このような捉えられかたは洋の東西を問わずあって、それを受けて、ここ数年、欧米のアクセシビリティ専門家の間では「インクルーシブデザイン (inclusive design)」という考えかたが語られるようになっています。狭義でのアクセシビリティ (WCAG の達成基準を満たす) だけでなく、ユーザビリティにも優れた、障害者や高齢者を含むあらゆるユーザーの UX に寄与するウェブデザインをしよう、という考えかたです。
この記事の冒頭で、皆さんの中には「ユーザーを第一に考える姿勢」が根底にあることでしょう、と述べましたが、ターゲットユーザーの課題や目的を起点に考えることと併せて、ターゲットユーザーの身体特性や各種利用状況なども考慮したデザインが、普通に行われてゆくことを期待したいところです。
また、ウェブ解析士の皆さんでしたら、障害者のアクセス状況や行動をデータとして取得し、そこから改善施策を検討できないか、という関心がおありかもしれません。ユーザーエージェントの種別として支援技術 (スクリーンリーダーなど) の併用の有無を認識したり、ユーザーの利用場所の種類 (屋外、公共の場所、など) を認識したりすることができれば、アクセシビリティに配慮した改善の PDCA が回しやすくなりそうです。現時点では難しいですが、ユーザーのプライバシーに配慮した形でこうしたデータが解析できるようになれば、ウェブ解析とアクセシビリティの親和性がより一層高まり、サイト運営においても関係者間でユーザーの多様性に対する理解が促進されることが期待できそうです。
それから、サイトへの集客に大きな影響力を持つ Google がアクセシビリティをどう捉えるのかも、期待を込めつつ注視したいところです。もともと、SEO とアクセシビリティとの間では (お互い「クローラー」「スクリーンリーダー」というテクノロジーがウェブコンテンツを解釈しユーザーに伝えるという点で) 関係性が深いのですが、これに加え Google は、UX の向上に寄与するアルゴリズム変更を次々に導入しています (ページの読み込み速度、常時SSL、MFI…)。Google の使命「世界中の情報を体系化し、アクセス可能で有益なものにすること」を考えると、近い将来、アクセシビリティの担保度合いが検索結果に影響することも可能性として考えられます 。そのときになって慌てて考えるよりは、今からでもアクセシビリティを意識して取り組みたいところです。
できるところから少しずつ
最後にひとつ。アクセシビリティの担保は「0 か 100 か」ではありません。やれる範囲で、少しずつ、継続的に取り組むことが重要です。
そもそも、ウェブに情報を公開しているという時点で、既にある程度はアクセシブルとも言えます。見出しレベルや画像 (<img> 要素) の alt など、基本に沿った普通の HTML を記述していれば、それだけでかなりアクセシブルなウェブコンテンツになります。あとは、多種多様な特性を抱えたユーザーがいるということを理解し、その多様性を尊重した設計や実装の改善を、加えてゆくようにしましょう。
ここ数年、UX という言葉が流行っています。ウェブ解析士の皆さんも、ユーザーを第一に考えるマインドの中で、少なからず UX に関心があったり、実践したりしているのではないでしょうか。もう一歩踏み込んで、ユーザーの持つ多様性をも包含した形で UX をよりよくしたいものです。そのために、ぜひアクセシビリティに取り組んでいただければと思います。
