音声ブラウザご使用の方向け: ナビメニューを飛ばして本文へ ナビメニューへ

講演「EPUB3.1規格の開発とアクセシブルな電子出版の推進」

 

JEPA CTO 村田 真

 

slide1

(スライド1 テキスト)

<村田> こんにちは。村田です。聞こえますか?
 EPUB3.1規格の開発とアクセシブルな電子出版の推進という題で発表します。JEPAのCTOとしてEPUB3.0からずっとEPUBの制定にかかわっています。特に国際化に関してリーダーシップを取りました。 今日はお伺いしないといけないところインフルエンザにかかってしまい、スカイプで申し訳ありません。

 次のスライドをお願いします。

slide2

(スライド2 テキスト)

 まず経緯と現状認識ですね。
 EPUB3はDAISY4の配布フォーマットだと理解しています、だいたい。私はこれをジョージカーシャーと話したのですけれど、EPUB2の時には一部のものがアクセシブルだったのですが、EPUB3ではそうじゃなくて、すべてをアクセシブルにしようと。要するに、ジョージが言うには一部のものだけアクセシブルにするんじゃだめだ。普通なものがアクセシブルにならないとみんなhappyにならない。そういう風に彼は言っていました。それからすでに数年がたったわけです。EPUB3ができて。
 今、悲観的に見るとEPUB3は残念ながらアクセシビリティを必要とする人の役に立っているとは言えないですね。特に日本では。それで、もっというとアクセシビリティ関係者が一生けん命仕様の制定とか実装して、それを電子書籍のビジネスをやっている人が金儲けのために使っている。そう意味で尊い善意が一部の人の金儲けのために使われているということがないわけではないです。まあそれはあまり好ましいことではない。
 でも一方、楽観的に考えると、そもそも普通のものをアクセシブルにすることはそんなに簡単に実現できることではないんですね。それはなんでも当たり前です。そして今、DAISY関係者がEPUB checkというEPUB文書のチェッカーをつくっています。これは先ほども申し上げました通り、普通の電子書籍はみんな使っているんですね。それを通らないものは出さない。どこもそうなっています。それは電子書籍のアクセシビリティが少しずつだけど整備されていて、それがチェックされている、そういうことを意味するわけですね。
 みんなの目に見える形にはまだ残念ながらなっていないかもしれないけれどEPUBが少しずつアクセシブルであることが保障されるようになってきている。

 EPUB testというサイトがあります。そのサイトをクリックしてください。
http://epubtest.org/testsuite/accessibility/
これはアメリカのBISGという団体がいろんな閲覧システムに対して、アクセシビリティを評価しています。見てみると0パーセントというものもあるけれど100%というものもある。Readiumなんかは良い方です。voice dream reader、これも良い方です。
 私の感覚ですが、おそらくアメリカのほうがアクセシブルなリーダーが普及していると思います。日本はあんまりですよね。残念ですが。でも確実にリーダーはアクセシブルになりつつあると私は思っています。そういう意味で理想は大きく、それで悲観的な話もいっぱいあるけど、楽観的にみるとEPUB文書はみんなEPUB checkでデイジー関係者のつくったプログラムでチェックされるし、少しずつアクセシブルなシステムができていると。おそらく、日本では残念ながらアクセシブルな閲覧システムはでてないと思うんですけれども。少しずつ状況はよくなっていると思います。

 次のページお願いします。

slide3

(スライド3 テキスト)

 仕様が普及するには仕様制定だけでなく、実装もあり、利用者があり、みんなが合意しないと進んでいかないと普及しないんですね。仕様制定が先走っても、実装されない、利用者に使ってもらえない、そういうことになります。仕様制定では進んでいるけれども実装や利用者のほうが遅れている。それは仕方がないのかなと思います。みなさんが実装や利用者のほうでは私よりも皆さんの力のほうがが大事なんじゃないかと思ってます。私は仕様制定担当ですから。

 次のページお願いします。

slide4

