9月 29

W3C Publishing Working Groupで軽量SMIL(次世代SMIL?)について議論始まる

 W3CのPublishing Working Group の2017年9月18日の電話会議で、SMIL lite(軽量のSMIL)が(おそらく)始めて議論されています。先のエントリで紹介したWeb Pulications
での利用が想定されています。Web Pulications はEPUBと統合されて、EPUB4的な立ち位置になる可能性も示唆されているので、次世代SMILといえる立ち位置になりうるのかもしれません。まだ、議論は始まったばかりのようで、どこに向かうのかはわかりませんが。

 要件リストは、Essential Requirements(不可欠な要件)とAdvanced Requirements(高度な要件)にわけて整理されています。Essential Requirements はざっと見た感じ、現行のEPUB3ですでに実現できていることが並んでいるようですが、Advanced Requirements では、現行のEPUBでは実現できていない手話動画とテキストの同期も想定した動画のサポートや、音声解説を付けた動画のサポートが挙げられています。

 議事録を読むと、SMIL lite は XMLではなく、JSON で行く可能性が今のところ高そうですね。 

 なお、SMIL (Synchronized Multimedia Integration Language) は、DAISY や EPUB 3 では、テキストと音声の同期あるいは音声(録音音声またはTTSによる読み上げ)の再生の制御のために使用されています。現行の EPUB 3 におけるSMILのサポートは音声に限定されていますが、聴覚障害者のために手話動画とテキストを同期させたEPUBを作るため、動画のサポートが EPUB 3 仕様策定の段階から要望としてあがっていたようです。そういう経緯があったためか、EPUB Media Overlays 3.0の仕様では、動画をサポートしないことがわざわざ言及されています(最新の EPUB 3.1 でも同じです)。今回の SMIL lite の議論もこの経緯を受けてということだと思われます。

Although future versions of this specification might incorporate support for video media (e.g., synchronized text/sign-language books), this version supports only synchronizing audio media with the EPUB Content Document.

 

 最後に議事録からSMIL lite に関係するところを転載します(ここでも河村宏さんの名前が…)。

1. Requirement for SMIL Lite

Garth Conboy: “SMIL lite” == “grin”

Tzviya Siegman: https://github.com/w3c/publ-wg/wiki/Requirements-and-design-options-for-synchronized-multimedia
Marisa DeMeglio: link in GotoChat
… we’ve been looking at design reqs for syncronized multimedia

Rachel Comerford: https://github.com/w3c/publ-wg/wiki/Requirements-and-design-options-for-synchronized-multimedia

Marisa DeMeglio: allowing talking books to talk

Tzviya Siegman: can you give a quick overview?

Marisa DeMeglio: EPUB3 didn’t have a lot of problems with media overlays
… we can look at something lighter than SMIL
… we used a slim subset in EPUB3
… but SMIL adoption in the world at large hasn’t been huge
… so we can look at other formats
… we do need to link chunks of text with chunks of audio
… you still need structural semantics for navigation etc
… making video + text transcripts more accessible is a requirement
… and there are some things not included in media overlays
… I’ve been emailing with dweck
… like having multiple granularities of navigation–from para by para to word by word
… text + sign language
… video + descriptive audio
… all those are not covered by media overlays
… our next step is deciding what format to do

Garth Conboy: That multi-resolution MO approach was discussed some years ago, and I think prototyped in Readium, I think. It’s a cool idea.

Marisa DeMeglio: first question is about formats–XML or not XML

Dave Cramer: what’s the status of audio sync on the web at large?

Marisa DeMeglio: I don’t know of anything

Ivan Herman: I don’t know much more
… I love your understatement… SMIL adoption is terrible
… we will have to define a SMIL-lite which has any hope for implementation

Bill Kasdorf: is there an active SMIL WG?

Ivan Herman: we will also have to ensure there will be several implementations on top of browsers

Laurent Le Meur: I agree with Ivan when he says we’ll have to create polyfills
… if this is the case, if JS is the language that will use SMIL, then XML is not the best structure for that
… JSON has the lead, a structure JS loves
… SMIL is so complex, there are too many features
… we can track as JSON structure

Garth Conboy: Marisa is also correct, when saying MO/SMIL(lite) adoption in EPUB Reading Systems is pretty good.

