EPUBの非テキストコンテンツに長文の代替テキストをつける

 プリントディスアビリティのある人の利用を想定して、学術書のEPUBを制作するにあたり、原本にある図や表、写真などでEPUBでは、画像として挿入するコンテンツ(以下、「非テキストコンテンツ」)について、それと同じ目的を果たし、同じ情報を提供するためのテキスト(以下「代替テキスト」)をどのように提供するかという点でしばらく悩んでいました(今も悩んでいる)。代替テキストは、制作の対象が学術書であること(資料的要素の高い非テキストコンテンツが多い)、また、それに付随して、利用される想定が、アカデミックな用途であること、音訳での非テキストコンテンツの説明のノウハウ(仕様)をそのまま活用したことから、代替テキストも長文のものが多くなります。DIAGRAM Centerが公開している以下のガイドラインで作成される代替テキストをイメージすると、それに近いものだと思います(これに準拠したわけではないのですが、情報の粒度や内容は結果として似てくる気がします。要件を整理すると考えることは似てくるのでしょうか)。

 代替テキスト簡潔に短く済むのであれば、alt属性に記述すればよいのですが、長文になると、alt属性に記述するのが躊躇われます。そこで、alt属性以外の方法で、長文の代替テキストをどのように提供するべきか、以下の1から3-4を検証しましたが、結論から述べると、現在のEPUBの閲覧環境の実装を考慮すると、3-4のハイパーリンクが最も妥当という結論になりました。

1 長文の代替テキストを画像の後に配置する

 一番単純なのは、以下のパターン1のように画像の直後にその長文の代替テキストを置くことです。例えば、以下のような感じ。

<figure>
<figcation>表1-1 平成元年から平成20年までのブログエントリ数 </figcation>
<p>※著者が「○○白書」から構成を変更して作成</p>
<img src="../table1_1.jpg" alt="表1-1の画像。内容説明はこの後にあり。">
</figure>
<p>表1-1の内容説明、開始。</p>
(長文の代替テキスト本文)
<p>内容説明、終わり</p>

 しかし、上のように本文の間に長文の代替テキストそのまま置いてしまうと、本文を読み上げている時に長文の代替テキストも上から順に読み上げてしまいます。全ての読者に長文の代替テキストを読み上げさせることになり、本文のみを読みたい読者にとっては、必要がない箇所を読ませてしまうことになってします。

2 スキップリンクをつける

 1にスキップリンクをつけて、長い内容説明をスキップできるようにする方法もあります。DAISY2.02で作成される音声DAISYでも、図表などの内容説明をスキップできるよう、これと同様の対応がよくされています。

<figure>
<figcation>表1-1 平成元年から平成20年までの某</figcation>
<p>※著者が「○○白書」から構成を変更して作成</p>
<img src="../table1_1.jpg" alt="表1-1の画像。内容説明はこの後にある。">
</figure>
<a href="#desc_end01">内容説明スキップ<a>
<p>表1-1の内容説明、開始。
(長文の代替テキスト本文)
<p id="desc_end01">内容説明、終わり</p>

 これはEPUBのどの閲覧環境の実装でも可能なはずですので、現在でも採用できる対応だと思います。ただ、長文の代替テキストを持つ非テキストコンテンツが1点、2点であればともかく、多くある場合は、本文だけが読みたい人は、その都度、スキップリンクを使用することが必要になりますので、煩わしいかもしれません。長文の代替テキストを必要とする人だけが、その都度、操作してそれを長文の代替テキストを読めるようにしたほうがよいかもしれません。
 

3 別の場所に長い説明テキストを配置する

 長文の代替テキストが複数ある場合は、章末なり、巻末にまとめておいて、本文から必要なユーザーが参照できるようにするという方法考えられます。これについては、方法が以下のようにいくつか提案されています。まとめると、longdesc属性を使用する方法、WAI-ARIAを使用する方法、単純にハイパーリンクを配置する方法の3つでしょうか。

3-1 longdesc属性を使用する

 HTMLのlongdesc属性を使用する方法です。longdesc属性の用途としては、別のところに配置した長文の代替テキストへのURLを格納する属性で、まさに今回の目的にぴったりの属性です。以下は、長文の代替テキストを本文と分けてhtmlファイルを作成した例ですが、別に同一html内に長文の代替的スを配置し、longdesc属性で関連付けても仕様上は全く問題ないはず。

<!--本文-->
<figure>
<figcation>表1-1 平成元年から平成20年までの某</figcation>
<p>※著者が「○○白書」から構成を変更して作成</p>
<img src="../table1_1.jpg" alt="表1-1の画像。内容説明はこの後にある。" longdesc=”longdescription01.html#desc1_1" >
</figure>

