デザイン×モバイルファーストのコンセプトで作れば、読み上げソフト利用者にも使いやすいウェブサイトが作れるのではないかと書いたことがありました。デザイン×モバイルファーストのコンセプトでウェブサイトを構築すれば、読み上げソフトユーザーがウェブサイトに求める要件の8割から9割は満たせるのではないかと感じています(あくまで個人的な感覚です)。そこから先の1、2割は、@kazuhitoさんが書いているように「音声でコンテンツを読み上げさせる、というコンテキストに目一杯寄せた(そういう目的に特化した)」対応になり、アクセシビリティというよりは、読み上げソフト利用者のユーザビリティ考慮した部分最適化になるかもしれません。8割、9割を満たせるだけでも十分に読み上げソフト利用者にとって、使いやすいウェブサイトになるはずなので、全てのウェブサイトは目指すべきというのが、私の考えなのですが、残り1、2割も「デザインの力」で要件を調和すれば、読み上げソフト利用者に特化した部分最適化にならず、全体最適化を図れるのではないかとも考えています。ウェブサイトが理想に近いかもと感じています。(NLB)この図書館は、プリントプリントディスアビリティのある人々を対象とした図書館ですので、読み上げソフト利用者の利用を特に意識して作られているようですが、図書館の利用者は、視覚障害者に限定されない幅広いプリントプリントディスアビリティのある人々を対象としているためか、ウェブサイトは読み上げソフト利用者にとってのユーザビリティを損なわず、非読み上げソフト利用者にとっても使いやすくなるよう、うまくバランスがとられていると感じます。詳しく見てみましたので、まとめてみました。一方で、詳しく見てみると、ここをこうした方が使いやすくなるのにと思えるところもありまして、それについても長々と書いていますが、高評価の中でここの問題がなければもっとよかったのに(さらに自分の理想に近かったのに)という視点で書いたものです。ここで書くことは、当然ですが、あくまで私が感じていること以上のものではありません。全体的にシンプルな構成で、デザイン的にも(多分に感覚的なところがありますが)優れいていると思います。文字色と背景色コントラスト比が高いため、視認性が非常に高いです。)の達成基準で言えば、一部はAAですが、ほとんどがAAAを満たしていています。テキストが主体となる部分は、黒い背景色に白い文字色になっています。白黒反転機能を備えるウェブサイトもありますが、このウェブサイトの場合は、白黒反転をデザインとして成立させています。Sansというゴシック体のフォントも視認性の向上に貢献していると思います。デザインで構築されていますので、スマートフォンでこのウェブサイトを表示すると以下の様な感じで、ヘッダーにあったメニューが1つにまとめられている以外はほとんど変わりませんが、スマートフォンのために作り込まれたようなシンプルなサイトです。モバイルファーストを意識して作ったのか、ユーザー側のニーズを汲み取って作った結果なのかはわかりませんが、モバイルファーストでつくったと言われれば信じてしまいそうです。スマートフォンで表示したNLBのウェブサイトテキストを選択すると出てくるReadSpeaker社の読み上げ機能が利用できます。開発のリソースはウェブサイトそのものアクセシビリティの向上にまずは割くべきで、支援技術でできる部分でもありますので、この機能の実装を必須とは感じませんし、実装の優先順位が高いとは思いませんが、あれば利用する人がいるとは思います。「自分は読み上げソフトという支援ソフトが必要なんだ」と明確に自覚するところまで行かなくても、場面場面で読みにくさを感じていて、ここで読み上げてくれたら利用しやすいと感じる人も存在するはず(そういう層が実はかなり厚いのではないかとなんとなく感じている)。トップページユーザーにとってこのページで最も重要であろう、図書館のデータベースの検索フォームに至るまでには、あまり余計なものが配置されておらず、画面が表示されてから読み上げソフトで左上のところからフォーカスを開始しても、移動してもすぐに到達できるようになっています(画面を表示してからの赤い矢印は読み上げ順序。検索を主体とするサービスのサイトならば、これは結構できてるところも多いのですが、様々なサービスも提供する図書館全体の公式サイトですかね。検索フォームに最短で到達することを優先するなら、Googleや国立国会図書館サーチのように検索フォームに最初からフォーカスを当てておくというやり方も考えられます。この図書館のサービスがアカウントを取って認証を経て使用するサービスであることを考えると、アカウントの取得の仕方やログインリンクがあるヘッダー部分の情報はスキップできないということになるのでしょうか。読み上げソフトユーザーは、フォーカスを一カ所ずつあてながら、音声で順番に読み上げてサイトを理解します。視覚的に全体の構成を把握することが難しいので、伝えるべきことは読み上げられる可能性が高い場所に、逆にそうでないものは、そうでない場所に配置する必要があります。NLBのウェブサイトの場合は、画面が最初に表示されフォーカスが左上端からスタートしてからの、検索フォームに至るまではの場所は、ユーザーがフォーカスを当てて読み上げる可能性が高く、ユーザーに伝えるべきことが伝えることができる非常に重要な場所です。欲張ってこの部分が長くなると、ユーザーにとっては煩わしくなりますので、絞り込む必要があります。他の画面に言えることですが、そのページとって最も重要な要素が画面が表示されてからの読み上げフォーカスの開始点から近ければ近いほど、基本的には読み上げソフト利用者には利用しやすくなります。そこはモバイルファーストの考え方とかなり重なると思います。以下のように検索結果を左側、分類や資料の種別などによって検索結果を絞り込むファセットナビゲーションを右に配置しています。検索を実行して次にユーザーが知りたい情報は、その検索結果ですので、もっとも重要な位置である左側にそれを配置しています。個人的には後述するアクセシビリティの問題を差し置いても、検索結果一覧こそ重要な左側に配置するべきと考えているので、このレイアウトは好きです。読み上げ順序NLBのファセットナビゲーションは、用意された検索条件を操作しながら、ユーザーがキーワードによって検索した結果を絞り込むもので、検索サービスの多くで導入されているナビゲーションです。この機能は、検索結果とファセットナビゲーションの両方を見比べてこそ効果を発揮するUIと思います。読み上げソフト利用者が、これを利用しようとすると、検索結果一覧のエリアとファセットナビゲーションのエリアにフォーカスを行き来しなければなりませんので、使いづらいと思います。ファセットナビゲーションは、それが利用できる人にはとても有用なナビゲーションです。NLBの利用者も読み上げソフト利用者に限定されるものではありませんので、利便性の向上を感じるユーザーがいるのであれば導入するべきだと思いますが、導入する場合も、読み上げソフトにその利用を強いることにならないよう、読み上げ順序は考慮する必要があると思います。この画面の場合、検索したユーザーが最初に確認したいのは、検索結果そのもののはずですので、検索結果一覧を先に読み上げさせたほうがユーザーにとっては利便性が高いのではないかと思います。NLBは詳細検索画面を用意していませんので、ファセットナビゲーションにその役割を担わせようとしているのかもしれませんが、ユーザーの全てが詳細検索をしたいと考えるわけではありませんし、ファセットナビゲーションの通過をユーザーに強いることは避けたほうがよいと思いました。ファセットナビゲーションが、検索結果を確認してそれを絞り込むものである以上、検索結果を先に確認する必要があります。そのためにも検索結果一覧エリアは先に読み上げるべきだと思います。result”をクリックすることでファセットナビゲーションそのものを非表示にすることができます。非表示にすれば、検索結果一覧にもすぐに移動できます。スキップリンクに近い用途でしょうか。result”のリンクを押すことができるのかという点が気になりますが。この方法だと、検索結果一覧を最後まで確認して、ファセットナビゲーションで検索条件を絞り込みたい場合に、スキップしたそれに戻らなくてはなりませんし。ファセットナビゲーションを非表示した状態(英語版)。Types”以外は、基本的に大項目だけを表示して下位の項目は非表示にしていますので、検索結果から絞り込みたいと考える読み上げソフト利用者でも利用しやすいかもしれません。読み上げソフト利用者にとっては、詳細検索画面があれば、キーワード検索と条件指定を一度に済ませられることを、キーワード検索と、ファセットナビゲーションによる絞込みと、工程を2つに分けてしまっている感じになるのかもしれません。考えると、ファセットナビゲーションで検索できる条件で、条件指定とキーワード検索ができる詳細検索画面は用意したほうがよいのかなと感じました。result”をクリックするとファセットナビゲーションが展開されるようになっています。ファセットナビゲーションが不要な人は、ファセットナビゲーションが省略される分、検索結果一覧に移動できます。スマートフォン版のほうが使いやすいかもしれません。スマートフォン版のファセットナビゲーション検索結果一覧エリアです。検索結果一覧エリアにも「簡易ファセットナビゲーション」と呼ぶべきリンク(赤枠)が用意されています。検索結果一覧エリアの上部。所蔵館が「簡易ファセットナビゲーション」これはなるほどと思わせるUIで、検索結果一覧の中にあるので、読み上げソフトユーザーにも使いやすいのではと感じました。ユーザーが最も使用する項目をここに用意して置くことでファセットナビゲーションに近い機能を読み上げソフトユーザーも利用することができます。上で述べたように、ファセットナビゲーションより検索結果一覧を先に読み上げるようにしていたら、もっと有効だったかもしれません。すると、簡易ファセットナビゲーションは読み上げソフトユーザーに寄せた部分かもしれませんが、うまくデザイン落とし込んでいるので、そこにある不自然さは感じません。数あるファセットナビゲーションの中で所蔵図書館が簡易ファセットナビゲーションになっている点は、ちょっと謎ですが、NLB固有の事情があるかもしれません。残念なのが、NVDAで検証すると、リンクのはずなのに、A要素にhref属性がないためか、Tabキーでリンクのようにフォーカスを当てられないという・・。入れる各コンテンツのメタデータが掲載されている書誌詳細画面です。Library“のものです。book”ボタン(赤枠)が資料のタイトルと著者の次に読み上げられる配置になっています。ユーザーの最終目的は資料を入手することですので、資料のタイトルと著者という必要最低限の情報を確認させたら、入手方法に誘導するという流れは、ユーザーが求めるものに最短のルートを提供しているように思います。その前にReadSpeaker社の読み上げ機能を立ち上げる”LISTEN”というボタンがあるのですが、特にオーディオブックの書誌の場合には、非常に紛らわしいのではないかという気もしました(そのままオーディオブックをストリーミング再生するものと誤解されそうな気がします)。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。