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

　何かを例えば、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. ある程度全体像が予測しやすいように配慮する

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