Laurent Le Meur: as for the requirements, we should make sure the structure we define doesn’t prevent us from adding advanced features later

Ric Wright: one other area is where there is a SMIL implemenation is for animation of SVG
… this has been implemented by browsers

Avneesh Singh: the main objective of this work was lack of support of SMIL on the web
… and then additional things came up
… that were not covered in EPUB3 MO
… media fragments is the one thing in the web which is used
… if we can find out groups in web who are trying to solve similar problems
… we can try to do it together

Charles LaPierre: ETS and Mark Hakkinen has done lots of work with SMIL
… they might have some insight
… they use this for assessments

Tzviya Siegman: the larger group should comment about requirements
… this is not part of our charter… so what should we do with these requirements? What are next steps?

Ivan Herman: as usual, this was the topic I wanted to put on the queue
… that’s an admin problem
… this whole issue of SMIL lite is not in our charter, but is a necessary thing
… this would be rec-track work
… the traditional way to do something like this would be to form a separate CG
… that would look at an initial spec plus one or two polyfills, showing it is possible
… once the CG says we have this, it solves these requirements, it’s polyfilled, it has users
… the most obvious way would be to then form a new WG

Garth Conboy: From charter: “This specification should generally be a functional superset of EPUB 3.1. Functional round-tripping to/from EPUB 3.1 considered highly desirable.” So, would could argue it’s kinda in our charter, as it’s in EPUB 3.1.

Ivan Herman: I still believe something like SMIL is still necessary for the web, and not only for WP
… even if WP is driving this here
… the web in general would benefit
… we then could get experts from other places for a CG
… I have some colleagues in Amsterdam who worked on original SMIL
… some of them are still around; I can approach them
… but a WG would be too much for them

Tzviya Siegman: the next steps are to clean up requirements and share them
… we should pass this on to APA, and share with Janina

Ivan Herman: there are some other media-related groups, like a video group
… they might have feedback
… and outside w3c there are other groups

Marisa DeMeglio: to comment on SMIL
… DAISY was in smil WG
… we used SMIL more than anyone else, but used less of it
… our use case was really different from everyone else’s
… they used it for short presos, annotations, etc.
… we used for entire books
… I’m not sure that reawakening the SMIL group would be good
… we might look elsewhere for overlap

Ivan Herman: it’s going to be very light, very concentrated

Tzviya Siegman: it might come down to how you position it
… I can help with that

Avneesh Singh: that’s a valid point from marisa_demeglio
… we need more strength to make it an implementable standard
… we need to strike a balance for something useful for our requirements as well as for others
… that IPTV was looking for something like SMIL
… Hiroshi can be a liason
… and Mark H can also help

Tzviya Siegman: we have people volunteering to be liasons
… joanie might know who to talk about at the browsers

Avneesh Singh: I will contact Mark Hakkinen and Hiroshi Kawamura

Bill Kasdorf: I was going to ask Marisa if there is a link she can share that documents the subset of SMIL that is actually used by DAISY

Marisa DeMeglio: bill_kasdorf: http://www.idpf.org/epub/31/spec/epub-mediaoverlays.html#sec-overlays-def

Bill Kasdorf: marisa: thanks, I didn’t realize that the MO spec in EPUB 3.1 was the subset you were talking about. That’s great to know because that is what folks are actually using in the publishing world.

9月 24

WebとEPUB(そして、その先にある出版)を繋ぐものとなるか、”Web Publications” #html5jpub

 2017年9月24日に開催されるHTML5カンファレンスのセッションの1つ、html5j 電子出版部セッションにパネリストの1人として登壇させていただくことになりました。

 このセッションのテーマは、端的に言うとW3Cで議論されている”Web Publications(以下、WP)”という仕様をテーマにしています。これについては、セッションに先立って公開されている村上真雄さんの以下のスライドに詳しいのですが、私の理解では、いろいろな意味で、WebとEPUBの間を繋ぐ役割を果たすものではないかと思います。

 

 WPの特徴は、htmlファイルなどをとりまとめる役割を果たす、EPUBで言うところのOPFファイルに相当する「マニフェスト」と呼ばれるファイルを持つことで、これにWPに関するメタデータを持たせたり、読む順序(htmlを表示する順序)の情報を持たせることで、wpを複数のhtmlを1つのコンテンツのようにあつかうことができるようになるようです。EPUBを簡易にしたような仕様のように思えます。

 仕様はまだ定まっていないので、はっきりとしたことはいえないところがありますが、一番シンプルなパターンがおそらく以下のようなパターンで、画像はもちろん、Webと同じような方法で動画、音声も扱えたりするのでしょう。逆に言えば、EPUBで扱えるSMILは扱えるのかな(難しいか・・)

