読み上げソフトユーザーへの情報保障のためのプレーンテキストデータの書き方について

 何かを例えば、wordやPowerPointのファイル、PDF形式のファイルなどで送ったり、提供したり、公開したりする場合で、さらに提供する人に視覚障害者などの読み上げソフトを利用する方が含まれている場合には、同じ内容のプレーンテキストファイルも作成して提供することがあります。その際に気をつけていることを何点か思いつくところを参考までにまとめてみました。
 
 あくまで私のやり方でして、これが正解というものではないとは思いますし、いつも全てをやっているわけでもありません。対象となる人が限定されるなら、その人のICTスキルに応じての話になりますし、幅広い層の不特定多数の人を対象にホームページ上で公開するとなった場合は、それなりに労力をさくという感じでケースバイケースです。この中からできるところからやれるとよいのかもしれません。
 プレーンテキストデータの書き方については、毎回迷いながらやっていますので、ご意見いただけると嬉しいです。

1.読み上げソフトで誤読を誘発しない言葉を選択する。

 読み上げソフトで誤読を誘発しない言葉を選択します。言うは簡単ですが・・。
例えば、日付や時刻で

2016/2/7(日)13:30〜16:00

と書きがちですが、以下のように

2016年2月7日(日曜日)13時30分から16時まで

とか。
見栄えや幅を揃えるために、以下のように日時の日と時の間にスペースをいれてしまいがちですが、

日 時
連絡先

「日 時」を「にちじ」とは読んでくれないので、

日時
連絡先

など。
 読み上げソフトがインストールされているのであれば、一度実際に聞いて確認するのがベストかと思います(私もそれほどやれているわけではありませんが・・・)。
 例えば、「視覚障害のある方」の「ある方」という言葉、「のあるかた」と読んで欲しいのですが、「あるほう」と読んだりして、意外な単語を誤読しています。後で知ると結構焦ります。「市町村立」を「しちょうそんりつ」と読まずに、「いちまちそんりつ」と読んだりなどしてたりしますので。
※2016年2月10日追記
 ここについては、以下のようなご意見をいただきました。
・漢字の誤読について、そこまで配慮されていると助かる面もあるが、「ある方」が「あるほう」などよくある誤読は、もう慣れっこになっており、間違って読まれても脳内補完できるという人は多いのでは。
・日付の書き方については、文書内で一貫していれば、yyyy/mm/ddで問題ない
・人名や地名が振り仮名で表記されていれば助かる。

2.読みを補記する

 誤読をすることが分かっている場合でも、固有名詞など、その言葉を使用せざるを得ない場合があります。しかも、誤読されると文章の意図もきちんと伝わらない場合です。分かる範囲になりますが、読みの情報を一応補記するようにしています(できる範囲で)。
 例えば、ブラウザのFirefoxのような、英語の造語でしょうか。Firefoxを「フィレフォックス」と読む読み上げソフトもありますので、この場合は、「Firefox(ファイアフックス)」と単語の後ろに括弧でくくって読み情報を補記するなどしています。日本語の漢字であれば、誤読があっても一字読みで漢字を確認することで一応救われることもありますが、英語はそれもできませんので(アルファベット一文字一文字を読み上げることも可能かもしれませんがとはいえ・・)、英語の造語については特に気をつけています。
※2016年2月10日追記
 これに関連して、「Word」や「PC-Talker」は「ワード」「ピーシートーカー」とカタカナ表記にしているという意見もありました。年配の人だと、英語読みではとまどうこともあるとのことです。そういえば、場合によっては私も「DAISY図書」を「デイジー図書」、「PC-Talker」を「PCトーカー」などのようにカタカナ表記することがあります。
 カタカナ表記については、他の人から正式な表記を知りたいという欲求もあるので、最初に登場するときは、正式な表記とカタカナヨミを併記するのがよいのではないかと意見もいただきました。
  

3.URLやメールアドレスはそれだけを一行で表記する

 例えば、URLなどは以下のように見出しとURLなどを一行でまとめて書きがちです。
