Webアクセシビリティ対応で「音声読み上げ・文字拡大・色変更」は的外れ。本当に必要なのはSEO？

アクセシビリティに対応しているとは言い難い支援機能

Webサイト側で用意した「文字サイズ変更」などの支援機能だけでは、アクセシビリティに対応しているとは言い難いことについて前回の記事で触れましたが、どう対応すべきか本題の前におさらいしておきましょう。よく見かけるのは次のような機能です。

• 音声読み上げ
• 文字拡大
• 文字色変更

アクセシビリティに対応しているとは言い難い支援機能

これについて、総務省の「みんなの公共サイト運用ガイドライン（2016年版）PDFのP21」を見ると、次のように記載されています。

これは総務省の文書ですからマイルドな表現になっていますが、はっきり言ってしまえば、サイト側にこれらの機能を設けることは、的外れな対応だということです。

なぜ、的外れの機能なのか？

なぜ、的外れなのでしょうか？ それは、実際にユーザーが使っているシーンを考えればわかります。たとえば、PCを起動してからサイトのコンテンツを読むまでの流れを書き出してみましょう。

1. ブラウザを立ち上げる
2. アドレスバーに文字列を入れて検索する
3. 検索エンジンの検索結果から該当のコンテンツを探す
4. サイトに訪問し、コンテンツを読む

サイト側で用意した支援機能は、4の「サイトに訪問し、コンテンツを読む」の段階になって初めて使えるものです。サイトに「音声読み上げ機能」があれば、そのサイトのコンテンツを読み上げることはできますが、他のサイトのコンテンツを読むことはできません。そしてもちろん、ブラウザを立ち上げたり、検索文字列を入れたりする際にも、この機能を使うことはできません。

もし、このような支援機能にニーズがあるとすれば、普段は目で見てアクセスする人が「何らかの事情でそのサイトのコンテンツだけ読み上げで聴きたい」というようなケースでしょう。サイトの性質によっては、そういうニーズがある場合も考えられますが、それはどちらかと言えば、アクセシビリティというよりもユーザビリティの話になります。

このように、ユーザーの利用シーンを考えてみると、個別のページに支援機能をつけても活用が難しいことがわかるでしょう。実際のユーザーの利用シーンを見ることは、アクセシビリティを考えるうえで非常に重要なことなのです。

注意点：障害の種類や性質は人によってさまざま

ただし、ひとつ注意点があります。障害の種類や性質は、人によって異なるということです。たとえば、「視覚障害」と言っても、まったく見えない人もいれば、光を感じることはできる人、目を近づければ大きなものは何となく読める人、眩しいものが苦手な人など、さまざまです。ある人には問題なく使えるものが、他の人にはまったく使えないこともあります。

特定ユーザーの行動パターンは、他のひとには当てはまらないことがあります。障害のあるユーザーの行動を見るときは、このことを意識しておきましょう。

最初に何をするべきか？ まずは現状把握から

さて、ここからは弁護士ドットコムのアクセシビリティへの取り組みを見ていきましょう。

私がまず行ったのは、何はともあれ現状把握です。今までどんな取り組みをしてきたのか、現在のサイトのアクセシビリティの状況はどうなのか、といったことについて、ヒアリングや調査を行いました。

Webサイトをきちんと作ると、アクセシビリティ向上につながる

今までのアクセシビリティ向上のための取り組みについてですが、意識的に特別な施策を行ってきたかどうかといえば、NOでした。アクセシビリティに関心を持っているエンジニアやデザイナーの方はたくさんいますが、組織的になにか特別な取り組みはしていません。ただし後述しますが、これは「何もしていない」ということとイコールではありません。

そして、特別な取り組みがなかったにもかかわらず、現状のサイトはアクセシビリティをある程度確保できているようでした。問題点は散見されるものの、情報にまったくアクセスできないとか、まったく使えないといった状況ではありません。私が今まで見てきたサイトのなかでも、平均以上のアクセシビリティは確保できているように思えました。

ヒアリングしてみると、実は、ある取り組みがアクセシビリティ向上につながっていることがわかってきました。

• ひとつは、SEO（サーチエンジン最適化）の取り組みをしていたこと。

• もうひとつは、デザイナーやエンジニアのなかに、Webサイトをきちんと作る、品質を高めるという意識があったこと。

SEOの取り組みやWebサイトをきちんと作ることが、なぜアクセシビリティ向上につながるのでしょうか。これは2つの観点から説明できます。

SEOに取り組むと、支援機能でアクセスしやすくなる

現在の検索エンジンのほとんどは、Webページからキーワードなどの情報を収集し、その情報に基づいて検索結果を出しています。この際、情報を収集するのは「ロボット」と呼ばれるプログラムであり、つまり機械です。

機械は人間のように画像を見ることができません。そのため、SEOの観点から、画像の代わりとなるテキスト情報（代替テキスト、alt属性）を指定することが求められます。また、ロボットがアクセスした際、文書の構造が適切に伝わるように、タイトルや見出しなど、HTMLの文書構造を適切にマークアップすることが強く推奨されます。こうした施策により、コンテンツは機械で処理しやすいものになり、検索エンジンも適切にキーワードを抽出できるようになります。