(スライド4 テキスト)

 EPUB仕様の現状と将来です。
 EPUB3が2011年の11月にできました。EPUB3.0.1が2014年にできた。この時に、固定レイアウト、漫画とか、絵本とか、料理のレシピ、そう言うものが入ったわけです。
 そしてEPUB3は、ISO/IECの方に持ってこられて、技術仕様になりました。これは、ISO/IECは何の威力もないかというと、そういうことはなくて、特に政府の調達、教科書の調達などで使う時には、やはり、IDPFのようなフォーラム水準じゃなくて、ISOやIECで何らかのお墨付きを得ることが、非常に重要なんですね。それで韓国は、このISO/IEC技術仕様書制定に、非常に熱心でして、韓国から提案するという形をとって、技術仕様にしました。今度3.0.1も同じようにするはずです。
 次はEPUB3.1ですけど、今度は国際規格にしようと。今まで技術仕様だったんですけど、今度は国際規格にしようと。そういう夢を持ってます。当然国際規格になった方が、教育なんかで使っていく上では便利なんですね。逆に言うと、適当な拡張はしてくれるなと。
実は3.0.1から3.1の間に、いくつかの拡張モジュールが作られました。それは、辞書と索引であったり、複数レンディションであったり、プレビューであったり、マンガのコマ単位遷移、注釈 、いろんなものがあるんですけど、残念ながらこれは3.1では入れないってことになりました。まだモジュールとしての成熟を待ってから入れようと。仕様はそもそもちゃんと書かれたものがあるんですけれども、残念ながらそれがまだ使われていない。
 固定レイアウトも、モジュールとして始まったんですが、3.0.1で組み込まれたんですね。それは非常に使われたから。残念ながら他の拡張モジュールに関しては、そこまで使われてはいないので、残念ながら3.1では入りませんでした。今後の成熟待ちだと思います。

slide5

(スライド5 テキスト)

 次に、ISO/IECにおけるEPUB。
 ちなみに韓国は、韓国の国家規格にして、それから、ISOに提出という道を取りました。日本では、EPUBはJISにも何にもなっていませんけれども、国際規格になればそれでいいかなと言うところですね。

slide6

(スライド6 テキスト)

 次に、EPUB3.1を構成する、いろいろなサブグループ。
 10ほどのサブグループがあって、その中でいろいろなことが検討されています。全部をカバーすることは、今日は当然できませんけれども、細かすぎますからね、いっぱいありますから。今日はこの中で、主にアクセシビリティに関係するものだけをご説明したいと思います。

slide7

(スライド7 テキスト)

 まず、つい先日、1月の末に、EPUB3.1の最初のドラフトが出たんですね。文句があるなら急いで言ってくれというものです。つまり、最終決定をしたわけではない。特に、いろんなものを落とすから、いろんな機能を落とすから、それに対して文句があるなら言ってくれと、そういうものです。逆に追加部分については、必ずしもまだ入ってません。つまり、これとこれを落とすからいいですか?というのを聞いてるのであって、これを追加するからいいですか?というのは、まだそこまで行っていません。
 では、まず最初に落とすものとして、NCXの削除。NCXはDAISY関係者は当然なじみの深いものでしょうけれど、このEPUB3.1では落として、ナビデーションドキュメントに一本化しようと、そういう方針になっています。ナビゲーションドキュメントは当然ルビも入りますし、もうこれ、二つあるとたまらんと、出版社からすると。NCXとナビゲーションドキュメントの両方を、全く同じように保つのは大変だと。片一方だけにしてくれと。NCXの削除は、特に、Hachetteによって提案されています。

 次に、epub:type属性、これは、EPUBのstructural semantics、DAISY関係者の方には当然おなじみかと思いますけど、それでずっと用いられたものですね。
 ところがこれは、XML構文のHTMLでは使えるんですけれども、HTML構文のHTMLファイルでは使えない。そこで、ARIAのrile属性へ移行しようと。そういう話が進んでいます。あと、WAI-ARIAモジュールを追加しようと。それから、適合要件として、WCAG2.0のレベルAAにHTMLおよびSVGが適合することを追加しようと、要件として。前は、スキームそのものだけが入っていたんですけど、今度は、HTMLとSVGもこれに適合することを要求することになりました。
 最初のドラフトではこれくらいしか入ってなくて、嬉しい話はほとんどないですね。ARIAが入る、WCAG2.0に適合する、それだけであって、後は別に嬉しくもなんともない。

slide8

