ノルウェー録音・点字図書館(NLB)のウェブサイトがいいぞ

 以前、「いわゆるウェブサイトの「障害者対応」のページについて」というエントリで、レスポンシブ Web デザイン×モバイルファーストのコンセプトで作れば、読み上げソフト利用者にも使いやすいウェブサイトが作れるのではないかと書いたことがありました。個人的な感覚では、JIS X 8341-3:2016の適合レベルAAの基準を満たしつつ、レスポンシブ Web デザイン×モバイルファーストのコンセプトでウェブサイトを構築すれば、読み上げソフトユーザーがウェブサイトに求める要件の8割から9割は満たせるのではないかと感じています(あくまで個人的な感覚です)。そこから先の1、2割は、@kazuhitoさんが書いているように「音声でコンテンツを読み上げさせる、というコンテキストに目一杯寄せた(そういう目的に特化した)」対応になり、アクセシビリティというよりは、読み上げソフト利用者のユーザビリティ考慮した部分最適化になるかもしれません。まずはこの 8割、9割を満たせるだけでも十分に読み上げソフト利用者にとって、使いやすいウェブサイトになるはずなので、全てのウェブサイトは目指すべきというのが、私の考えなのですが、残り1、2割も「デザインの力」で要件を調和すれば、読み上げソフト利用者に特化した部分最適化にならず、全体最適化を図れるのではないかとも考えています。
 そんな考えを持つ私が、ノルウェー録音・点字図書館 (Norwegian Library of Talking Books and Braille : NLB) のウェブサイトが理想に近いかもと感じています。


Norwegian Library of Talking Books and Braille (NLB)

 
 この図書館は、プリントプリントディスアビリティのある人々を対象とした図書館ですので、読み上げソフト利用者の利用を特に意識して作られているようですが、図書館の利用者は、視覚障害者に限定されない幅広いプリントプリントディスアビリティのある人々を対象としているためか、ウェブサイトは読み上げソフト利用者にとってのユーザビリティを損なわず、非読み上げソフト利用者にとっても使いやすくなるよう、うまくバランスがとられていると感じます。
 少し詳しく見てみましたので、まとめてみました。一方で、詳しく見てみると、ここをこうした方が使いやすくなるのにと思えるところもありまして、それについても長々と書いていますが、高評価の中でここの問題がなければもっとよかったのに(さらに自分の理想に近かったのに)という視点で書いたものです。
 なお、ここで書くことは、当然ですが、あくまで私が感じていること以上のものではありません。

1. 全体

 全体的にシンプルな構成で、デザイン的にも(多分に感覚的なところがありますが)優れいていると思います。
 そして、文字色と背景色コントラスト比が高いため、視認性が非常に高いです。コントラスト比を確認して見ると、WACG2.0(JIS X 8341-3:2016 )の達成基準で言えば、一部はAAですが、ほとんどがAAAを満たしていています。特にテキストが主体となる部分は、黒い背景色に白い文字色になっています。白黒反転機能を備えるウェブサイトもありますが、このウェブサイトの場合は、白黒反転をデザインとして成立させています。サイト全体に使用されているMuseo Sansというゴシック体のフォントも視認性の向上に貢献していると思います。

白黒反転をデザインとしたNLBウェブサイトのテキスト主体の箇所の画像
LBウェブサイトのテキスト主体の箇所

 レスポンシブ Web デザインで構築されていますので、スマートフォンでこのウェブサイトを表示すると以下の様な感じで、ヘッダーにあったメニューが1つにまとめられている以外はほとんど変わりませんが、スマートフォンのために作り込まれたようなシンプルなサイトです。モバイルファーストを意識して作ったのか、ユーザー側のニーズを汲み取って作った結果なのかはわかりませんが、モバイルファーストでつくったと言われれば信じてしまいそうです。

スマートフォンで表示したNLBのウェブサイトの4つの画面。左からトップページ上部の検索画面、トップページ下部にあるおすすめ資料コーナー、検索結果一覧画面、NLBの紹介画面。
スマートフォンで表示したNLBのウェブサイト

 テキストを選択すると出てくるReadSpeaker社の読み上げ機能が利用できます。開発のリソースはウェブサイトそのものアクセシビリティの向上にまずは割くべきで、支援技術でできる部分でもありますので、この機能の実装を必須とは感じませんし、実装の優先順位が高いとは思いませんが、あれば利用する人がいるとは思います。「自分は読み上げソフトという支援ソフトが必要なんだ」と明確に自覚するところまで行かなくても、場面場面で読みにくさを感じていて、ここで読み上げてくれたら利用しやすいと感じる人も存在するはず(そういう層が実はかなり厚いのではないかとなんとなく感じている)。

