8月 03

アクセシビリティの観点から電子書籍のおけるTTSの読み上げの正確性をどこまで保障するべきか

 総務省から電子書籍のアクセシビリティを確保するための調査研究の報告書が出たこともあって、また、それに関係しての前後の動きだと思いますが、電子書籍のアクセシビリティに関係するイベントが最近、開催されることもあって、タイトルにあるようにアクセシビリティの観点から電子書籍のおけるTTSの読み上げの正確性をどこまで保障するべきかという議論が起きています。

 端的にいって、SSMLなどを用いてTTSによる読み上げの正確性を保障することについては、賛否両論、というより、Web関係者の間では、批判的な意見が多いような印象がありますが、私の考えをまとめておこうかと思います。知識不足からくる思い込みもあるかと思いますので、ご容赦を。

 結論から言えば、TTSの読み上げの正確性をどこまで保障するべきかは求められるニーズと負担できるコストによる、つまり、コンテンツ次第なので一律に全部保障すべきであるとか、TTSに任せておけばよいとも言えない、というのが正直なところです。誤読があっても許容できる(それよりもむしろ早く提供してほしいというニーズがつよい)ものもあるでしょうが、一方で、教科書や辞書、児童向けの書籍(ルビなどが多くふられている書籍などはイメージしやすいでしょうか)などのように、正確な読み上げが求められるものが確かにあります。

 ですので、コンテンツの性質と目的、正確性を求められるニーズ、負担できるコストに応じての水準で、正確性を保障していければよいのだろうと考えています。問題は、現在の状況は、この「応じての」対応ができないことです。
 
 現時点では、SSML(ヨミ情報等をTTSに渡すマークアップ言語)やPLS(ヨミ情報の辞書)に対応したEPUBの閲覧環境や制作環境がないため、TTSでは、読み上げの正確性のニーズに対して、現状では対応できません。そのため、肉声等によって正確に読み上げられた音声ファイルを作成する(つまり、録音図書かマルチメディアDAISYとして作成する)しか方法がありません。
 
 つまり、誤読も許容してTTSの辞書任せで読み上げさせるか、マルチメディアDAISY化(つまり、肉声等による読み上げで完全に正確な読み上げを保障するもの)か、のどちらかしか選択肢がしかなく、その中間がありません。たとえば、基本的に誤読は許容するけど、専門用語や人名、地名などの誤読はなくしたいとか、ルビが振られている箇所だけは誤読をなくしたいという中間的なニーズにあった対応方法がなく、そのゼロか百かのいずかの選択をせざるを得ない状態です(正確にはルビを読み上げさせるとか、部分的なマルチメディアDAISY化というのも考えられなくはないですが)。

 また、EPUBリーディングシステムのMedia Overlaysへの対応が進んでいるとはまだまだ言えない状況であるため、上の後者(音声化)の選択も実質的にはとりづらく、アクセシビリティの観点からみれば、EPUBは誤読を許容するコンテンツしか入る余地がない状況です。

 また、別の問題として、TTSが読み上げない文字の存在があります(基本的にSHift-JISでサポートしていない文字に多いと考えればよいみたい)。

図 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より

 TTSは、これらの文字の存在そのものは、認識はするものの、まったく読み上げません。誤読でも読み上げてくれれば、全盲者でもその存在を認識できますが、読み上げない文字を全く認識することができません。こういう文字はSSMLなどで読みを入れて読み上げられるようにするしか方法はないのではと思います。

 全文にSSMLを入れるというのは、おそらくは当面、かなりの高コストなのでしょうが、部分的にここだけは読み上げを保障したいというところにSSMLを使うとか。制作環境でルビタグを入れる箇所には、自動的にSSMLも入れる機能を実装する(略ルビとかいろいろあるので、修正は必要でしょうか。)ことで、ルビがふられた箇所の読み上げの正確性を保障するとか(児童書など出版社が子どもに対する配慮でルビが必要だと判断した箇所に結果として読み上げが保障されることになる)とかできないだろうかと考えるわけです。
 
 EPUB 3では、SSMLに加えて、PLSという形式で全体にわたる読み情報の指定を辞書という形で持たることができます。本文中に何度も出てくる固有名詞や地名、索引に掲載される用語についてPLS辞書を持たせるだけでもかなり誤読を減らすことができるはずです。EPUB3の仕様では、TTSが読み上げる優先順位は、

SSML>PLS>TTSの辞書

