いわゆるウェブサイトの「障害者対応」のページについて

 ウェブサイトのアクセシビリティについて、JIS規格に準拠してウェブアクセシビリティを確保することとは別に、いわゆる「障害者対応」のためにはテキストベースのサイトを用意しなければ十分に対応できない(そして、それが別インターフェイスを用意することを意味するので、なかなかできない)、みたいな話をいろいろなところで聞くことがあります。そういう話を聞く度にもやもやっとするので、この「もやもや」について、少し考えを整理しておきたいと思います。あくまで私の理解なので、正しいかどうかは分かりません。「障害者対応」のページを設けているサービスもありますが、それ自体は素晴らしいことで、当然ながらそのサイトを否定するものではありません。設けられるなら設けたほうがよいし、内容によっては必要なサイトもあるだろうと思います。
 
 私がもやもやっとしているのは、

  1. 「障害者対応」のためにはテキストベースのサイトを用意しなければ十分に対応できない
  2. それが別インターフェイスを用意することを意味する(通常の画面では健常者向け扱い)
  3. 別のインターフェイスを用意することがなかなか難しい

という、1から3の流れになりがちなところです。
 読み上げソフトは基本、ウェブサイトに用意されたテキストしか読みません。テキストのみが使用されているサイトでも、画像がばんばん使用されたビジュアルなサイトでも、読み上げソフト利用者から見れば、どちらも「テキストベースのサイト」になります。ビジュアルなサイトで、アクセシビリティが問題になるのは、画像をふんだんに使用したビジュアルなサイトだからではなく、読み上げソフトからみえる「テキストベースのサイト」が、読み上げソフトユーザーにとって使い勝手が悪い、読み上げソフトでは使えない機能があるからです。ビジュアルなサイトをだから、「障害者対応のテキスト版サイト」を別に用意しなければという話ではないと私は思う。
 障害者対応のページ、或いは、テキスト版のサイトが必要であるという認識が広まることは、逆にそういうサイトを設け無ければ、いわゆる「障害者対応」ができないという認識が広まることになり、普通は同じサイトに複数のインターフェイスを持つことはなかなか困難なので、自分のところは「障害者対応」はできないんだというあきらめがひろまってしまうことを恐れている。
 読み上げソフトユーザーは、音声でサイトを利用します。つまり、フォーカスを一カ所ずつあてながら、音声で順番に読み上げてサイトを理解します。視覚的に全体の構成を把握し、必要な箇所をすぐに特定して、そこを読むということが難しいです。読み上げソフトユーザーの利用を想定する場合、それを考慮したサイトにしなければなりません。そのためには、以下の条件を備える必要があると思います。

  • 意味ある順序で読み上げられるだけでななく、そのページのメインコンテンツにすぐにたどり着けるよう、読み上げられる順序を考慮してDOMを構成する
  • 不必要な情報が少なくする

 「障害者対応」と銘打っているサイトが読み上げソフト利用者にとって使いやすいのは、テキスト版サイトだからというよりも、ターゲットが読み上げソフト利用者に絞られているため、上がしっかり考慮されているのだろうと思います(無論、それだけではないですが)。
 実はモバイル向けのサイトは上で書いた条件に該当することが多く、読み上げソフト利用者にとって利用しやすいものが多いのではないかと感じています。もう少し突き詰めると、JIS X 8341-3:2016にはもちろん準拠しつつ、
レスポンシブウェブデザイン×モバイルファースト
のコンセプトでつくれば、読み上げソフトの利用者にも使いやすいサイトになるのではないかと思うのです。
 JIS規格に準拠してウェブサイトを構築しても、レイアウトが複雑だったり、一ページの情報量が多すぎて読み上げソフト利用者には使いづらいサイトになる可能性もありますが、レスポンシブウェブデザインで製作すれば、少なくともスマホを想定した線形のレイアウトも想定するでしょう。それは縦方向に意味ある順序でコンテンツを表示することを意味しますので、意味ある順序で読み上げられることにもなります。それにモバイルファーストをかみ合わせれば、必要な情報がすぐにたどり着くように、また、無駄な情報がそぎ落とされるようになるのではないでしょうか。
 ウェブ利用時間におけるスマホの占める割合の増加や、Googleの最近の以下の動きもありますので、SEO対策とあわせて考えてみる価値はあると思います。

 無論、レスポンシブウェブデザイン×モバイスファーストだけで、全てが解決するわけではなく、サイトの内容によっては、読み上げソフトの利用者にとって使いやすいUIを用意したほうが望ましいものもあるかもしれません。しかし、ほとんどウェブサイトにとっては、できる余地がまだまだあるのではないでしょうか。