manifest(表示する順序の情報やメタデータを持つ)
├-html1
├-html2
├-html3
(中略)
└html10

 
 EPUBと違い、スクリプトの使用におそらくは制限はなく、閲覧環境はウェブブラウザになると思うので、EPUBではできないようなインタラクティブなコンテンツ、動的なコンテンツ、APIを叩くようなコンテンツもつくれルのではないかと思うので、ウェブサイトをそのままWP化することもできるはず。

 オンライン上に展開されているWPを利用することはもちろん、オフラインでWPを利用することも想定されているようです。

図の説明はキャプションの後の本文にあり
“Accessing a Portable Web Publication in packed state from the Web via a Service Worker.” from Portable Web Publications for the Open Web Platform (W3C First Public Working Draft 15 October 2015)
 上の図は、オフラインでのWPの利用を示した図で、Webにアクセスできる環境にあるときに必要に応じてService Workerでサーバーに接続してラップトップコンピューターがウェブブラウザ上でWPを取得(更新?)してキャッシュすることを示している(らしい)。

 EPUB寄りの目線でみれば、オンラインで利用されることが想定されていることが「へぇ」ポイントかもしれない。ここはWeb寄りの立場で見るか、EPUB寄りの立場で見るかで、WPのどこに「へぇ」するかは違うのかもしれない。

図の説明はキャプションの後の本文にあり。
“Accessing a Portable Web Publication in an unpacked state directly from the Web. ” from Portable Web Publications for the Open Web Platform (W3C First Public Working Draft 15 October 2015)
 上の図はHTTPリクエストでサーバーに接続してラップトップコンピューターがウェブブラウザからパッケージされていないWPを取得する図。普通にWebにアクセスするのと同じということでしょうか。

 ページネーションや目次などのナビゲーションや閲覧環境も電子書籍のUIを取り入れたものが構想されているようです(しかも、ブラウザ上で)。理想的にいくならば、WebのよいところとEPUBのよいところをそれぞれ取り入れたものになりそうですし、WPがWebとEPUBを橋渡しすることで、WebやEPUBにもお互いの長所を取り入れる効果が期待できるような気がする。UIについては、以下で書いたこともありますが。電子書籍のリーディングシステムとWebブラウザが相互に影響しあって、それぞれのUIのよいところをとりいれるとよいと思う。

 パッケージングして、1つのファイルにできるようになることも想定されていて、その場合は、Packaged Web Publications(PWP)と呼ばれるようです。パッケージングの仕様は方向性がよくわかりませんが、オフラインで利用したり、持ち運んだりする場合は、1つのファイルとして扱えることが必須なような気がします。

図の説明はキャプションのあとの本文にあり
“The same content can be turned into an archived file and back without any inherent changes to the core content or associated digital assets” from Portable Web Publications for the Open Web Platform (W3C First Public Working Draft 15 October 2015)
上の図は、同じコンテンツがコンテンツのコアな部分の変更を伴わずにオフライン、オンライン両方で利用できることを示した図。スマートフォンがパッケージされて1つのアーカイブファイルをオフラインで利用し、ラップトップコンピューターがパッケージされずに展開されたWPをオンラインで利用している。

 W3Cのドキュメントを読むと、WPがフォローする範囲といいますか、想定されるユースケースはかなり広いようで、Web寄りの立場から見れば、オフラインでも読めるWebという見方もできそうですし、EPUB寄り、出版寄りの立場から見れば、EPUBにちかいもの、しかし、EPUBよりも自由度の高い出版物と見えるような気がする。立ち位置によってだいぶWPも違うものに見えるかもしれない。Webと出版を両端におくとするなら、私のイメージは以下の図のような感じで、WebとEPUBに若干重なりながら、webとEPUBの間に立つ立ち位置のように思えます。立ち位置によって全く違うものに見えるかもしれない。