URL: https://code.kzakza.com/
これで取り返しの付かない問題になるというわけでもないのですが、上の書き方だと、エディタによっては、「URL:」からリンクを貼っていることもありえますし、読み上げソフトを使用しながら、「https://code.kzakza.com/」だけコピーすることも面倒な気がします。上の書き方をしていて実際、リンク先に飛べなかったという話も何度かいただいたことがありますので、
URL
https://code.kzakza.com/
のほうがよいような気がします。メールアドレスも同じ。

4. 文字コードはShift-JISにする

 これは特に根拠ありません。UTF-8で作成すると文字化けをするという話を何度かいただいたことがあるのでというだけの経験則による話です。これは、そんなことはないよと言われる人は多いかもしれません。
※2016年2月10日追記
これについては以下のようなご意見をいただきました。
・Shift JisのプレーンテキストデータをiOS上で開くと、文字化けを起こしやすい(確かにある!Mac OS上でも同じかもしれない)、海外製のアプリで開く場合ある、ということから、UTF-8のほうがよいというご意見をいただきました。
・UTF-8で概ね問題ないような印象ですが、BoMがないと化けることある

5.ドキュメントが大部になる場合は、章単位などの意味ある単位でファイルを分割する

 プレーンテキストデータは、構造化はされていませんので、HTMLドキュメントのように見出しでスキップしたり、ページ内リンクを活用した目次を冒頭に置くなどで意味ある単位で移動するということもできません。報告書のように紙の資料で数十ページにのぼるような長文になる場合は、最初からずっと目的の箇所まで読み上げるか全文検索で移動するしかありません。そのため、ナビゲーションの意味で、章単位などの意味ある単位でファイルを分割することで、ファイル単位で目次に相当する移動をできるようにします。ファイル数が多くなる場合は、それらをフォルダにいれて、zipで固めてお渡しすることもあります。

6. 図の説明を加える

 PDF版やword版などに図が入っている場合は、その図の説明をつけています。HTMLでの代替テキストと同じです。

7.表を線形のテキストに置き換える

 縦の項目と横の項目を組み合わせて理解する必要のある二次元的なコンテンツである表については、これというものが実はありません。複雑な表や大きな表だとどうしようかといつも迷います。しかし、以下のようにシンプルで小さな表であれば、線形、つまり、最初から順番に読んでいって理解しやすい形式に置き換えることがあります。
(例)

国の行政機関等 地方公共団体 民間事業者
障害を理由とする不当な差別的取扱いの禁止 義務 義務 義務
環境の整備(事前的改善措置) 努力義務 努力義務 努力義務
合理的配慮の提供 義務 義務 努力義務

 
これを以下のようなテキストに置き換えます。つまり、縦と横の見出しを1行でそれぞれ読むという感じでしょうか。

障害を理由とする不当な差別的取扱いの禁止、国の行政機関等は義務、地方公共団体は義務、民間事業者は義務
環境の整備(事前的改善措置)、国の行政機関等は努力義務、地方公共団体は努力義務、民間事業者は努力義務
合理的配慮の提供、国の行政機関等は義務、地方公共団体は義務、民間事業者は努力義務

これはいつもやれているわけではありません。表の数と大きさ次第でしょうか・・。

8. ある程度全体像が予測しやすいように配慮する

 読み上げソフトユーザー、というより、この場合は、特に視覚障害者に当てはまるかも知れませんが、全体の長さや構成などの全体像をぱっと視覚的に把握することが難しいため、線形でコンテンツを読んである程度全体像が予測できるように説明を追加しています。短ければよいのですが、長いといつ終わるか分からない文章を読まされるのは誰でもしんどいと思いますので。
 例えば、アンケートであれば、全体で質問はいくつある(例1)、ということや、個々の質問の中でも選択式のものであれば、質問文の最後に選択肢は4つある(例2)ということを伝えることなどでしょうか。
例1 質問は全部で20問です。次の5つのセクションに分かれています。
例2 次の選択肢からお選びください。選択肢は4個で、複数の回答が可能です。

