MTM(Swedish Agency for Accessible Media)のオンラインサービスLegimusなど

 DAISY Consortiumは今年で20周年を迎えるのだそうです。そして、昨年、2015年6月の理事会で、スウェーデンのMTM(Swedish Agency for Accessible Media)のJesper Klein氏がDAISY Consortiumの新しい会長(Chairman of the Board)に選任されています。38歳。若い。

 で、前置きが長くなってしまいましたが、そのJesper Klein氏が、以下の記事でDAISY Consortiumが今年で20周年を迎えることを紹介しつつ、所属するMTMの活動について紹介していました。MTMの最近の活動がよくまとまっていますので、この記事を箇条書きで要点をまとめてみました。

スウェーデンの概要

  • スウェーデンの人口:あまり多くない。980万人。移民が160万人と移民が占める割合が大きい。
  • インターネット利用率:世界でももっとも高い国の1つ
  • DAISY規格が生まれた国でもある。
  • MTMのターゲットである視覚障害者とディスレクシアは人口のおおよそ6パーセント、つまり、約60万人。この60万人に含まれない知的障害、認知障害などもMTMのターゲットになると思われるが、正確な数は分からない。

MTM(Swedish Agency for Accessible Media)のオンラインサービスLegimus

  MTM(Myndigheten för tillgängliga medier : 英語でSwedish Agency for Accessible Media)

  • MTMのアクセシブルな資料を提供するサービス、Legimus(http://www.legimus.se/)
  • コンテンツの提供インターフェイスは、ウェブサイト。iOSアプリや、Androidアプリ、DAISY配信プロトコルを用いたサービス
  • Legimusの登録ユーザー数は10万人(スウェーデンの人口の約1%)
  • 提供するコンテンツ数は、2016年初めで肉声で読み上げ録音したスウェーデン語のDAISY図書111,181点。全て無料で提供されている
  • 2014年は、その年にスウェーデン語で刊行された市販本(trade books)とテキストブックの約25%の録音図書を追加することができた。
  • その録音のほとんどが、商用のオーディオブックで朗読する俳優のような有名人ではないが、熟練した音訳者に読み上げによるもの。

MTM(Swedish Agency for Accessible Media)のその他

  • Legimusのオンラインサービス以外に、CDベースのサービスを図書館経由で利用しているものが、高齢の視覚障害者を中心に2万から3万人いる。
  • Legimusの利用者10万人とあわせると、MTMは13万人の利用者を持つことになる。ターゲットとなる人口の60万人の21.7%だ。
  • なぜ、たった21.7%しかいないのか。Klein氏は以下の4つの理由を挙げている。
    • ロービジョンやディスレクシアの人で、聞いて読書するよりがんばって目で読むほうがよい人は、大活字本を含む印刷した書籍、PDFやEPUB2で刊行された商用の電子書籍を読んでいる。
    • 読書をする習慣がそもそもない人がいる。
    • 多くのプリントディスアビリティのある人にまだサービスが知られていない。
    • 既存のオーディオブックサービスがベストセラーのタイトルを押させており、それで十分にニーズが満たせている。

プリントディスアビリテリィのある人のためのテキストデータコンテンツの提供の課題

 視覚障害や学習障害など様々な理由で印刷物を読むことが困難な状態、つまり、プリントディスアビリティ(Print Disability)にある人のために、紙の書籍からテキストデータコンテンツ(テキストDAISYやプレーンテキストなど)を製作する図書館や機関、団体が増えてきています。紙からテキストデータを作成する場合には、まずOCRの認識率の問題、それに伴うテキスト校正作業のコストの問題が出てきますが、今回はそれは置いておいて、テキストコンテンツ記述面における提供の課題について整理したいと思います。
 一言で申せば、音声合成システム(TTS)では、読み上げられない文字が存在することに起因する問題です。

1. 音声合成システム(TTS)で読み上げられない文字

 「読み上げられない」というのは、漢字の読み間違いのような誤読が発生するという話ではなく、音声合成システム(TTS)がその文字の辞書そのものを持っていないという問題です。そのため、該当する文字に音声合成システム(TTS)が出会った場合に、そこに文字があるということそのものは認識するようですが、その文字を無視をして読み上げません。
 総務省が2015年7月に公開した「音声読み上げによるアクセシビリティに対応した電子書籍制作ガイドライン」に詳しいので、該当箇所をそのまま引用します。

図 3 TTS ソフトの読み上げ可能な領域と読み上げ不可の領域。音声合成システム
(TTS)が読める範囲は、JIS X 0208:1997の範囲、つまり、第2水準までの6879文字であり、JIS X 0213:2004に含まれている文字で第3水準以降の4354文字はTTSでの読み上げに対応してないことが示されている
日本語の文字は JIS 第 1 水準、第 2 水準を規定した JIS X 0208:1997 と、第 3 水準、第 4 水準を規定した JIS X 0213:2004、そしてこれらに含まれない外字などが存在する。TTS ソフトで読み上げ可能な文字は現状では JIS X 0208:1997 の範囲にとどまっており、JIS 化されている文字のほぼ半分が読み上げ対象外となっている。
from 「(PDF)音声読み上げによるアクセシビリティに対応した電子書籍制作ガイドライン」p11より

 なお、実際のところ、第3水準以降の全ての文字を音声合成システム(TTS)で読み上げられないというわけではなく、第3水準以降でも一部の文字については、読み上げるソフトもあるようです(多くが第2水準以下に含まれる漢字の異体字だと思われます)。とはいえ、多くの文字が音声合成システム(TTS)で読み上げられないという問題が存在することには変わりありません。第3水準以降の文字は、現在の日常生活ではほとんど見かけることにない漢字ばかりですが、地名や人名などに用いられることもあるため、そのような地名、人名がでてくる可能性の高い学術文献や旧字資料のテキストデータを提供する場合には、これに対する対応が求められます。
 漢字の読み上げで誤読をしても、その誤読から文字を類推することは可能ですし、その文字の存在をユーザーに伝えることもできます。また、熟語単位で読み間違えても一字単位に文字を読み上げることで、文字を確認することができますので、一定の確かさは保障されているとはいえます。しかし、音声合成システム(TTS)が音に出して読み上げることそのものができない文字はそれもできません。プリントディスアビリティのある人を想定してテキストデータを製作する場合は、これらの文字に対する何らかの対応が必要になります。

2. 音声合成システム(TTS)が読み上げない文字に対する対応

 対応する方法として次の(1)から(6)が考えられます。
 以下の(1)から(6)の例として、中国は清代末期の人物、「李沅発」(り げんはつ)の「げん」の字に用いられている

「沅」

の字を用います。第3水準の漢字。この人物の名前ですが、TTSで読み上げると、「沅(げん)」の字を読み上げずに「すもも はつ」と読み上げるものが複数あるようです。
※2016年2月16日追記
 最初、「宮﨑あおい」の「﨑」を例として挙げていましたが、「﨑」の字は複数のTTSで読めるという指摘を複数の人からいただきました。そこで、宮﨑あおいとは違い、この人物に全く思い入れはありませんが、「李沅発」(り げんはつ)(参考 李ゲン発 – Wikipedia)を例として使用することにしました。

(1)の1 読みを補記する

 該当する文字の後ろに括弧でくくるなどして、読み情報を補記する方法です。

例(李沅発の後ろに読み情報である「り げんはつ」を追加)
 李沅発 → 李沅発(り げんはつ)
長所
  • 原本通りの漢字をそのまま使用したまま、正確な読み上げを一応担保できる。
  • プレーンテキストでも記述が可能である。
短所
  • 原本に存在しない情報が本文に混ざるため、原本に本来あった情報とあとで補記された情報が区別できなくなってしまう。
  • 原本に存在した情報とテキスト作成者が補記した情報を区別できたとしても、引用する時の作業で、注記を削除する作業が必要になる
  • 上の例の「李沅発(り げんはつ)」の場合、「李」と「発」の字は読み上げに対応しているため、その部分が二度読まれることになる(つまり、この場合、「すももはつ りげんはつ」と読まれる)。

 
※2016年2月13日追記 

(1)の2 読みを補記する(注記であることを明記する)

 (1)の1では、原本に本来あった情報とあとで補記された情報が区別できないという問題がありました。そこで、補記した注記であることをの説明を追加するという方法が考えられます。
  
 なお、以下の例では、わかりやすく「テキスト作成者注記 注記ここまで」と言葉で注記の範囲を示していますが、※(米印)などで置き換えてもよいかもしれません。その場合は、※(米印)で囲んだものが、テキスト作成者による注記であることを、冒頭に凡例の形で分かるようにしておく必要があります。

例(宮﨑の後ろに読み情報である「みやざき」、その前後に注記であることをの説明を追加)
 李沅発 → 李沅発(テキスト作成者注記 り げんはつ 注記ここまで)
長所
  • 原本通りの漢字をそのまま使用したまま、正確な読み上げを一応担保できる。
  • 原本にあった情報と注記としてテキスト作成者が補記した情報を区別できる。
  • プレーンテキストでも記述が可能である。
短所
  • 原本に存在した情報とテキスト作成者が補記した情報を区別できたとしても、引用する時の作業で、注記を削除する作業が必要になる
  • 上の例の「李沅発(り げんはつ)」の場合、「李」と「発」の字は読み上げに対応しているため、その部分が二度読まれることになる(つまり、この場合、「すももはつ てきすとさくせいしゃちゅうき りげんはつ ちゅうきここまで」と読まれる)。

※2016年2月13日追記ここまで 

(2)代替可能な漢字に置き換える

 異体字のような代替可能な漢字がある場合に限られますが、音声合成システム(TTS)が読み上げられる文字に置き換える方法です。

例(「沅」を異体字の「源」に置き換える)
 李沅発 → 李源発
長所
  • 音声合成システム(TTS)が読み上げられる上に、(1)のような二度読みをさけることができる。
  • プレーンテキストでも記述が可能である。
短所
  • 原本に忠実な表記ではない。漢字を置き換えたことを何らかの形で情報として提供しない限り、ユーザーがどこで漢字が置き換えられたか判別することができない。

(3)特に何もしない

 読み上げられない文字はやむを得ないと割り切って何もしないという対応です。

 李沅発
長所
  • 原本に忠実な表記である。
短所
  • 音声合成システム(TTS)が該当箇所を読み上げられない。

(4)構造化した読み情報を本文とは区別できる形で提供する(ルビをふる)

 原本本来の表記を維持し、かつ読み情報を本文と混同させないためには、読み情報を構造化し、本文と区別できる形で提供する必要があります。その1つの方法として、ルビをふるという方法があります。

例(ルビをふる)
 沅発げんはつ
長所
  • 本文と区別することができるため、TTSで正確な読みを担保した上で本文の確かさを保障することができる。
  • ルビの読み上げに対応しているDAISY閲覧ソフト、EPUB3閲覧ソフトは多い。
短所
  • EPUBやDAISY3ではこの方法をとることができるが、プレーンテキストでこの方法はとることができない。
  • ルビと漢字の両方を読む音声合成システム(TTS)が多いため、二度読みされる箇所がある。上の例の「宮﨑(みやざき)」の場合、「宮」の字は読み上げに対応しているため、その部分が二度読まれることになる(つまり、この場合、「みやみやざきあおい」と読まれる)。
  • サピエ図書館が定めるテキストDAISYの製作ガイドラインでは、ルビは原本にある場合にのみに使用するとなっており、音声合成システム(TTS)に対応していない文字に読み情報を追加する用途は、このガイドラインでは想定されていない。

(5)構造化した読み情報を本文とは区別できる形で提供する(SSMLを使用する)

 ルビは、読み情報を提供するだけではなく、説明をつけたり、様々な用途に用いられるため、かならずしも用途に適しているとはいえません。そもそもルビは人間であるユーザーに見せるために表示するものであって、機械、つまり、音声合成システム(TTS)に読み情報を伝達するというのは、ルビのあり方としては本来は副次的なものとも言えます。機械(TTS)に読み情報を伝えることを伝えることを本来の役割としているSSML (Speech Synthesis Markup Language)を用いるという方法が考えられます。

例(SSMLで記述する)
 <span ssml:ph=“リゲンハツ”>李沅発</span>
長所
  • 本文と区別することができるため、TTSで正確な読みを担保した上で本文の確かさを保障することができる。
  • 二度読みをさけることができる。
  • ruby要素を用いず、SSMLによって読み情報を持たせることができるため、サピエ図書館のテキストDAISYの製作ガイドラインとも衝突しない)。