このような、機械からの読みやすさを「マシンリーダビリティ」と呼びます。SEOの取り組みには、マシンリーダビリティを高める施策が多数含まれています。そして、障害のあるユーザーが利用する支援機能もまたプログラムであり、機械なのです。

目の見えない人は、画像を見ることができません。それでも、「スクリーンリーダー」という支援技術を使えば、代替テキストを読み上げて画像の内容をある程度理解することができます。また、コンテンツの全体を目で見ることができなくても、見出しにジャンプする機能で見出しだけを拾い読みすれば、全体を把握したり、読みたいところから読み始めたりすることができます。

検索エンジンのロボットと、スクリーンリーダーなどの支援技術は、人間の目を持たない、プログラムであるという点で共通しています。SEOの目的でマシンリーダビリティを向上すれば、支援技術でアクセスしやすいものになり、結果的にアクセシビリティ向上につながるのです。

逆に、画像に適切な代替テキストが指定されていなかったり、見出しが適切にマークアップされていなかったりすると、サーチエンジンのロボットからも、支援技術からもアクセスしにくいものになってしまいます。

検索エンジンに頼る人のアクセシビリティ

Webで何かを探そうとするユーザーのほとんどは、障害があるないにかかわらず、まず検索エンジンで検索するでしょう。たとえば、企業を訪問しようと思い、サイトで所在地を調べるときはどうするでしょうか。私がよくやるのは、次のような方法です。

• まず「企業名」を検索して、トップページにアクセスする
• サイト内のナビゲーションに「アクセス」「所在地」などの項目がないか探し、あればそれをクリックする
• なければ「企業情報」「会社情報」などを探し、それらのなかに「アクセス」などがないか探す

しかし時には、「アクセス」という項目がなく、企業情報を見ても所在地の情報がどこにあるのかわからない、ということもあります。そのような場合は検索エンジンに戻って、「企業名 アクセス」のように検索しなおします。すると多くの場合、目的の所在地情報にたどり着けます。

サイト内のナビゲーションが使いにくければ、検索エンジンで直接探すほうが早いわけです。これは障害者に限った話ではないのですが、障害があると、ナビゲーションの使いにくさの影響をより強く受けることがあります。SEOを行い、検索エンジンから情報にたどり着けるようにすることで、ナビゲーションを使わずに検索エンジン経由でアクセスする、新たな経路が生まれます。これによって、より多くの人が情報にアクセスできるようになるのです。

「Flash」など、特殊なものはアクセシビリティが担保しにくい

このように、アクセシビリティに対する特別な取り組みをしていなくても、使いやすさを考えながらWebサイトを素直に作ろうとすれば、その取り組みがいつのまにかアクセシビリティの向上につながっていることがあります。

この点については『デザイニングWebアクセシビリティ』の共著者である伊原力也氏と共同で「実はできている!? Webアクセシビリティ」というテーマで講演をしています。次にスライドが公開されていますので、興味のある方は参考にしてみてください。https://www.slideshare.net/rikiha/web-63761798

ただし、Webの元々の使われ方とまったく異なるような、奇をてらった作り方をすると、アクセスできないコンテンツができてしまうことがあります。

たとえば、一時期流行したFlashのコンテンツなどは、かなり配慮した作り込みをしなければ、アクセシビリティが担保できないものでした（Flashについては、アドビが2020年末にサポートを終了すると発表していますので、今後どんどん少なくなっていくと思いますが）。

HTMLで作る場合であっても、本来の使い方とは異なるトリッキーな作り方をすると、ユーザーの環境によってはアクセスできなくなる場合があるので注意が必要です。

ユーザー調査から改善点を見つける

弁護士ドットコムはSEOに取り組んでいましたし、大きく奇をてらったようなページの作り方も少なかったため、アクセシビリティに大きな問題はありませんでした。

となるとアクセシビリティ向上のために弁護士ドットコムにジョインした私の仕事がいきなり終わってしまいそうですが、そんなことはありません。幸か不幸か、問題点がまったくないわけではなく、まだまだたくさんの改善の余地がありました。

では、その改善のために何をするべきでしょうか?

私が実行したのは、実際に障害当事者の方にご来社いただいて、サイトを使っていただくことでした。

この記事の冒頭でお伝えしたように、アクセシビリティを考えるうえで、実際のユーザーの行動を見るということは非常に重要です。そして実際の利用シーンを見れば、必ず改善すべき点がみつかるはずだと考えました。それを実際に改善につなげることができれば、アクセシビリティへの取り組みを根付かせるための大きな一歩になるはずです。

幸いなことに、弁護士ドットコムの開発チームは「スクラム開発」の考え方を取り入れています――つまり、一週間といった短い期間で、どんどん開発をしていくスタイルで仕事を進めています。これは、小さな改善をすぐに実施することができる体制です。改善の方針さえ決まれば、すぐに実際のサイトに反映して、成果を見ることができます。

また、ユーザーテストにはもう一つ狙いがありました。

それは、社内のメンバーが障害当事者の存在を明確にイメージできるようにすることです。

次回の連載では、実際のユーザーテストの様子と得られた教訓、そしてそれを反映するプロセスについてお伝えしたいと思います。