(スライド8 テキスト)

 では、先送りされたものはなにか。
 まず、メタデータですね。メディアオーバーレイのためのメタデータ。このEPUBメディアオーバーレイのファイルは、テキストは全部あるんだけど、オーディオは一部しかない。逆にオーディオは全部あるんだけれども、テキストはほんの一部しかない。そういう区別を、メタデータで表現できるようにしようと。これが進んでいます。これまではダウンロードしてみないと分からなかったんですけれども、これからは、ダウンロードする前に、メタデータを見るだけで分かる。
 次に、アクセシブルな出版物であることを示す証明書を入れようと。これはまだ仕様書に書いてあるだけで、どんな形で入るか、あきらめられるかもしれませんけど、そう言う証明書を入れたいと。それを証明してくれる人はだれなんだろうとか、いろいろ問題ありますけど、希望としては証明書を入れたいと。
 それから、点字の言語を表わすメタデータですね。点字は、コードポイントとしては、全ての言語で共通になっていて、点字のコードポイント見ただけじゃ、それをどの自然言語に変えたら良いか分からない。それで、メタデータを入れて、この点字は何語なんだろうというのが分かるようにしようということです。これも当然ダウンロードする前に分かる。表示、つまりレンダリングするときにも、言語が分かっていると、うんと楽になるかもしれません。
 先程、NCXを落とすと言いました。じゃあNCXでできることが全部EPUBのnavigation documentでできるかというと、実はできないことがあります。NCXにはラベルというものがあって、それが、EPUBのnavigation documentsにはない。これを追加しようと言う話になっています。
 あとオーディオのプロファイルですね。アクセシビリティを重視した、オーディオのプロファイルを作ろうと。
 あとの2つは私がイシューを追加したものですが、まず、一番下のものは、ルビなし/ルビあり/総ルビの区別を示すメタデータ 。このメタデータを見るだけで、ルビがあるのかないのか、総ルビなのか、それが分かるようにしようと。
 もうひとつは、音声読み上げエンジンを必要とする自然言語 を最初に分かるようにしたいと。音声読み上げを、例えば日本語と中国語で必要だと。それを、文章の途中でなくて先頭を見ればわかるようにしたいと。そして、先頭を見るだけで、日本語の音声読み上げエンジンと中国語の音声読み上げエンジンを起動してしまいたい。文章を読んでいる途中で起動するのではなくて。そういうお話です。
 いろいろいいましたけど、これらが全部入るかどうかは分かりません。今のはだいたいメタデータで、つまり文章中に入っているデータを見れば分かることなんですね。ルビなしなのか、ルビあるなのか、総ルビなのかというのは、当然文書の中を全部見れば分かる。音声読み上げエンジンを必要とする自然言語が何かというのも、当然文書を全部なめれば分かる。最初のメディアオーバーレイのためのメタデータに関しても、文書を全部なめれば分かる。そういうものはない方がいいという意見もあるんですね。つまり、メタデータが間違っている可能性が高まるから、そんなものはない方がいいと、そういう意見もあります。これはどうなるか分かりません。
 みなさんはどう思いますか?ルビなし/ルビあり/総ルビの区別を示すメタデータ 。これ絶対欲しいと言う人何人くらいいますか?会場で。
<会場から>参加者90名中、あった方が言い方が、12名、いらないという方が、1名。

<村田>じゃあ、最初のメディアオーバーレイのためのメタデータ。これが欲しいと言う方は、会場にどれくらいいますか?
<会場から>欲しい人が23人、いらないと言う人が1人

<村田>じゃあ、最後から二番目の、音声読み上げエンジンを必要とする自然言語、これをメタデータで示すべきだと思う人。
<会場から>必要だと思う人が24人

<村田>ちなみに、私はこれはダメかなと考えています。Matt Garrishに反対されちゃったので。やってはみますが。ちなみに、日本語と中国語の本でも、日本語の部分はオーディオが入っていないけど、中国語の部分はすべてオーディオが入っているということはありえます。つまり、音声読み上げエンジンに関しては、この本は日本語と中国語の両方を使ってるんだけど、音声読み上げに関しては中国語はいらないと、日本語しかいらないと、そう言うことはあります。これは、そこまで区別しようと言う話なんですね。もともと、文章中にどの言語が入ってるかっていうのは、示す情報があるんです。dc:language という。今言っているのは、更に、音声が録音されているかいないかまで区別して入れようじゃないかということです。これはかなりハードルが高いですね。

slide9