Webと出版を両端において、WPの位置づけを示した図。Webが左、出版が右端にあり、出版のすぐそばにEPUBがあり、EPUBとWebの少し間のあるところにWPがEPUBとwebに重なりつつ置かれています

 EPUBは仕様上、長さに上限も下限もありませんが、現状、Amazonのような書店で販売され、紙版と並行して出されるコンテンツが圧倒的に多い気がします。その意味では、EPUBのコンテンツの長さやンテンツのあり方は、今のところ紙の出版物に規定されている(されてしまっている?かもしれない?)(もちろんEPUB全てがそうというわけではありません)。

 WPはおそらく紙の出版物(少なくも図書)の代替として出されることは、主なユースケースにならないのではという気もしています。Webよりも長く、本より短いサイズのコンテンツに向いているものかもしれない。2011年に以下のようなエントリを書いたことがありますが、WPに該当する部分があるかもしれない(、これも今読み返すとだいぶ外れているのですが)。

 ビジネスモデル、というべきなのか、分かりませんが、制作者からどのような過程を経て、WPがユーザーの手に渡るのかという点も気になります。電子書籍に以下の図のようにプラットーフォームごとにコンテンツへのリーチから、DRM、課金、アノテーション、リーディングシステムまで囲い込む垂直統合型が基本になっています。垂直統合型が悪いというわけではないのですが、それだけだと、ユーザー側の選択肢が狭められてしまうので、可能な部分をプラットフォームの機能をレイヤーごとに分けて水平分業型にできないかと考えたこともありますが、

プラットフォーマーがアカウント、リーチ(検索)、DRM、課金、アノテーション、リーディングシステムをそれぞれで抱えている図

Webと親和性が高そうなWPは、おそらくWebに準じた水平分業型に近いものになるのではないか。電子書籍領域のそばに水平分業型のWPというコンテンツがドンと出てくることで、以下の図にあるように水平に伸びてくるレイヤーが電子書籍から出てくるかもしれない。

左端にWeb、右端に電子書籍、中央にWPがある横軸の図で、アカウント、リーチ(検索)、DRM、課金、アノテーション、リーディングシステムの各レイヤーが並んでいる図。webはリーチ、アノテーション、ブラウザのレイヤーを有している(アカウント、DRM、課金レイヤーはない)。最も右端の電子書籍部分はプラットフォーマーが全てのレイヤーを独自に囲い込んでいるが、中央に近づくと、一部のレイヤー(リーチ、アノテーション、DRM、リーディングシステム)を他の電子書籍プラットフォーマーと共有したり、WPともレイヤー(リーチ、アノテーションなど)を共有している。中間にあるWPはWebよりな位置ではWebと同じレイヤー構造で、電子書籍よりの位置では、アノテーションや課金は電子書籍とレイヤーを共有している。

アクセシビリティの観点からいえば、自分の使いやすいリーディングシステムは人によって異なるので、プラットフォーム側に使用するリーディングシステムを固定されない方が望ましい。自分の使いやすいリーディングシステムやブラウザで複数のプラットフォームのコンテンツやWPが使えるようになるとよいなぁと思ったりする(ちなみに以下の図で複数で共有されているリーディングシステムレイヤーは1つのリーディングシステムで複数のプラットフォームを共有するということではなく、利用者にとって使いやすいリーディングシステムで複数のプラットフォームを利用できるということを示している)。

 2012年にも以下のエントリを書いたことがあります。今、改めて読み返すとこれはこれで結構ツッコミどころが多いのですが、WPの目指すところはこれに近いイメージはあるかもしれないとも感じています。

 PWPは、次世代のEPUBになる可能性もあるようです。WPとEPUBよりは、WPとWebのほうが親和性が高いように思えるので、WPとEPUBが統合したら、出版とWebの融合もかなり進むのではないかという気がする(しかし、その場合、EPUB3とだいぶ異なる仕様になるので、後方互換性は大丈夫かという懸念も)。

 思いつくところをいろいろと書きましたが、さあ、どうなるのでしょうか。WPのアクセシビリティはどうなるか、という点も気になるところ。

参考ドキュメント

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