短所
  • EPUB3はSSMLに対応しているが、DAISY3では対応していない。構造化できないプレーンテキストでももちろん利用することはできない。
  • EPUB3閲覧ソフトでもSSMLに対応しているものは皆無(ではないかと思われる)

(6)音声を追加する

 音声合成システム(TTS)ではなく、肉声で読み上げた音声データを追加する方法も考えられます。一言で言えば、DAISYまたはEPUB形式の「マルチメディアDAISY」として提供するということになります。マルチメディアDAISYとして提供する場合は、該当する文字だけではなく、全文テキストに対応する音声を追加することが前提となります。該当する文字だけ、または、それを含む文章に対してだけ音声データを追加する方法も考えられなくはありません。しかし、その場合は、読み上げる箇所に応じて音声合成システム(TTS)による読み上げと音声データに読み上げが自動的にうまく切り替えられる必要があると思いますが、そのような機能を備えたDAISYまたはEPUB閲覧ソフトはない気がします。

長所
  • 肉声で読み上げた音声を別につくるため、原本に忠実な表記を維持しつつ、正確な読み上げを担保することができる。
  • 不必要な二度読みも避けることができる。

短所
  • 音声データを別に用意する必要があるため、それを製作するたコストがかかる。
  • 音声データとテキストデータを関連づける編集作業コストもテキストの長さに応じてそれ相応にかかる。
  • 音声データを持つことになるため、ファイルサイズが重くなる。

  