となっています。全文にSSMLを埋め込む方法がもっとも読み上げの正確性を保障できますが、仕様通りに実装されているならば、全体にわたる読み情報の指定は、PLS辞書で、それ以外の例外的な読み方法の提供はSSMLで指定するだけでもかなりの正確性を担保できるのではないかと思います。地名などは、PLS辞書を使い回せないのかとも思ったりしますが、これはどうなのでしょうか。

 上に紹介した総務省の報告書には、ウェブアクセシビリティガイドラインで知られるW3CのWCAG2.0に倣って、読み上げ対応について、達成度を3段段階にわけて要件を提示しています。
 個々の要件やそれぞのレベルについては、議論のあるところかもしれませんが、私は全体的な傾向は概ね同意できます。

  • まずは、出版される全ての出版物でレベル1を目指す。
  • その中からコンテンツの性質、ニーズに応じてレベル2や3を目指す(今は、それを実現できる実装が制作環境にも節欄環境にもないので、まずはそれの実現が必要ですが)。
  • そして、場合によっては図書館等が視覚障害者等の利用者のリクエストを受ける形で、著作権法第37条第3項に基づいてアクセシビリティ機能を追加して、レベルを引き上げる(著作権法第37条第3項でアクセシビリティの追加をどこまでできるかは議論のあるところですが)

というは、考えとしてありではないかと思いました。

表 1-1 音声読み上げによる電子書籍アクセシビリティの実現レベル(案)

レベル 電子書籍コンテンツ リーダー
0 ・音声読み上げを行えるようなテキストデータを持たない場合。 ・OS が提供するアクセシビリティ支援機能を利用することができない場合。
・又は、電子書籍専用端末が、アクセシビリティ支援機能を持たない場合。
1 ・音声読み上げに対応できるよう、テキストデータを持っていること(紙面が画像で構成されている固定レイアウト型の場合は、マルチレンディション1により、画像とは別にテキストデータを持つ)。
・かつ、最低限の構造化がなされていること。
・電子書籍コンテンツに含まれるテキストデータを、OS が提供するアクセシビリティ支援機能に渡せること、またはリーダーがテキストデータを読み上げできること。
・また、電子書籍の構造に従い、最低限のナビゲーション機能が利用できること。
2 ・テキストを正しく読み上げできるよう、誤読しやすい部分や音声化しないと内容伝達に支障がある画像等(例えば外字)に対して、正しい読み方の情報を持っていること。
・かつ、章や節などが正しく構造化されていること。
・電子書籍コンテンツに含まれるテキストデータを、OS が提供するアクセシビリティ支援機能に加え、TTS ソフト等のアクセシビリティ支援ツール等に出力できること。
・又は、レベル 2 以上の電子書籍コンテンツが持つ読み方の情報をテキストデータとともに出力できること。
・上記に加え、電子書籍コンテンツの構造に従い、目次と本文の間の移動、飛ばし読みなど適切なナビゲーション機能が提供されていること。
3 ・レベル 2 に加え、電子書籍のテキスト及び音声化しないと内容伝達に支障がある画像等(例えば外字)のすべてに対して、正しい読み方の情報もしくは正しく読み上げられた音声データファイル(audio データ)を持っていること(肉声、TTS は問わない)。
・また、発話する言語種別に関する情報、発話音声の種別(性別、声質等)に関する情報を持っていること。
・レベル 2 に加え、レベル 2 以上の電子書籍コンテンツが持つ、読み方その他発話に関する情報に基づき、その指示とおりに正しく読み上げできること。
・その際に、読み上げスピードの変更等、利用者に適した読み上げを行えるように調整を行えること。
・また音声データファイルを持つ電子書籍の audio データを再生することができ、メディアオーバーレイ(mediaoverlays)の機能が再生可能なこと。

(PDF)電子書籍のアクセシビリティを確保するための調査研究報告書』3ページ(PDFのページでは8/84ページ)より

 話は少し逸れて、最後に申し上げておくと、電子書籍のアクセシビリティという話になると、議論が読み上げ対応が集中しすぎてしまっている印象があります。アクセシビリティが求められるのは、読み上げソフト利用者に限定されないので、アクセシビリティメタデータやリーディングシステムの実装(どのような支援機能が必要か 文字サイズ変更、行間変更、配色変更、縦書き・横書き変更 etc.)などなど、スコープを拡げて要件を整理していく必要があると思います。

7月 31

EPUB3で製作された録音図書にも対応したDAISY再生機器PTR3

発売が予定されているDAISY再生機器プレクストークPTR3がEPUB3にも対応しています。これが、EPUB3のMedia Overlaysに対応しており、EPUB3で製作された録音図書(本文部分が音声のみ)に対応しているようです(おそらくは、すでに発売されているプレクストーク PTN3も)。

 以下のエントリを書いたのが2013年6月だから、EPUB3で録音図書を製作できることを私が知ったのもそのあたり。