<!--longdescription01.htmlファイル。各非テキストコンテンツの内容説明が章ごとに集約されている例-->
<section>
<h1>第1章の図表の内容説明</h1>
<section>
<h2 id="desc1_1">表1-1 平成元年から平成20年までの某 の内容説明</h2>
(表1-1の長文の代替テキスト本文)
</section>
<section>
<h2 id="desc1_2">表1-2 昭和25年から昭和41年までの甲乙丙 の内容説明</h2>
(表1-2の長文の代替テキスト本文)
</section>
<section>
<h2 id="desc1_2">表1-3 平成と昭和における玩具の対象年齢の推移 の内容説明</h2>
(表1-3の長文の代替テキスト本文)
</section>
…
</section>

 longdesc属性は、ほとんど使用されていないためか、一度HTMLの仕様から消えて、また、HTML5の拡張仕様として2015年に復活したようです。

 
 そういう状況なので、現時点において、EPUBの閲覧環境で実際に使用できるものかどうかです。EPUB閲覧環境よりは実装が進んでいるはずの、ウェブブラウザとスクリーンリーダーの組み合わせ(PC-Talker+IE11、NVDA+FF)で検証してみました。

 PC-Talker+IE11だと、「説明付き」、NVDA+FFだと、「詳細説明あり」と読み上げてくれます。しかし、エンターを押すと、NVDA+FFだとlongdesc属性で指定された箇所に遷移するのですが、PC-Talker+IE11だと、うまく遷移してくれませんでした。もう少し検証が必要かもしれませんが、ウェブブラウザとスクリーンリーダーの組み合わせでもこの状況なので、おそらくそれより実装が遅れているEPUBの閲覧環境では、まだ利用できる段階ではないと思われました。

3-2 WAI-ARIAのaria-describedbyを使用する

 WAI-ARIAのaria-describedbyを使用する方法です。longdesc属性の対応が進んでいないためか、IDPFの掲示板でもaria-describedbyを使用することが勧められていたりしています。aria-describedbyを使用する場合は、同一のhtmlファイル内に長文の代替テキストを配置する必要があるようです。


<figure><!--本文-->
<figcation>表1-1 平成元年から平成20年までの某</figcation>
<p>※著者が「○○白書」から構成を変更して作成</p>
<img src="../table1_1.jpg" alt="表1-1の画像。内容説明はこの後にある。" aria-describedby=”#desc1_1" >
</figure>
……
<!--同一htmlファイル内の末尾-->
<section>
<h1>第1章の図表の内容説明</h1>
<section>
<h2 id="desc1_1">表1-1 平成元年から平成20年までの某 の内容説明</h2>
(表1-1の長文の代替テキスト本文)
</section>
<section>
<h2 id="desc1_2">表1-2 昭和25年から昭和41年までの甲乙丙 の内容説明</h2>
(表1-2の長文の代替テキスト本文)
</section>
<section>
<h2 id="desc1_2">表1-3 平成と昭和における玩具の対象年齢の推移 の内容説明</h2>
(表1-3の長文の代替テキスト本文)
</section>
…
</section>

 aria-describedby は、フォームにフォーカスを当てた時のようにimg要素にフォーカスを当てたら、長文の代替テキストが有無言わさず読み上げられる懸念もあったのですが、以下のサンプルで検証してみました。

 結果は以下のとおり。ウェブブラウザとの組み合わせも以下なので、EPUBにaria-describedbyを使用するのは現段階ではちょっと時期尚早かなという感じ。

PC-Talker+IE11 NVDA+FF
Image with aria-describedby Attribute (Same Page Description) 画像にフォーカスをあてるとその箇所を読み上げる。 画像にフォーカスをあててもaria-describedbyで紐づけた箇所は読み上げず
Image with aria-describedby Attribute (Link to External Page Description) リンクテキストを読み上げる。エンターを押すと、リンク先に移動するが、aria-describedbyで紐づけたリンクテキストのリンク先と異なる。 「詳細説明あり」と読む。エンターを押すとaria-describedbyで紐づけたリンクテキストのリンク先に遷移

 なお、Accessibility Test Suiteにもaria-describedbyのサンプルが公開されており、少し古いものの、以下で検証結果が公開されていますが、img要素に用いるにはまだまだという印象があります。

 

3-3 WAI-ARIA の aria-details を使用する(未検証)

 まだ時期尚早と思い、検証まではしていませんが、将来的はaria-detailsを使用する方法も有り得そうです(longdesc属性とどちらの未来がくるのか・・)。aria-describedby よりは aria-details のほうが属性の目的にかなっているかもしれません。

aria-details属性は、aria-describedbyによって通常提供されるよりも詳細な情報を提供する単一の要素を参照する。
Accessible Rich Internet Applications (WAI-ARIA) 1.1 日本語訳 – aria-details (プロパティ)

3-4 ハイパーリンクを使用する