参考

 マルチメディアDAISYについては、以下をご参照ください。

 学術活動における利用の場合は、テキストが引用されることも想定しなければなりません。原本と異なる文字が使用されたり、本来原本に含まれていない情報が補記として区別できない形で追加されてしまうとその利用に支障がでる可能性があります。そのため、学術活動でも利用されることを想定する場合は、原本に忠実な表記を維持しつつ、原本に本来あった情報と区別できる形で読み情報を音声合成システム(TTS)に提供することが求められます。その点では、上の(1)の2、(4)、(5)、(6)の対応が求められるということになります。その点では、上の(4)から(6)の対応が求められるということになりますが、製作コストやフォーマットによる制限で(1)から(3)の対応をせざる得ないこともあります。
 
 上でも少し触れましたが、次はテキストデータコンテンツを提供するフォーマットについても少し整理します。

3. 提供するフォーマットの課題

 プリントディスアビリテリィのある人にテキストデータコンテンツを提供するフォーマットとして、現時点では、プレーンテキスト、DAISY3、そして、その後継規格であるEPUB3が考えられます。上の2でも(1)から(6)の話の中で、触れているところもありますが、フォーマットごとに長所と短所をまとめてみました。DAISY3とEPUB3そのものについては、再掲になりますが、以下で紹介していますので、こちらをご参照ください。