(スライド9 テキスト)

 次ですが、今、いくつか、メタデータと言いました。最近、このメタデータをどうするかと言うことに関しては、schema.org 、それをメタデータに入れようとか、IMS Global Learning Consortiumをメタデータに入れるという話が非常に多いです。前は、もっと別のが、ONIXとか、Dublin coreとか有力だったんですけど、最近は、schema.orgとか、IMS Global Learning Consortiumが有力になっています。schema.orgが有力なのは当たり前で、ブラウザをやってる会社がみんなこれやってるから、非常に多く使われていますね。ブラウザの検索エンジンがやってるわけですから。
 では、IMS Global Learning Consortiumっていうのは何かと言うと、これ、教育のための仕様をつくる団体です。今度日本事務所ができます。その中に、IMS Global Access for All (AfA) Personal Needs & Preferences (PNP) Specification Information Model Version 3.0というものがあるんですね。このIMSは、非常に、教育系のメタデータをいっぱいやっています。いろんな団体がアクセシビリティのメタデータの仕様を制定して、どれも使われていない、もうひとつ、と、そういう話もあります。そういう傾向がないわけではないですけど、教育系の仕様としては、これぐらいしかないんじゃないかなと思いますね。 リンクをたどってみてください。
(https://www.imsglobal.org/accessibility/afav3p0pd/AfA3p0_PNPinfoModel_v1p0pd.html)
Access for All、AfAといいます。個々の人に対するニーズ、もしくは、好ましい形で設定できるようにする、information modelをいれて、いろいろやってますね。
 下のメタデータを見てみましょう。AccessModelRequiredというのが3.1にありますね。visualとtextual、どれが必要か、この文書に関しては、visualだけなのか、それともtextualでいいのか。
3.1 AccessModeRequired Attribute Descriptionの、Notesのところ。
accessModeRequired.existingAccessMode = visual
accessModeRequired .adaptationRequest = textual
expresses this statement: “Resources that are visual should be replaced by an adaptation that is textual.”
Visualなものなんだけど、なんとかtextとして表示してくれと。そういうお話ですよね。
このメタデータは、preferenceに入る設定と、contentsに入る設定と、両方ありますんで。

 その次にAdaptationTypeRequired。
 延々といっぱいあります。3.4 は、EducationalComplexityOfAdaptation。どこまでむずかしいのか。3.6は自然言語ですね。3.10はメディア。NIMASはアクセシビリティの仕様ですよね。
 このような教育のメタデータの仕様があって、これを、EPUBではわりと意識しています。schema.orgでは足りないところがあるので、こちらを使おうかと。今後これが重要になるのかなという気がしています。少なくとも見るだけは見ておかないといけないかなと。ちょっと多すぎるので、この中から抜いて使うような気もするんですけど。割とIMSの仕様と言うのは、非常に分厚くて、永遠とページ数があって、何があったかなという傾向があるんですね。IMSに関する仕様も、これ一つではなくて、いくつかあるんです。それを全部見ないといけないんで、大変だな、というのはありますけど。でもAccess for Allというのはどうも無視できないもののようです。

slide10

(スライド10 テキスト)

 では次に、ところで、複数レンディション、一つのEPUB出版物の中に、例えば点字と普通のテキストとの両方を入れて、ユーザーのどちらが欲しいかによって切り替える。それは、EPUBの拡張モジュールとしてできてるんですね。これは私は3.1に入るかなと思って期待してたんですけど、すべての拡張モジュールは入れないことになりました。他にも辞書とか索引とかいっぱいあるんですけど、そういうものをすべて入れない。理由は、まだ十分に成熟とは言えないからだ。実装に使われないといけないから。
 前回、入れたのは、漫画とか料理本、固定レイアウトですね。あの時は非常に多く使われていて、そこまで使われているかっていうと、残念ながらそこまで使われていません。まだまだ、ちょろちょろっと実装がある程度です。どの拡張モジュールについても、それが言えます。そういう意味で仕方がないかなと思います。今後の成熟を待ちたいというところです。
 でもじゃあ、EPUB3.1の一部として予定されているものに、成熟してない拡張がないかっていうと実は結構あるんですけど、そういうもので、今までできているモジュールを落とすのであれば、そういう、野心的な拡張はやめてよって私は思うんですけどね。具体的に言うと、zipをやめてXMLをやめようというEPUB webという技術が相当します。

slide11

(スライド11 テキスト)

 次のページは、もう少し複数レンディションに関して説明したものです。
 一つのEPUBファイル中に、等価ないくつかの表現を入れて、実行時に選択させる。高解像度と低解像度であったり、日本語と英語であったり、画像とHTMLであったり、点字であったり。
 EPUB3.1の中でアクセシビリティの話をすると、だいたいこういうところになるんですね。そういう意味ではメタデータが中心であって、コンテンツの中の話はあまりないです。NCXのラベルが入る話し。あとはだいたいメタデータですね。コンテンツに対する、アクセシビリティはだいたい済んでるよな、という話もあります。最近、SSMLをHTML文書に埋め込むと汚くなるから、外出しできるようにしてくれと、そう言われる方がいます。河村さんにもいってますよね?どう思います?

<河村>今朝来たんで、あんまりまだ良く読んでないんですけど、全部にSSMLを入れていくということ自体が、ちょっとどうなのかなという風に。そこのところで、まだちょっと、本当にそれが必要っていうか、メリットが何かというのが気になっているのと、そもそも、書いて定義するほどの、確実な正しい読みというのが、本当に定義できるんだろうかと、人が話しているものってある一定の幅がありますよね。だからまあその幅の中ならまあ許容されるというのが、自然言語の音声だと思うんですけど、それを書いてしまうと、今度固定されるんで、非常に幅が狭くなって、これは正しい、これは正しくないというレベルのものになってしまわないかと。そこが、本当に実用的なのかどうかっていう点がどういう風に検証されるのかなと、もう少しお話を聞きたいという風に思っています。
<村田>分かりました。もし必要だったら言ってください。そしたらがんばりますけど。そうでなければあきらめます。

<河村>もうひとつはですね、メリットとして、サイズが小さくなる、というのが、ほとんど唯一のメリットとして挙げられていたと思うんですね。人間の音声と対比して、人間のと言うか、今作っている音声と同期させるのとの比較で、全部SSMLで書いてしまえば、サイズが小さくなると言うのが、唯一のメリットとして私には読み取れたので、そこのメリットを出すためにそれだけの労力をかけ、あるいは、先ほど言ったエビデンスを作るということに、そんな優先順位が高いのかな?というのが正直言って、私から言わせるともうちょっと他に先にやることがありそうな感じがしています。
<村田>JIS X0213にない文字、そういうものは、現在の日本語の音声エンジンは一切対応してないから、それはSSMLでやるしかないと。それはそうかもしれないけど、213でしかないものなんていうのは本当に知れてるわけですよ。一つの文章中に。それを全部振ったとしても本当に知れていて、すべての文章に振るなんていうことは全然違う。そういう意味でどうなのかなという気持ちは私もあります。
 あと私の理解ですけど、SMILっていうのは残念ながら実装が追い付かなかった仕様ですよね。非常に大きい仕様で。SMIL3なんか。そういう意味で、大きい仕様を作ったけど、普及しなかったと。そういう反省があって、メディアオーバーレイが非常に刈り込んだ仕様になったと思っています。せっかく刈り込んだのにまた増やすのかと。そういう反応は当然出ると思います。 まだ議論待ちですが、ちょっとあんまりポジティブじゃないですよね。

<河村>もう少し十分ご意見と背景は良くうかがってから、考えたいと、会場のみなさんもいろんなご意見あると思いますので、もう少しよく議論が必要だと思っています。
<村田>さっき河村さん、メディアオーバーレイのためのメタデータいらないって言いましたよね。オーディオブックと、テキストは全部あるけどオーディオが一部しかない、そういうものを区別するためのメタデータはいらないと、それは何ですか?
<河村>実は今日、つい先ほど、日本ライトハウスの久保田さんからHyMeというハイブリッドブックのデモを見せていただいたんですね。それは、地の分のテキストは、TTSで読んで、その中の、複雑な図ですね、それは人間がナレーションで読んでるというデモで、それをハイブリッドメディア、ハイミー、HyMeと名付けたそうですけれでも、そのデモをいただいたんですが、私が思うには、先程、2つのケースだけが、全部にオーディオが入ってるもの、全部にテキストが入っているものとなってたんですけれでも、私が考えてるユースケースの中では、例えば盲ろうの人がいた場合に、どういう風になるのかなあとかですね、いくつか、もう少し、場合分けを、もう少し考えてみないと、メタデータの付け方が、そんなふうにはすっきり2つには分かれないんじゃないかなと。そういうような理由です。
<村田>分かりやすく言えば簡単にするために2つにまとめちゃっただけで、確かにもう少しは考えられるだろう、しかしあんまりまだこの追加予定項目に関しては、3行分くらいしか書いていないので、まだまだです。
<河村>もう少し付け加えますと、そのメディアオーバーレイのメタデータ、そのものには、私はあった方がいいのかもしれないなと思ってるんですが、先程挙げた、2つのケースだけというところで、え、ちょっと待ってよと。これ、もうちょっとやっとかないと、後で混乱しないかと、いう風に思ったと、そういう意味です。
<村田>分かりました。河村さんがアクセシビリティに反対なのかと思ってびっくりしました。
 これで終わりました。