ReadSpeaker社の読み上げ機能で読み上げている画像。ReadSpeakerのUIと読み上げている箇所がハイライトされているところが表示されている
ReadSpeaker社の読み上げ機能

2. トップページ

 ユーザーにとってこのページで最も重要であろう、図書館のデータベースの検索フォームに至るまでには、あまり余計なものが配置されておらず、画面が表示されてから読み上げソフトで左上のところからフォーカスを開始しても、移動してもすぐに到達できるようになっています(画面を表示してからの赤い矢印は読み上げ順序。以下同じ)。検索を主体とするサービスのサイトならば、これは結構できてるところも多いのですが、様々なサービスも提供する図書館全体の公式サイトですかね。

トップページ上部にある検索フォーム。画面左上からヘッダーを移動して検索フォームにいたる読み上げ順序を赤矢印で示している。
トップページの読み上げ順序

 検索フォームに最短で到達することを優先するなら、Googleや国立国会図書館サーチのように検索フォームに最初からフォーカスを当てておくというやり方も考えられます。しかし、この図書館のサービスがアカウントを取って認証を経て使用するサービスであることを考えると、アカウントの取得の仕方やログインリンクがあるヘッダー部分の情報はスキップできないということになるのでしょうか。
 読み上げソフトユーザーは、フォーカスを一カ所ずつあてながら、音声で順番に読み上げてサイトを理解します。視覚的に全体の構成を把握することが難しいので、伝えるべきことは読み上げられる可能性が高い場所に、逆にそうでないものは、そうでない場所に配置する必要があります。NLBのウェブサイトの場合は、画面が最初に表示されフォーカスが左上端からスタートしてからの、検索フォームに至るまではの場所は、ユーザーがフォーカスを当てて読み上げる可能性が高く、ユーザーに伝えるべきことが伝えることができる非常に重要な場所です。しかし、欲張ってこの部分が長くなると、ユーザーにとっては煩わしくなりますので、絞り込む必要があります。他の画面に言えることですが、そのページとって最も重要な要素が画面が表示されてからの読み上げフォーカスの開始点から近ければ近いほど、基本的には読み上げソフト利用者には利用しやすくなります。そこはモバイルファーストの考え方とかなり重なると思います。

2. 検索結果一覧画面

 検索結果一覧は以下のように検索結果を左側、分類や資料の種別などによって検索結果を絞り込むファセットナビゲーションを右に配置しています。検索を実行して次にユーザーが知りたい情報は、その検索結果ですので、もっとも重要な位置である左側にそれを配置しています。個人的には後述するアクセシビリティの問題を差し置いても、検索結果一覧こそ重要な左側に配置するべきと考えているので、このレイアウトは好きです。

検索結果一覧の画像。説明は画像の前の本文でしている。
検索結果一覧

 ただ、残念な点が1つありまして、上のようなレイアウトであれば、検索結果一覧を読み上げてから、ファセットナビゲーションを読み上げるものなのですが、NLBのウェブサイトは以下のようにファセットナビゲーションを読み上げてから、検索結果一覧を読み上げます。