(1)プレーンテキスト

 拡張子txtのテキストデータです。どの環境でも編集や閲覧ができるエディタは標準でインストールされています。編集も特別なICTスキルは必要なく、製作環境、閲覧環境ともにもっとも制約の少ないフォーマットと言えます。

長所
  • 構造化のコストもかからないため、低コストかつ短期間で製作することができる。
  • 製作環境を選ばないため、多くの人間が製作することが可能である。
  • 専用のソフト等のインストールが必要なく、閲覧環境にほぼ制限がない
  • ファイルサイズも軽量である
短所
  • 構造化できないため、コンテンツが大部になる場合のナビゲーションが不足する
  • 音声合成システム(TTS)が読み上げない文字については、上の2(1)〜(3)のいずれかの対応に限定される。

(2)DAISY3

 日本では、プリントディスアビリィのためのテキストDAISYは、主にDAISY3で製作されていいます。ルビをふることで読み情報を補記することも「一応可能」です。

長所
  • 構造化できるため、大部なコンテンツでも様々なナビゲーションを提供できる。
  • ルビをふることが「一応可能」であり、ルビという形で本文とは区別される形で読み情報を提供することができる。
  • プレーンテキストに比べると閲覧環境に制約があるとはいえ、後で紹介するEPUB3と比べると閲覧環境はまだ整備されている(とはいえ、DAISY2.02で製作された音声DAISYと比較するとまだまだ限定的である)。
  • DAISY3に対応した閲覧ソフトは、プリントディスアビリティのある人が利用することを想定されているため、アクセシビリティに十分配慮されてる。
  • マルチメディアDAISYの製作も可能(ただし、日本では、ほとんどのマルチメディアDAISYはDAISY2.02で製作されている。)