EPUB 3.1の仕様とそれに含まれるEPUBのアクセシビリティに関する仕様

 1月5日にEPUB 3.1の仕様がIDPFで承認されました。

 EPUB 3.1の仕様は、EPUB Packages 3.1、EPUB Content Documents 3.1、EPUB Open Container Format (OCF) 3.1などの複数の仕様で構成されています。2016年に公開されていたEPUB 3.1のドラフト版はありがたいことにIMAGEDRIVEさんが日本語訳を公開してくれています。EPUB3.01からの変更点を解説した”EPUB 3.1 Changes from EPUB 3.0.1″も含めて翻訳してくださっていますので、ご参照ください。

 EPUB 3.1の仕様では、アクセシビリティに関する仕様が規定され、その関連文書としての実装方法をまとめた文書が公開されました。

 よりアクセシブルなEPUBコンテンツを制作する要件についてまとめられているほか、必要な人が自分にあったアクセシブルなコンテンツをきちんとを発見できるようにするため、EPUBコンテンツに包含すべきアクセシビリティメタデータの要件についても整理されています。
EPUB Accessibility 1.0と関連文書であるEPUB Accessibility Techniques 1.0(実装方法集)の関係は、W3CのWeb Content Accessibility Guidelines (WCAG) 2.0/a>とそのTechniques for WCAG 2.0(実装方法集)の関係に倣ったものだと思われます。技術的なテクニックは随時変更できるように仕様本体から切り離したのでしょう。WCAGと実装方法集の関係の詳細については、以下をご参照ください。

全視情協「テキストデイジー・マルチメディアデイジーデータ 再生機器・ソフトウェアに関する調査結果(2015)」

 公開されてずいぶん日がたちますが、視覚障害者情報提供施設(いわゆる点字図書館)の全国組織である全国視覚障害者情報提供施設協会(全視情協)が「テキストデイジー・マルチメディアデイジーデータ再生機器・ソフトウェアに関する調査結果」(平成28年3月31日)を平成28年5月19日に公開しています。DAISY再生ソフトのEPUB対応の予定についても調査されています。
全視情協:各種資料 – テキストデイジー再生機器等に関する調査結果(2015)
目次は以下のとおり。
1.カテゴリー別 機種・ソフトウェア 4ページ
2.機能別調査結果 5ページ
(1)再生可能なデイジーデータ 5ページ
(2)移動可能な単位 5ページ
(3)飛ばし読み(スキッパブル)機能 6ページ
(4)文字の読み上げ、検索機能 6ページ
(5)テキスト表示、ノートテイク(印付け等)機能 6ページ
(6)テキストデイジーデータの再生について 7ページ
(7)インターネット接続とサピエ図書館のデータの再生機能について 8ページ
(8)EPUB3への対応(対応予定) 9ページ
3.機種・ソフトウェア別機能調査結果 10ページ
(1)ブレイルセンスU2 10ページ
(2)ブレイルセンスオンハンドU2ミニ 10ページ
(3)Voice-Trek DS-902 10ページ
(4)Olympus Sonority 11ページ
(5)BMS16 12ページ
(6)BMS40 12ページ
(7)My BookⅢ 13ページ
(8)ボイスオブデイジーVer.4 for iOS 14ページ
(9)ボイスオブデイジーVer.4 for Android 14ページ
(10)Dolphin EasyReader 6.03 日本語版 14ページ
(11)Dolphin EasyReader Express 6.06 113 16ページ
(12)AMIS 3.13 日本語版 17ページ
(13)プレクストークPTN2 18ページ
(14)プレクストークポケットPTP1 19ページ
(15)プレクストークリンクポケットPTP1/LINK 19ページ
(16)いーリーダー 20ページ
資料1 カテゴリー別 機種・ソフトウェア 一覧表 22ページ
資料2 機能別調査結果 一覧表 23ページ