検索結果一覧画面での、ファセットナビゲーションを読み上げてから、検索結果一覧を読み上げるという、読み上げ順序を赤矢印で示している。
検索結果一覧画面での読み上げ順序

 NLBのファセットナビゲーションは、用意された検索条件を操作しながら、ユーザーがキーワードによって検索した結果を絞り込むもので、検索サービスの多くで導入されているナビゲーションです。この機能は、検索結果とファセットナビゲーションの両方を見比べてこそ効果を発揮するUIと思います。読み上げソフト利用者が、これを利用しようとすると、検索結果一覧のエリアとファセットナビゲーションのエリアにフォーカスを行き来しなければなりませんので、使いづらいと思います。ファセットナビゲーションは、それが利用できる人にはとても有用なナビゲーションです。NLBの利用者も読み上げソフト利用者に限定されるものではありませんので、利便性の向上を感じるユーザーがいるのであれば導入するべきだと思いますが、導入する場合も、読み上げソフトにその利用を強いることにならないよう、読み上げ順序は考慮する必要があると思います。この画面の場合、検索したユーザーが最初に確認したいのは、検索結果そのもののはずですので、検索結果一覧を先に読み上げさせたほうがユーザーにとっては利便性が高いのではないかと思います。NLBは詳細検索画面を用意していませんので、ファセットナビゲーションにその役割を担わせようとしているのかもしれませんが、ユーザーの全てが詳細検索をしたいと考えるわけではありませんし、ファセットナビゲーションの通過をユーザーに強いることは避けたほうがよいと思いました。また、ファセットナビゲーションが、検索結果を確認してそれを絞り込むものである以上、検索結果を先に確認する必要があります。そのためにも検索結果一覧エリアは先に読み上げるべきだと思います。
 ただ、NLBのサイトでは、ファセットナビゲーションにある”Filter result”をクリックすることでファセットナビゲーションそのものを非表示にすることができます。非表示にすれば、検索結果一覧にもすぐに移動できます。スキップリンクに近い用途でしょうか。非表示にする一手間が必要なこと、Tabキーを連打して高速で読み上げのフォーカスを移動させている場合に、そこにあると知っていればともかく非表示にできるリンクの存在を知らない場合などにピンポイントに”Filter result”のリンクを押すことができるのかという点が気になりますが。また、この方法だと、検索結果一覧を最後まで確認して、ファセットナビゲーションで検索条件を絞り込みたい場合に、スキップしたそれに戻らなくてはなりませんし。

ファセットナビゲーションを非表示した画面。検索結果一覧にすぐに移動できることを赤矢印で示している。
ファセットナビゲーションを非表示した状態(英語版)。検索結果一覧にすぐに移動できる

 ファセットナビゲーションとして用意されている項目もあまり多くなく(以下の画像は英語版のファセットナビゲーション)、よく利用されるであろう”Media Types”以外は、基本的に大項目だけを表示して下位の項目は非表示にしていますので、検索結果から絞り込みたいと考える読み上げソフト利用者でも利用しやすいかもしれません。読み上げソフト利用者にとっては、詳細検索画面があれば、キーワード検索と条件指定を一度に済ませられることを、キーワード検索と、ファセットナビゲーションによる絞込みと、工程を2つに分けてしまっている感じになるのかもしれません。そう考えると、ファセットナビゲーションで検索できる条件で、条件指定とキーワード検索ができる詳細検索画面は用意したほうがよいのかなと感じました。

英語版ファセットナビゲーションの画像。大項目としてFilter result、Media types、Made for、Language、Library、Publishing yearが表示され、Media typesが展開し、小項目のAudio book、Braille bookが表示されている。
デスクトップで表示した英語版ファセットナビゲーションの画像

 
 スマートフォンで表示すると、初期設定では、次のようにファセットナビゲーションも非表示になって、”Filter result”をクリックするとファセットナビゲーションが展開されるようになっています。ファセットナビゲーションが不要な人は、ファセットナビゲーションが省略される分、検索結果一覧に移動できます。スマートフォン版のほうが使いやすいかもしれません。

スマートフォン版のファセットナビゲーションの画像。最初は非表示状態になっているものを、展開してファセットナビゲーションを表示した図。
スマートフォン版のファセットナビゲーション

 検索結果一覧エリアです。検索結果一覧エリアにも「簡易ファセットナビゲーション」と呼ぶべきリンク(赤枠)が用意されています。

検索結果一覧エリアの上部。所蔵館が「簡易ファセットナビゲーション」として表示されているところが赤枠で囲われている。
検索結果一覧エリアの上部。所蔵館が「簡易ファセットナビゲーション」

 これはなるほどと思わせるUIで、検索結果一覧の中にあるので、読み上げソフトユーザーにも使いやすいのではと感じました。ユーザーが最も使用する項目をここに用意して置くことでファセットナビゲーションに近い機能を読み上げソフトユーザーも利用することができます。上で述べたように、ファセットナビゲーションより検索結果一覧を先に読み上げるようにしていたら、もっと有効だったかもしれません。もしかすると、簡易ファセットナビゲーションは読み上げソフトユーザーに寄せた部分かもしれませんが、うまくデザイン落とし込んでいるので、そこにある不自然さは感じません。数あるファセットナビゲーションの中で所蔵図書館が簡易ファセットナビゲーションになっている点は、ちょっと謎ですが、NLB固有の事情があるかもしれません。ちょっと残念なのが、NVDAで検証すると、リンクのはずなのに、A要素にhref属性がないためか、Tabキーでリンクのようにフォーカスを当てられないという・・。