短所
  • プレーンテキストと比較すると、構造化に製作コストがかかる。
  • ルビ表記は一応実現されているが、これは日本独自の実装によるもので、DAISY3本来の仕様には含まれているものではない。そのため、正式なコンバータでEPUB3に変換した場合には、ルビにいれた情報はおそらく落とされる。長期保存の観点から問題がある。
    (参考)DAISY3がruby要素に対応していないため、この手法が使用されてる。
    ruby要素を擬似的に再現する ≪ Archive ≪ Alias under the Azure
  • サピエ図書館が定めるテキストDAISYの製作ガイドラインでは、ルビは原本にルビがある場合にのみに使用するとなっている。音声合成システム(TTS)に対応していない文字に読み情報を追加する用途は、このガイドラインでは想定されていない。

(3)EPUB3

 電子書籍のメインストリームのフォーマットとして使用されていますが、DAISY3の後継規格でもあり、DAISYが備えるアクシブルな機能を継承し、さらには読み情報の構造化に関する機能など日本語にとって重要な機能が追加されています。純粋に技術的な観点でみれば、フォーマットとしては、これが解決策になりえますが、短所にも書いてあるとおり、閲覧環境が十分ではありません。

長所
  • 構造化できるため、大部なコンテンツでも様々なナビゲーションを提供できる。
  • ruby要素に仕様レベルで正式に対応している。
  • SSMLによって読み情報を持たせることが可能である。
  • マルチメディアDAISYの製作も可能(ただし、日本では、ほとんどのマルチメディアDAISYはDAISY2.02で製作されている。)
短所
  • プレーンテキストと比較すると、構造化に製作コストがかかる。
  • プリントディスアビリティにとって使いやすい閲覧環境がDAISY3と比較してもまだ十分に整備されていない(とはいえ、かなり改善されつつある)
  • SSMLに対応した閲覧ソフトも編集環境もまだない(と言い切ってよいと思う)。

(4)その他

その他に、WORDファイルもあり得るかもしれません。WORDファイルのアクセシビリティは私も勉強不足でまだよく分かっていませんので、ここでは、省略します。

4. まとまりのないまとめ

 マルチメディアDAISYや、SSMLを用いて読み情報を提供するEPUB3形式で提供できれば理想的と言えます。
 しかし、プレーンテキストからDAISYやEPUBを製作するには構造化のコストがさらにかかり、また、製作環境や閲覧環境も制約されるため、常にこれを選択できるわけではありません。特にEPUB3閲覧ソフトでSSMLに対応しているソフトは皆無ではないかと思われるため、現時点でのSSMLを用いたEPUB3形式での提供は時期尚早だと思われます。マルチメディアDAISYも上で述べたように音声ファイルの製作コストやそれにテキストデータを関連付けるコストがさらにかかります。
 製作コスト、製作環境や閲覧環境の観点からみれば、プレーンテキストが他のフォーマットに比べて優れていると言えるかもしれません。しかし、音声合成システム(TTS)が読み上げない文字に対する対応としてプレーンテキストでとれるものは、上の2にあげたものでは、上にあげた2の(1)から(3)のいずれかになります。(1)の1「読みを補記する」、(2)「代替可能な漢字に置き換える」、(3)「特に何もしない」は一長一短あり、全ての利用者層のニーズを満たすものはありません。かろうじて、(1)の2の「(1)の2 読みを補記する(注記であることを明記する)」が、広い範囲のニーズを満たすものと言えるでしょうか。どれも一長一短あり、全ての利用者層のニーズを満たすものはありません。
 音声合成システム(TTS)が読み上げない文字に対する対応の観点からは、プレーンテキストでは、(1)の2の「読みを補記する(注記であることを明記する)」の対応をしつつ、構造化では、EPUB3のSSMLの利用環境が整うまでは、DAISY3による構造化しかないかもしれません。(1)の2の対応では、構造化を見越して自動的に構造化できるような記述方法がとれるとなおよいかもしれません。
 なんとも歯切れのわるい話ですが、音声合成システム(TTS)が読み上げない文字に対する対応の観点から、現時点で100点といえるフォーマット、記述方法はないため、EPUB3のSSMLの利用環境が整うまでは、対象となるコンテンツと提供する利用者像を勘案して対応を検討するほかないかもしれません。
※2016年2月13日追記
(1)の2が追加されたことにともない、上のように修正しました。

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

 何かを例えば、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個で、複数の回答が可能です。