longdesc属性やaria-describedby が使用できないとなると、単純に長文の代替テキストのハイパーリンクを配置するという方法が考えられます。これについては、以下の例2と例3でサンプルが掲載されています。

例えば、以下の様な感じでしょうか。長文の代替テキストから本文に戻れるように相互リンクにしています。 なお、以下は、同一htmlファイル内に長文の代替テキストを配置していますが、別のhtmlファイル内に配置しても特に問題ありません。

<!--本文-->
<figure>
<figcation>表1-1 平成元年から平成20年までの某</figcation>
<p>※著者が「○○白書」から構成を変更して作成</p>
<img src="../table1_1.jpg" alt="表1-1の画像。内容説明はこの後にある。" aria-describedby=”#desc1_1" >
<p><a id="ref1_1″ href="#desc1_1">画像の詳細な内容説明へのリンク</a></p>
</figure>
…
<section>
<h1>第1章の図表の内容説明</h1>
<section>
<h2 id="desc1_1">表1-1 平成元年から平成20年までの某 の内容説明</h2>
(表1-1の長文の代替テキスト本文)
<p><a href="#ref1_1">本文へ戻る</a></p>
</section>
<section>
<h2 id="desc1_2">表1-2 昭和25年から昭和41年までの甲乙丙 の内容説明</h2>
(表1-2の長文の代替テキスト本文)
<p><a href="#ref1_2">本文へ戻る</a></p>
</section>
<section>
<h2 id="desc1_2">表1-3 平成と昭和における玩具の対象年齢の推移 の内容説明</h2>
(表1-3の長文の代替テキスト本文)
<p><a href="#ref1_3">本文へ戻る</a></p>
</section>
…
</section>


 ハイパーリンクは、おそらくどのEPUB閲覧環境でも実装されていますので、別の場所に長文の代替テキストを配置する場合はこの方法が現時点においては、もっとも取れうる方法だと思います。そして、長文の代替テキストが多々使用されるEPUBの場合も、この方法が妥当という結論に個人的にはなりました。
 
 上では、epub:typeのnoteref、endnotes、endnoteを使用していますが、現時点ではあってもなくても問題無いかと思います。ただ、これらをつけるとEPUBの閲覧環境では、リンクではなく、ポップアップとして長文の代替テキストが表示される可能性があります。その場合のスクリーンリーダーでの読み上げはどうなのか、長文だとポップアップにはどのように表示されてしまうのかというあたりは、要検証でしょうか。
※2017年12月21日追記
 epub:typeのnoterefを使用すると、iBooks、KoboのiOS版、Microsoft Edgeでテキストがポップアップして表示されること、iBooksはポップアップ先のファイルのサイズを100kb程度に留めないとビューアがハングアップする可能性があることをご指摘いただきました。長文の代替テキストでは、100kbを超える可能性が高いこと、そもそもポップアップで長文の代替テキストを表示させることで利便性が高まるかどうか疑問があることから、上のサンプルコードからepub:typeのnoteref、endnotes、endnoteを記述している部分を削除しました。

余談 EPUB 3 CG での議論

 W3C EPUB 3 Community Groupの2017年11月30日の電話会議でも長文の代替テキストの提供について議論されていました。この11月30日会議の議事録から該当部分を転載します。

Best practices for extended descriptions
Avneesh:: no way to provide extended descriptions currently. Data attributes/ Described_by has limitations for images. Publishers want longer descriptions. Screen readers have difficulty if text is long.
Avneesh: http://kb.daisy.org/publishing/docs/html/images.html#ex-02
Avneesh: https://benetech.app.box.com/s/5zt5jbz4fydu8hlqulb649l2vdo736mq
Avneesh:: need a simple alternative that will work in most reading systems. Matt made recommendation based on simple linking mechanism. Link above ... described_by is not going away. this is one of several options. diagramcentral.org BISG already aware and discussing QuickStart guide. ... One concern - information is outdated in IDPF guidance. Knowledgebase is providing outdated info to publishers.
Luc Audrain: +1
Tzviya:: why is ARIA necessary? HTML recommendations seem sufficient.
Tzviya: see https://github.com/w3c/html/issues/561
Clapierre:: publishers dont want URL link as text (ugly) testing with an image that links but clickable images are problem in some readers
Rachel:: need for extended descriptions in science, psychology, etc. Cant disrupt visual user experience and degrade pedagogical experience.
Wolfgang: s/cant/can't/
Avneesh:: latest version of Edge supports but IE will not collapse it.
Minutes 30 November 2017 · w3c/publ-cg Wiki

ノルウェー録音・点字図書館(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”というボタンがあるのですが、特にオーディオブックの書誌の場合には、非常に紛らわしいのではないかという気もしました(そのままオーディオブックをストリーミング再生するものと誤解されそうな気がします)。