3. 書誌詳細画面

 検索結果一覧から入れる各コンテンツのメタデータが掲載されている書誌詳細画面です。以下の画面の例は”
The Invisible Library“のものです。

The Invisible Libraryの書誌詳細画面
“The Invisible Library”の書誌詳細画

 資料を入手できる”Borrow audio book”ボタン(赤枠)が資料のタイトルと著者の次に読み上げられる配置になっています。ユーザーの最終目的は資料を入手することですので、資料のタイトルと著者という必要最低限の情報を確認させたら、入手方法に誘導するという流れは、ユーザーが求めるものに最短のルートを提供しているように思います。
 ただ、その前にReadSpeaker社の読み上げ機能を立ち上げる”LISTEN”というボタンがあるのですが、特にオーディオブックの書誌の場合には、非常に紛らわしいのではないかという気もしました(そのままオーディオブックをストリーミング再生するものと誤解されそうな気がします)。

JAWS Support for ARIA

 JAWSを開発しているFreedom Scientific社が、JAWSのWAI-ARIAサポート情報を纏めたドキュメント(”JAWS Support for ARIA”)を以下で公開しています。
JAWS Screen Reader – Documentation
仕様に係る情報をスクリーンリーダー側が公開してくれると、1つ1つサンプル使って検証したりしなくて済むのでありがたい。他のスクリーンリーダー側がこういう形で技術文書の公開をしてくれると、Web開発者側もとても参考になるし、対応を促すこともできると思うのですが。

アクセシビリティの観点からWebブラウザで標準で取り入れて欲しいUI

6年ほど前に以下のエントリで電子書籍のUIでWebブラウザのUIをまねて欲しいところを書いたことがありますが(6年前かぁ・・・)、今回は逆の話で、WebブラウザのUIで電子書籍のUI(機能というべきかもしれない)を取り入れて欲しいという話。

 ウェブサイトに自治体や公的機関のサイトで、文字の拡大縮小や白黒反転機能などを備えているものものあります。これの要否については、OSやブラウザの標準の機能で備えているので、それを阻害しないようなウェブサイト作りをするべきで、まずはそれにリソースを割くべきという考えがおそらく主流なのだと思います。私も基本的にはこれに同意しますが、一方で、OSやウェブブラウザの機能がどこまで使いやすいかということもやや疑問がなくはありません。
 例えば、OSで白黒反転表示することは可能ですが、これはPC上で行う全ての作業が白黒反転されてしまうので、これに切り替えて使うには、かなりの覚悟がいるというか、白黒反転でなければもう使えないという方に限られてしまうのではないかと思ったりする。
 私も子どもが寝かしつけで抱っこしている際は、部屋を真っ暗にして、iPhoneで電子書籍などを読んでいたこともありましたが(片手で指挟んででも読めるし、暗いところでも読めるので重宝した→当時のエントリ)、そういう場合は、普通の画面ではまぶしすぎるので、白黒反転表示で環境によって読んでいましたが、環境によって、表示を切り替えたいというニーズもあるのではないか。
 
 いわゆる「健常者」と、いわゆる「障害者」の間にはとても大きな層があって、例えば、高齢者の方などはだんだんWebブラウザが使いづらくなっていくことに気がつかないまま、使わなくなるか、遠ざかってしまうという人もいるのではないか。
 Webブラウザで文字の拡大縮小はだいたいついていますし、ボタンで変更できるUIを備えたブラウザもある。しかし、それ以外は、ユーザー側で表示を切り替えるのはかなりハードルが高い。ウェブサイトごとに表示を切り替えたい気もするし、環境に応じて切り替えたい。
 電子書籍だと、文字拡大や、フォント変更、行間変更、配色変更などはほぼ標準的についていますが、Webブラウザでもそういう機能とそれを気軽に使えるUIを備えてもらえないかなと思ったりする。拡張機能で追加できるかもしれないけど、標準で備えてもらってこそ多くの人の手の届くと思うので。