そのことを知ってから、EPUB3で録音図書が再生できる環境が整備されれば、

  • 特定の機器や再生環境に依存せず、メインストリームなEPUBの環境で録音図書が再生できるようになる(それは、たくさんあるEPUBの閲覧環境を選択できることを意味し、自分にあった閲覧環境を選ぶことができる選択肢ができる
  • 商用のオーディオブックがEPUB3で販売されるようになれば、それはいわゆるDAISY録音図書、あるいはその近似値。図書館や点字図書館が著作権法の権利制限規定で製作するのを待つまでもなく、ユーザーが購入することができるようになる<(商用コンテンツと、図書館製作コンテンツのフォーマット上の境目が曖昧になる)/li>

 ということが実現されるのではないかとわくわくしていました。EPUB3録音図書の閲覧環境が整備されることを今か今かと待ちわびていましたが、その一歩がついに現実に。
 

6月 14

EPUB Accessibility 1.0 概要

 EPUB3.1の仕様と同時に公開されたEPUBのアクセシビリティの仕様 EPUB Accessibility 1.0 について概要をまとめてみました。

仕様及び関連文書

  EPUBのアクセシビリティの仕様は、EPUB Accessibility 1.0 。これは規格として策定されたものなので、長期的な使用に耐えうるように、その時々の技術には依存しない形で書かれているため、要件も抽象的な記述になっている。具体的な実装方法は、関連文書であるEPUB Accessibility Techniquesに参照することになる。これは、WCAGとWCAGの関連文書である”Techniques(実装方法集)”と同じ関係。EPUB Accessibility Techniques に似た立ち位置の文書として 古くからあるEPUB 3 Accessibility Guidelines が存在するが、Techniques のさらなる追加の説明文書的な立ち位置として整理されているらしい。
  

 また、EPUBもウェブ技術を使用しているので、アクセシビリティの要件をのかなりの部分をWeb Content Accessibility Guidelines (WCAG) 2.0 に拠っているので、これも参照する必要がある。

EPUB Accessibility 1.0が対象とするEPUBのバージョンの範囲

 EPUB3.1と同じタイミングで公開されたものだが、EPUBの特定のバージョンを対象とするものではなく、古いバージョン又は将来のバージョンも含む全てのEPUBのバージョンを対象とする。

EPUB Accessibility 1.0のポイント

 個人的にポイントと感じたところは以下。

  • アクセシビリティメタデータは必須。超重要。この仕様で最低限満たすべきとしているラインがアクセシビリティメタデータを提供すること。
  • WCAG2.0のレベルAが必須要件。レベルAAは推奨。なので、非テキストコンテンツに対する代替テキストは必須
  • 音声(非テキストコンテンツ)が主たるコンテンツである録音図書は、WCAG2.0の要件を満たすものではない(代替テキストがないから)。しかし、不可ではない。特定の利用者に最適化されたものであり、だからこそ、それとわかるアクセシビリティメタデータを提供することが重要
  • ページ数のある紙版等のバージョンがある場合は、ページ番号は提供すべきとしている
  • TTSによる読み上げの支援(SSML、PLS)に関する規定はなし
  • DRMは否定していないが、支援技術によるアクセスを阻害する制限は不可
  • 補論という形で閲覧ソフトと配信システムの要件も規定されている

 印象としては、この仕様はそれほど高いハードルを設けていない。アクセシビリティメタデータを提供すれば、EPUB Accessibility 1.0の必須要件に準拠したと言えるものは多いのではないか。DRMだな。DRMかなぁ…

概要

 EPUB Accessibility 1.0は、要件の適合によって以下のとおり、発見可能なEPUB出版物、アクセシブルなEPUB出版物、最適化されたEPUB出版物の3つに整理されている。

発見のメタデータ要件 アクセシビリティの要件 最適化(規格またはガイドライン識別)の要件
発見可能なEPUB出版物 適合  
アクセシブルなEPUB出版物

適合 適合  
最適化されたEPUB出版物

適合   適合

 

発見のためのメタデータ要件

 EPUB 3 Publication(OPFファイル)に格納されるメタデータにschema.orgのアクセシビリティメタデータ以下のように包含することを求めている。詳細は、以下のエントリにまとめたのでそちらを参照。

必須(must)

推奨(recommended)

任意(optional)

アクセシビリティの要件

 以下のとおり。

○WCAGとの適合性

 
 WCAGレベルAが必須(must)、WCAGレベルAAが推奨(recommended)となっている
 WCAGが求める要件も幅広いので、ここで全て網羅できないが、レベルAで求められている以下は直接関係がある要件だろうか。画像等の非テキストコンテンツに代替テキストの提供を必須としている点は重要(webだと最近だと提供することが常識になっていますが、電子書籍だとどこまで提供されているか・・・)。

原則 1: 知覚可能 – 情報及びユーザインタフェース コンポーネントは、利用者が知覚できる方法で利用者に提示可能でなければならない。
ガイドライン 1.1 テキストによる代替: すべての非テキストコンテンツには、拡大印刷、点字、音声、シンボル、平易な言葉などの利用者が必要とする形式に変換できるように、テキストによる代替を提供すること。

1.1.1 非テキストコンテンツ: 利用者に提示されるすべての非テキストコンテンツには、同等の目的を果たすテキストによる代替が提供されている。ただし、次の場合は除く: (レベル A)
(中略)

ガイドライン 1.3 適応可能: 情報、及び構造を損なうことなく、様々な方法 (例えば、よりシンプルなレイアウト) で提供できるようにコンテンツを制作すること。
1.3.1 情報及び関係性: 何らかの形で提示されている情報、 構造、及び関係性は、プログラムによる解釈が可能である、又はテキストで提供されている。 (レベル A)
1.3.2 意味のある順序: コンテンツが提示されている順序が意味に影響を及ぼす場合には、正しく読む順序はプログラムによる解釈が可能である。 (レベル A)
1.3.3 感覚的な特徴: コンテンツを理解し操作するための説明は、形、大きさ、視覚的な位置、方向、又は音のような、構成要素が持つ感覚的な特徴だけに依存していない。 (レベル A)

ガイドライン 1.4 判別可能: コンテンツを、利用者にとって見やすく、聞きやすいものにすること。これには、前景と背景を区別することも含む
1.4.1 色の使用: 色が、情報を伝える、動作を示す、反応を促す、又は視覚的な要素を判別するための唯一の視覚的手段になっていない。 (レベル A)
(中略)
1.4.3 コントラスト (最低限) : テキスト及び文字画像の視覚的提示に、少なくとも 4.5:1 のコントラスト比がある。ただし、次の場合は除く: (レベル AA)
(中略)
1.4.4 テキストのサイズ変更: キャプション及び文字画像を除き、テキストは、コンテンツ又は機能を損なうことなく、支援技術なしで 200% までサイズ変更できる。 (レベル AA)
1.4.5 文字画像: 使用している技術で意図した視覚的提示が可能である場合、文字画像ではなくテキストが情報伝達に用いられている。ただし、次に挙げる場合を除く: (レベル AA)
(中略)

原則 2: 操作可能 – ユーザインタフェース コンポーネント及びナビゲーションは操作可能でなければならない。
(中略)
ガイドライン 2.4 ナビゲーション可能: 利用者がナビゲートしたり、コンテンツを探し出したり、現在位置を確認したりすることを手助けする手段を提供すること。
2.4.1 ブロックスキップ: 複数のウェブページ上で繰り返されているコンテンツのブロックをスキップするメカニズムが利用できる。 (レベル A)
2.4.2 ページタイトル: ウェブページには、主題又は目的を説明したタイトルがある。 (レベル A)
2.4.3 フォーカス順序: ウェブページが順を追ってナビゲートできて、そのナビゲーション順が意味又は操作に影響を及ぼす場合、フォーカス可能なコンポーネントは、意味及び操作性を損なわない順序でフォーカスを受け取る。 (レベル A)
2.4.4 リンクの目的 (コンテキスト内) : それぞれのリンクの目的が、リンクのテキスト単独で、又はリンクのテキストとプログラムによる解釈が可能なリンクのコンテキストから判断できる。ただし、リンクの目的がほとんどの利用者にとって曖昧な場合は除く。 (レベル A)
2.4.5 複数の手段: ウェブページ一式の中で、あるウェブページを見つける複数の手段が利用できる。ただし、ウェブページが一連のプロセスの中の1ステップ又は結果である場合は除く。 (レベル AA)
2.4.6 見出し及びラベル: 見出し及びラベルは、主題又は目的を説明している。 (レベル AA)
(中略)

原則 3: 理解可能 – 情報及びユーザインタフェースの操作は理解可能でなければならない。
ガイドライン 3.1 読みやすさ: テキストのコンテンツを読みやすく理解可能にすること。
3.1.1 ページの言語: それぞれのウェブページのデフォルトの自然言語がどの言語であるか、プログラムによる解釈が可能である。 (レベル A)
3.1.2 一部分の言語: コンテンツの一節、又は語句それぞれの自然言語がどの言語であるか、プログラムによる解釈が可能である。ただし、固有名詞、技術用語、言語が不明な語句、及びすぐ前後にあるテキストの言語の一部になっている単語又は語句は除く。 (レベル AA)
(中略)

原則 4: 堅牢 (robust) – コンテンツは、支援技術を含む様々なユーザエージェントが確実に解釈できるように十分に堅牢 (robust) でなければならない。
ガイドライン 4.1 互換性: 現在及び将来の、支援技術を含むユーザエージェントとの互換性を最大化すること。

4.1.1 構文解析: マークアップ言語を用いて実装されているコンテンツにおいては、要素には完全な開始タグ及び終了タグがあり、要素は仕様に準じて入れ子になっていて、要素には重複した属性がなく、どの ID も一意的である。ただし、仕様で認められているものを除く。 (レベル A)
4.1.2 名前 (name) ・役割 (role) 及び値 (value) : すべてのユーザインタフェース コンポーネント (フォームを構成する要素、リンク、スクリプトが生成するコンポーネントなど) では、名前 (name) 及び役割 (role) は、プログラムによる解釈が可能である。又、状態、プロパティ、利用者が設定可能な値はプログラムによる設定が可能である。そして、支援技術を含むユーザエージェントが、これらの項目に対する変更通知を利用できる。 (レベル A)

 

<余談 EPUB形式の録音図書>

 少し話はそれるが、EPUB形式の録音図書について。WCAGは、以下のような要件もある。

ガイドライン 1.2 時間依存メディア: 時間依存メディアには代替コンテンツを提供すること。
1.2.1 音声のみ及び映像のみ (収録済) : 収録済の音声しか含まないメディア及び収録済の映像しか含まないメディアは、次の事項を満たしている。ただし、その音声又は映像がメディアによるテキストの代替であって、メディアによる代替であることが明確にラベル付けされている場合は除く: (レベル A)
収録済の音声しか含まない場合:時間依存メディアに対する代替コンテンツによって、収録済の音声しか含まないコンテンツと同等の情報を提供している。
収録済の映像しか含まない場合: 時間依存メディアに対する代替コンテンツ又は音声トラックによって、収録済の映像しか含まないコンテンツと同等の情報を提供している。
1.2.2 キャプション (収録済) : 同期したメディアに含まれているすべての収録済の音声コンテンツに対して、キャプションが提供されている。ただし、その同期したメディアがメディアによるテキストの代替であって、メディアによる代替であることが明確にラベル付けされている場合は除く。 (レベル A)
(中略)
1.2.7 拡張音声解説 (収録済) : 前景音の合間が、音声解説で映像の意味を伝達するのに不十分な場合、同期したメディアに含まれているすべての収録済の映像コンテンツに対して、拡張音声解説が提供されている。 (レベル AAA)

 上の要件については、以下のエントリを参照。

 つまり、音声には聴覚障害等の理由で利用できない人のために代替となるテキストデータを提供するということが求められています。1.2.2などは満たすとまさにEPUB with Media Overlays(マルチメディアDAISY)。音声を主たるコンテンツとするEPUB形式の録音図書(目次データのみがテキスト)は、WCAG レベルAの要件を満たせないということになる。つまり、「アクセシブルなEPUB出版物」である要件は満たせない。

 ただし、EPUB Accessibility 1.0 はEPUB形式の録音図書を否定はしていない。これについては、考え方を以下のように整理している。

  • WCAGは幅広いユーザーを対象とするので、録音図書のように、視角障害者に利用できても聴覚障害者に利用できないコンテンツは、WCAGの要件に適合しないということになる
  • しかし、特定のユーザーに最適化されたEPUB出版物をEPUB Accessibility 1.0はを否定しない。
  • その代わり、発見のメタデータの包含を提供することを重視し、豊富なアクセシビリティメタデータによって必要とする特定のターゲットに的確に発見されることを想定
  • EPUB形式の録音図書は、「概要」に掲載した表で言うところの、「アクセシブルなEPUB出版物」にはなれないが、「発見可能なEPUB出版物」と「最適化されたEPUB出版物」にはなれる

○EPUBのための追加要件

 WCAGだけでは規定できないEPUB独自の要件として、ページナビゲーションとメディアオーバーレイについて、以下のとおり規定している。EPUB独自の要件といえば、TTSのサポートとしてSSMLやPLSなども他にも言及されてもよい要件はいろいろあると思うが、ページナビゲーションとメディアオーバーレイ以外に言及はない。ちなみに関連文書のEPUB Accessibility Techniques 1.0 にもページナビゲーションとメディアオーバーレイ以外の言及はない。EPUB 3 Accessibility Guidelines まで行くといろいろある。

ページナビゲーション

 
 以下の場合は、ページナビゲーションを提供するべき(should)。

  • EPUB版とは別にページ数のあるバージョンの出版物(紙版の出版物等)がある場合
  • 教育等で印刷版とEPUB版の両バージョンを併用することが想定されるとき
メディアオーバーレイ

メディアオーバーレイドキュメント(SMILドキュメント)内にあるる全ての「スキップ可能な構造(skippable structures)」と「回避可能な構造(escapable structures」を識別することを保証する。

※といっても、DAISY3のようにコンテンツに「スキップ可能な構造(skippable structures)」と「回避可能な構造(escapable structures」を設定するのではなく、EPUB3の場合は、メディア オーバーレイ要素の epub:type 属性によって提供されるセマンティクス(ここは、footnoteですよ、figureですよという情報)に基づいて、リーディングシステムがスキップ機能や回避機能を提供することを想定しているので、何をすればよいのだろうか。きちんとepub:type 属性によってセマンティクスを提供するということだろうか。

最適化(規格またはガイドライン識別)の要件

 EPUB Accessibility 1.0 の「最適化(規格またはガイドライン識別)の要件」では、適合している規格、ガイドラインを識別するための情報を dcterms の conformsTo プロパティで提供することが必須(must)とされている。なお、WCAGもその対象になるが、WCAGだけは、「最適化(規格またはガイドライン識別)の要件」ではなく、「アクセシビリティの要件」として整理されている。

 詳細は、以下のエントリにまとめたのでそちらを参照。

配信(提供)にあたっての要件

デジタル著作権管理(DRM)

EPUB 出版物に適用される場合、製作者は、支援技術によるアクセスを阻害する制限を課してはならない(must not)。

配信業者に提供するメタデータ

  配信業者に提供するメタデータについても、その形式でアクセシビリティメタデータが提供できるならば、(配信業者が求めなくても)アクセシビリティメタデータを提供しなくてはならない(must)。

 これも詳細は、以下のエントリにまとめたのでそちらを参照。

おまけ

EPUB Accessibility 1.0 はあくまでコンテンツに対する要件をスコープとしているが、補論として配信システムとリーディングシステムの要件も提示している。

配信システムの要件

  • ユーザーインターフェイスは、[WCAG 2.0] レベル AA に適合しなければならない(must)。
  • 利用可能なアクセシビリティ メタデータによって、検索結果を絞り込む機能を提供しなければならない(must)。

リーディングシステムの要件

  • 全ての [A11Y Test Suite] の基本的なアクセシブル リーディング システムのテストを合格しなければならない(must)。
  • User Agent Accessibility Guidelines (UAAG) 2.0レベル AA 適合性の要件を満たすべきである(should)。
1月 07

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と実装方法集の関係の詳細については、以下をご参照ください。

7月 22

IDPFがEPUBのアクセシビリティの要件をまとめた仕様とその実装方法集のドラフトを公開

IDPFがEPUBのアクセシビリティの要件をまとめた仕様のエディターズドラフトとその実装方法を解説したTechniquesのエディターズドラフトを2016年4月に公開しています。そして、この7月にはその第2版が公開されています。

 文書のタイトルに”Discovery”という文言があるように、アクセシブルなコンテンツを発見するためのメタデータの要件にも力点が置かれています。

 この両文書はW3Cの”Web Content Accessibility Guidelines (WCAG) 2.0″とその関連文書である”Techniques for WCAG 2.0″の関係に相当するものを想定しているのでしょうね。

 IDPFはEPUB3のアクセシビティガイドラインを以下のように数年前から公開しています。

 これとの関係はよく分かりませんが、W3Cドキュメントの体裁に則った2016年に公開された仕様書に移行されることになるのでしょうか。たぶん。
 実際、要件とその実装方法を切り離した上のドキュメントのほうが全体的にすっきりしている気がする。

2月 07

マルチメディア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を使ってみよう
  • オーディオブック業界とはもっと連携を図って、図書館側の要望を伝えてもよいのではないか。ユーザー側の意見として
5月 28

アクセシブルな電子書籍とは何かを示すガイドラインの話(の続き)

 先のエントリで、以下の3つについて図書館がガイドラインを作成して要件を提示してはどうかという話をしました。

  • (出版社と電子書籍プラットフォームに対して)図書館が考える「アクセシブルな電子書籍」とは何か(コンテンツ作成ガイドライン)
  • (ビューワー開発者と電子書籍プラットフォームに対して)図書館が考える電子書籍の「アクセシブルな閲覧環境」とは何か(ビューワーのガイドライン)
  • (電子書籍プラットフォームに対して)図書館が考える電子書籍の「アクセシブルな提供方法」とは何か(コンテンツ提供ガイドライン)

 
 それぞれについてどのようなガイドラインを作成するべきなのか、参考になる先行的なものを含めてまとめてみました。

1.「アクセシブルな電子書籍」を示すコンテンツ作成ガイドライン

 EPUBのようなHTMLやCSS等のWeb標準技術をベースとした形式は、ウェブアクセシビリティのガイドラインとして知られるW3CのWeb Content Accessibility Guidelines (WCAG) 2.0( = JIS X8341-3:2010 = ISO/IEC 40500:2012)が対象とする「ウェブコンテンツ(Web技術によって作成されたコンテンツ)」に該当します。 

ウェブコンテンツとは、ウェブブラウザ、支援技術などのユーザーエージェントによって利用者に伝達されるあらゆる情報及び感覚的な体験を指し、例えば、ウェブアプリケーション、ウェブシステム、携帯端末などを用いて利用されるコンテンツ、インターネット、イントラネット、CD-ROMなどの記録媒体を介して配布されるウェブコンテンツ技術を用いて制作された電子文書、ウェブブラウザを用いて操作する機器などに適用する。
from JIS X8341-3:2010「1.適用範囲」
参考: ウェブアクセシビリティガイドラインWCAG 2.0とJIS X8341-3:2010に関する整理

 

 EPUBの場合は、JIS化もISO化もしているWACG2.0に則って製作していけばよいはず、というよりは、本来的には(特に公的機関などは)しなければならないはずです。しかし、WACG及びJIS 8341-3:2010の双方が参照すべきとする具体的な実装方法を説明した「WCAG 2.0 実装方法集」には、まだアクセシブルなEPUBの製作方法が掲載されていません(アクセシブルなPDFの作成方法はすでに掲載されている)。WACGの関連文書において、実装方法が具体的に示されない現時点では、WCAG2.0( = JIS X8341-3:2010)に則って作成せよと言われてもまだ難しいかもしれません。将来的には、「WCAG2.0 実装方法集」にEPUBの実装方法も掲載され、官公庁などが刊行物のEPUB版制作を外注する時にその仕様書に「JIS 8341-3:2010の達成等級AAを準拠すること」等々の一文を追加するだけで済むようになれば理想的ですが、少なくとも今はまだ存在しないため、電子書籍向けにブレークダウンしたものが必要です。

 EPUBについては、IDPFがアクセシビリティガイドラインを公開しています。EPUBについてもっともまとまったものだと思います。

 しかし、上のIDFPのガイドラインは各要件が平たく説明され、優先順位が示されている訳ではありません。優先順位はWCAG2.0( = JIS X8341-3:2010)の達成等級が参考になりますが、米国の出版団体 Association of American Publishers (AAP) が上のガイドラインの中で優先順位の高い要件13を挙げていますので、これも参考になると思います。

2. 電子書籍の「アクセシブルな閲覧環境」を示すビューワーのガイドライン

 閲覧環境についても、W3CのUser Agent Accessibility Guidelines(UAAG)2.0があります。これは上のコンテンツ作成ガイドラインであるWACG 2.0と対になっているようなもので、Web技術を用いて製作される電子書籍の閲覧環境も対象に対象になります。JIS規格どころかまだW3C勧告にもなっていませんが、参考になる部分が大きいはずです。

 米国の出版団体 Association of American Publishers (AAP) もEPUB 3 リーディングシステムに優先的に実装してもらいたい10の機能を公開しています。

 そして、DAISYコンソーシアムが電子書籍リーディングシステムのアクセシビリティを評価するためのチェックリストを公開しています。これについては、手前味噌ながら、私が翻訳して公開しています。

 最後に、これは本当に手前味噌ですが、EPUBの閲覧環境については、私も私案として要件をまとめてみたことがあります。これを、EPUBに限定しないように抽象化しつつ、優先順位の高い要件を3段階くらいでランク付けすれば、それなりにそれなりかも。

3. 「アクセシブルな提供方法」を示すコンテンツ提供ガイドライン

 これについては、参照するべきガイドラインは特に思いつきませんが、少なくとも以下の5点はポイントになるはずです。

  • 上の1と2のガイドラインを準拠すること
  • DRMが上の1と2のガイドラインの準拠を妨げないこと
  • アクセシビリティメタデータの提供(参考:メタデータを電子書籍のアクセシビリティの議論の俎上にそろそろのせませんか
  • 電子書籍プラットフォームのウェブサイトのウェブアクセシビリティをWCAG2.0( = JIS X8341-3:2010)に準拠する形で担保すること
  • ユーザービリティ(コンテンツ入手までの手順をなるべく少なくするなど)

 

関連エントリ

5月 27

アクセシブルな電子書籍とは何かを示すガイドラインを図書館側が作ってはどうか

 障害者差別解消法の施行まであと1年弱となりました。公共図書館向けのいろいろなサービスが障害差差別解消法の対応できる的なことを謳うようになると思いますが、電子書籍サービスもおそらくはその1つでしょう。

 個々の電子書籍ベンダの状況はよくわかりませんが、アクセシビリティ対応についてはベンダごとにそれぞれ重きを置くところがさまざまではないかと思います。「アクセシブルな電子書籍」と一言で言っても、図書館が考える「アクセシブルな電子書籍」とベンダ側(と出版社)が考えるそれが同じとは限らないため、図書館が考える「アクセシブルな電子書籍」が何かを明示する必要があるのではないかと考えています。利用者に対して直接サービスを提供する図書館側が考える「アクセシブルな電子書籍」の要件を整理して提示し、認識に齟齬が生じることを防ぐことが重要です。

 例えば、以下について要件の優先順位を示したガイドラインを提示することで、ベンダやコンテンツプロバイダが自分が提供するサービスやコンテンツが、客観的に自己評価でき、かつ、今後どのように改善していけばよいのか、その道筋を示すというのは一つの方法です。

  • (出版社と電子書籍プラットフォームに対して)図書館が考える「アクセシブルな電子書籍」とは何か。
  • (ビューワー開発者と電子書籍プラットフォームに対して)図書館が考える電子書籍の「アクセシブルな閲覧環境」とは何か。
  • (電子書籍プラットフォームに対して)図書館が考える電子書籍の「アクセシブルな提供方法」とは何か。

 この方法の大きな利点は、ベンダ側に要件を提示できるだけではなく、図書館側が電子書籍サービスの導入やコンテンツの購入に際して、これらを「障害差差別解消法の対応」という文言に左右されずに客観的に評価できることです。

 障害の状況は人によってそれぞれ異なりますので、全ての方が満足するものを提供することは困難です。ベンダが出してきたものに対して、問題点を指摘することは無論重要ですが、図書館側が考える「アクセシブルな電子書籍」を明示せずに、ベンダが問題を指摘され続けるという状況は、ベンダにとっては、ゴールが見えないため、やる気を削ぐ可能性もあり、あまり望ましいことではありません。

 そこで、ガイドライン的なものを提示することで、だれもがサービスやコンテンツを客観的に評価でき、問題点を顕在化できるようにする。そして、現実的に実装できる道筋を示す。ベンダ側も全ての要件を一気に満たすことは難しくても、道筋が示されれば、優先順位の高い要件から「合理的配慮」の範囲内で少しずつ実装してくれるかもしれない。企業全体としてその気はなくても、内部の人がやる気を出して可能な範囲で少しずつ改善してくれるかもしれないし、あるいは、ガイドラインによる客観的な評価をもって、上を説得するようになるかもしれない。後半は希望的観測もありますが、ガイドラインのあり方は、ウェブアクセシビリティガイドラインで知られるW3CのWCAG2.0( = JIS X8341-3:2010)はロールモデルになるものだと思います。

 利用者に接してサービスを提供する図書館は、障害者のニーズをくみ上げて出版社やベンダーに「アクセシブルな電子書籍」とは何かを伝えることができるし、その役割を果たすことでアクセシブルな電子書籍の普及に貢献することができるはずです。

 要件を整理してガイドラインを作成するということは、関係者間で「アクセシブルな電子書籍」の認識を一致させる必要がまずはあり、相当大変なことだ思いますが、それは必要な調整ではないかととも思います。

 私が図書館側の人間なので、今回は「図書館」を中心に述べてきましたが、視覚障害者情報提供施設(いわゆる、点字図書館)に置き換えても同じことが言えるはずです。立場としては図書館と点字図書館は同じであるはずですので、連携して取り組めればよいかもしれません。米国のEPUB 3 Implementation Projectが出版社、リーディングシステム開発者、コンテンツ販売者、サービスプロバイダ、そして、アクセシビリティ関係のコミュニティが集まって要件を整理したように、日本でももっと広いくくりで領域をまたいでこういうものが作れると本当はもっとよいのでしょうか。

関連エントリ