マルチメディアDAISYを普及させるための方法としていくつか

 音声とテキストを保持し、音声が読み上げる箇所のテキストをハイライトするマルチメディアDAISYが視覚障害やディスレクシアなどの様々な理由で読書に困難のある人にたいして幅広く有効であることは形式であることは疑いないところですが、テキストと音声それぞれをつくり、さらにそれを掛け合わせる必要があり、製作コストがそれなりにかかるため、普及しているとは言えない状況です。しかし、少しでも(可能であれば、商業ベースで)普及させるために、図書館としてこういう手立ては取り得るんじゃないかと思うところを思いつきで何点か。書いていて、マルチメディアDAISYに限定されるものではないかなと思いましたが。
 

1 アクセシブルな電子書籍の要件をまとめたガイドラインを作成する

  • 最終的にはマルチメデァアDAISYにたどり着くようなアクセシブルな電子書籍製作のためのガイドラインを作成する。
  • そもそも「アクセシブルな電子書籍」に対する関係者の認識に相違がかなりある。その相違を解消し、「アクセシブルな電子書籍」の要件を様々な領域がわかるようにするために要件をまとめたガイドライン。いろいろな業界の関係者を巻き込んで作成すれば、このガイドラインを作成するプロセスそのものがアクセシブルな電子書籍と何かというコンセサンスを形成するはず。
  • ガイドラインは、全ての要件を平たく挙げるのではなく、要件の優先順位を示す。たとえば、等級Aの要件を満たせば、スクリーンリーダーで読み上げさせれば誤読がありうるが、それでも読み上げさせることができるもの、等級AAAであれば、肉声の音声と同期したマルチメディアDAISYか、誤読がないようにSSMLを埋め込んだ電子書籍などになるなど。
  • アクセシブルなテキストDAISYライクな電子書籍も十分に出ていない状態で、出版社にいきなりマルチメディアDAISY作ってほしいと要望を出しても難しいと思う。そこで、まずはアクセシブルなテキストDAISYから目指す(ボランティアベースでマルチメディアDAISYを製作するにしても、紙の書籍からマルチメディアDAISYを作るよりは、テキストDAISYからマルチメディアDAISYを作る方がコストは安く押さえられるはず)。

ガイドラインの作成については、以下でまとめたことがあります。

2 マルチメディアDAISY普及のための団体を図書館の外に立ち上げる

  • 理解のある出版社あるいは出版関係者を巻き込んでマルチメディアDAISY普及のための団体を立ち上げる。
  • 様々な業界におけるマルチメディアDAISYの橋頭堡となるべき団体があるべきだと思う。
  • その団体で商業ベースでマルチメディアDAISYを出版するにはどうすればよいか研究したり、定期的に啓発イベントを行ったりする。
  • 出版社という組織ではなく、まずはその中にいる編集者に興味を持ってもらい、働きかける。そのためには、こういう団体が存在するほうがよいのではないか。
  • 岩田美津子さんがたちあげた「点字つき絵本の出版と普及を考える会」という団体はロールモデルになるのではないか。

3 技術者をもっと巻き込む

  • アクセシビリティに関心のある技術者や研究者は多い。また、技術的にやれる余地はかなり残されているのではないかと思う。著作権法第37条クラスタが抱えている問題をもっとオープンにして様々な技術者や研究者が参加しやすい体制を。
  • 例えば、青空文庫は、こんなに困っているんですということをアピールでアイデアソンを開いて、幅広い技術者の関心を集めた。こういう手法はもっと採用されるべき。
    青空文庫を救え!「Code for 青空文庫」アイデアソン #1 レポート #‎aozorahack

4 オーディオブック関係者/団体との連携を図る

  • 商業ベースでマルチメディアDAISYを出版させるビジネスモデルとしては、米国のアマゾンのImmersion Readingがやっているような、オーディオブックとKindle図書を別々に販売し、両方を購入した人にはその両方を掛け合わせて、マルチメディアDAISY機能として利用できる方法はかなり有効ではないか。
    Kindleで洋書を読むならImmersion Readingを使ってみよう
  • オーディオブック業界とはもっと連携を図って、図書館側の要望を伝えてもよいのではないか。ユーザー側の意見として