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.

アクセシビリティの観点からWebブラウザで標準で取り入れて欲しいUI

6年ほど前に以下のエントリで電子書籍のUIでWebブラウザのUIをまねて欲しいところを書いたことがありますが(6年前かぁ・・・)、今回は逆の話で、WebブラウザのUIで電子書籍のUI(機能というべきかもしれない)を取り入れて欲しいという話。

 ウェブサイトに自治体や公的機関のサイトで、文字の拡大縮小や白黒反転機能などを備えているものものあります。これの要否については、OSやブラウザの標準の機能で備えているので、それを阻害しないようなウェブサイト作りをするべきで、まずはそれにリソースを割くべきという考えがおそらく主流なのだと思います。私も基本的にはこれに同意しますが、一方で、OSやウェブブラウザの機能がどこまで使いやすいかということもやや疑問がなくはありません。
 例えば、OSで白黒反転表示することは可能ですが、これはPC上で行う全ての作業が白黒反転されてしまうので、これに切り替えて使うには、かなりの覚悟がいるというか、白黒反転でなければもう使えないという方に限られてしまうのではないかと思ったりする。
 私も子どもが寝かしつけで抱っこしている際は、部屋を真っ暗にして、iPhoneで電子書籍などを読んでいたこともありましたが(片手で指挟んででも読めるし、暗いところでも読めるので重宝した→当時のエントリ)、そういう場合は、普通の画面ではまぶしすぎるので、白黒反転表示で環境によって読んでいましたが、環境によって、表示を切り替えたいというニーズもあるのではないか。
 
 いわゆる「健常者」と、いわゆる「障害者」の間にはとても大きな層があって、例えば、高齢者の方などはだんだんWebブラウザが使いづらくなっていくことに気がつかないまま、使わなくなるか、遠ざかってしまうという人もいるのではないか。
 Webブラウザで文字の拡大縮小はだいたいついていますし、ボタンで変更できるUIを備えたブラウザもある。しかし、それ以外は、ユーザー側で表示を切り替えるのはかなりハードルが高い。ウェブサイトごとに表示を切り替えたい気もするし、環境に応じて切り替えたい。
 電子書籍だと、文字拡大や、フォント変更、行間変更、配色変更などはほぼ標準的についていますが、Webブラウザでもそういう機能とそれを気軽に使えるUIを備えてもらえないかなと思ったりする。拡張機能で追加できるかもしれないけど、標準で備えてもらってこそ多くの人の手の届くと思うので。

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

 公共図書館や点字図書館が著作権法第37条第3項の権利制限規定に基づいて、視覚障害者等のためにテキストDAISYを作るようにEPUBを作成した場合のPackage Documentファイル(OPFファイル)に包含するメタデータを考えてみました。EPUBのアクセシビリティ仕様であるEPUB Accessibility 1.0の要件を可能な限り満たすメタデータを目指しました。
 今回は、仮にEPUBを制作する図書館を「XXX図書館」とし、この図書館が、『ローマ帝国の崩壊: 文明が終わるということ』(ブライアン・ウォード=パーキンズ 著、南雲泰輔訳)を原本にたEPUB作成した場合を想定してみました。

原本となる書籍の特徴

  • 責任者に著者と訳者がいる。
  • テキストが主体の書籍だが、図(テキストがベースの図も含む)や地図、写真、グラフが用いられている。
  • テキストの一部にルビがふられている(ただし、訳語に原語の発音をカタカナ表記でルビをふったもの)。

想定されるEPUBの特徴

 視覚障害者等のためにテキストDAISYを作るようにEPUBを制作するということで、通常のリフロー型のEPUBであるということに加えて、以下のようなアクセシビリティの要件が追加されると想定します。

  • 原本のページ情報が追加されている。
  • 原本にあるルビはルビタグを用いて表示される(逆にいえば、原本にルビのない箇所にはルビを追加しない)。
  • 図や地図、写真、グラフが画像として挿入される場合は、代替テキストあるいは説明が長くなる場合は長い説明が追加されている。
  • DRMは用いない(DAISYだからDRMは不可というわけではないですが、用いないほうが利用者のリーディングシステムの選択の幅が拡がるのでないほうが望ましい)

以上で、おそらくWCAG 2.0 Level AAに準拠することになるのではないかと思われます。

想定されるEPUBのメタデータ

 EPUB Accessibility 1.0の要件を可能な限り満たすメタデータを包含します。
 また、著作権法第37条第3項の権利制限規定に基づいて製作されたDAISY的なEPUBならば、その原本の出版事項はメタデータに入れておく必要があります。しかし、EPUBの仕様に規定されるメタデータだけでは、語彙が不足するようなので、接頭辞”dtb”を宣言して、DAISY3の仕様から語彙を一部使用することにしました(ただし、DAISY3のメタデータの語彙が定義されているURIが見つからないので、URIはとりあえずの仮のもの)。

作ってみたEPUBのメタデータ

 作ってみたメタデータは以下の通りです。EPUB Accessibility 1.0の要件に関係してくるのは、「アクセシビリティ情報」以下のところです。
 なお、タイトルや責任者名にヨミを入れているのは、今回なんとなく入れてみたという次元のもので、必須というものでもないようです(DAISYでは入れられている例はあまり見たことがない)。
 
 接頭辞”schema”や”a11y”は、EPUB Publications Reserved Prefixesで予約済みなので、今回、接頭辞として宣言したのは、”dtb”のみです。
 実際に作ろうとすると、悩むところが多かったです。正しいかどうか・・・・

<?xml version="1.0" encoding="UTF-8"?>
    <package
        xmlns="http://www.idpf.org/2007/opf"
        unique-identifier="uni_id"
        version="3.0">
    <metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
<!-- 識別子 -->
              <dc:identifier id="uni_id">urn:uuid:4dafre9c99rkfkrfirlelir84448kckc8kiiri393943cdrerre434343gbghtht</dc:identifier>
<!-- タイトル -->
        <dc:title id="title">ローマ帝国の崩壊 : 文明が終わるということ</dc:title>
        <meta refines="#title" property="file-as">ローマ テイコク ノ ホウカイ : ブンメイ ガ オワル ト イウ コト</meta>
<!-- 責任者 -->
        <dc:creator id="creator1">ブライアン・ウォード=パーキンズ </dc:creator>
        <meta refines="#creator1" property="role" scheme="marc:relators">aut</meta><!-- 役割:著者 -->
        <meta refines="#creator1" property="alternate-script" xml:lang="en">Ward-Perkins, Bryan</meta>
        <meta refines="#creator1" property="display-seq">1</meta>
        <dc:creator id="creator2">南雲泰輔</dc:creator>
        <meta refines="#creator2" property="role" scheme="marc:relators">trl</meta><!-- 役割:訳者 -->
        <meta refines="#creator2" property="file-as">ナグモ, タイスケ </meta>
        <meta refines="#creator2" property="display-seq">2</meta>
<!-- フォーマット-->
        <dc:format>application/epub+zip</dc:format>
 <!-- 言語 -->
        <dc:language>ja</dc:language>
 <!-- 著作権情報 -->
        <dc:rights>このEPUB出版物は、著作権法第37条第3項の規定に基づき、障害等の理由により原本をそのままでは利用できない方のためにXXX図書館が制作したものです。著作権法に定められた権利制限規定に該当する場合を除き、又貸し、複製等による第三者への提供はできません。 </dc:rights>
<!-- EPUB製作機関情報 -->
        <dc:publisher>XXX図書館</dc:publisher>
        <dc:date>2017-07-30T22:34:23Z</ dc:date >
        <meta property="dcterms:modified">2017-07-31T23:38:37Z</meta>
<!-- 原本出版情報 -->
        <dc:source id="isbn_id">urn:isbn: 978-4-560-08354-3</dc:identifier>
        <meta refines="#isbn_id" property="identifier-type" scheme="onix:codelist5">15</meta>
        <!-- ↑原本のISBNが13桁の場合は"15"、原本のISBNが10桁の場合は"02" -->
        <meta refines="#isbn_id" property="source-of">pagination</meta>
        <!-- ↑EPUBに原本のページ情報を埋め込んだ場合にそのページ情報のソースがこの原本であるということをこれで記述 -->
<!-- アクセシビリティ情報 -->
<!-- accessMode -->
        <meta property="schema:accessMode">textual</meta><
        <meta property="schema:accessMode">visual</meta>
        <meta property="schema:accessMode">textOnVisual</meta>
        <meta property="schema:accessMode">chartOnVisual</meta>
<!-- accessModeSufficient -->
            <meta property="schema:accessModeSufficient">textual,visual</meta>
        <meta property="schema:accessModeSufficient">textual</meta>
<!-- accessibilityFeature -->
        <meta property="schema:accessibilityFeature">alternativeText</meta>
        <meta property="schema:accessibilityFeature">readingOrder</meta>
        <meta property="schema:accessibilityFeature">tableOfContents</meta>
        <meta property="schema:accessibilityFeature">printPageNumbers</meta>
        <meta property="schema:accessibilityFeature">structuralNavigation</meta>
        <meta property="schema:accessibilityFeature">unlocked</meta>
        <meta property="schema:accessibilityFeature">displayTransformability</meta>
        <meta property="schema:accessibilityFeature">longDescription</meta>
        <meta property="schema:accessibilityFeature">structuralNavigation</meta>
<!-- schema:accessibilityHazard -->
        <meta property="schema:accessibilityHazard">noFlashingHazard</meta>
            <meta property="schema:accessibilityHazard">noMotionSimulationHazard</meta>
        <meta property="schema:accessibilityHazard">noSoundHazard</meta>
<!-- schema:accessibilitySummary -->
            <meta property="schema:accessibilitySummary">全ての図、写真、グラフ等には代替テキストが提供されているか、長文になる場合は、その近くにそれらの長い説明テキストが挿入されています。このEPUB出版物はWCAG 2.0 Level AAに準拠しています。</meta>
<!-- WACGへの適合レベル-->
        <meta property="a11y:certifiedBy">XXX図書館</meta>
        <link rel="dcterms:conformsTo" href="http://www.idpf.org/epub/a11y/accessibility-20170105.html#wcag-aa"/>
     </metadata>
     <manifest>
   …
</package>

作ってみた感想

語彙の追加

 テキストDAISY的に作る場合は、原本出版社(sourcePublisher)や原本出版年(dtb:sourceDate)を入れたい。DAISY3の語彙を使用したいが、DAISY3の語彙を定義しているURIがよく分からず、困った(未だに解決していない)。

アクセシビリティメタデータ

 アクセシビリティメタデータについては、以下を参照。

 アクセシビリティ情報として、追加したSchema.orgのメタデータは、”WebSchemas/Accessibility“(imagedriveさんによる日本語訳)を参考に入力しましたが、個々の値については、Schema.orgの本サイトを含め、どこにも説明がされてないものが多く、どの値を入れるべきか迷うところが多かったです。例えば

  • accessMode:値に”chartOnVisual”、”textOnVisual”など”〜OnVisual”というものが用意されているが、”visual”と区別するのか(視覚機能が必要という点では全て同じように思えるが、画像として表示されるテキスト、グラフ区別する必要があるのか)
  • accessibilityFeature: “rubyAnnotations”について。ごく一部分の提供でも”rubyAnnotations”は入れるべきなのか。また、ルビの目的に制限はないのか(今回は、原本のルビが補足情報の追加が目的でアクセシビリティ機能の追加ではないので、この値は使用しなかった)。
  • WACG以外に適合させるガイドライン、規格は特に思いつかなかった。その場合、「最適化されたEPUB出版物」の要件として求められる「最適化(規格またはガイドライン識別)の要件」に適合できないということになるのか、そのあたりがよく分からなかった。代替手段として、accessibilitySummaryにきちんと書いておけばよいのか。

 dcterms:conformsToにWCAGのどのレベルに準拠しているかを記入することが求められていますが、あわせて”a11y:certifiedBy”で誰がそれを証明するかを記入することも求められています。本当は第三者の外部機関に証明してもらうことが一番でしょうが、図書館で費用をかけて個々のEPUBに外部に証明してもらうのは、難しいとおもわれますので、おれおれ証明になりますが、制作館である「XXX図書館」が証明することにしました。仕様にも出版社が証明者になる例があるので、問題ないはずですが・・・


※2017/08/01 追記
imagedriveさんがWebSchemas/Accessibilityに追記された訳注を参考に、一部メタデータを修正しました。
具体的には以下を追加しました。

<meta property="schema:accessibilityFeature">tableOfContents</meta>
<meta property="schema:accessibilityFeature">displayTransformability</meta>

  迷ったのは、すでに記入していた以下のメタデータです。番号付き見出しをEPUB出版物全体をとおして正しく使用できるかどうか。該当する場合としない場合がありそうですが、今回は該当するという前提で残しました。

<meta property="schema:accessibilityFeature">structuralNavigation</meta>

 
※2017/08/03 追記
dc:rightsに著作権情報(著作権法第37条第3項の権利制限規定に基づいて制作されたこと)を追加しました。DAISYならほぼ当然のことですが、EPUBだと必要でしょうか。おそらく

 <!-- 著作権情報 -->
     <dc:rights>このEPUB出版物は、著作権法第37条第3項の規定に基づき、障害等の理由により原本をそのままでは利用できない方のためにXXX図書館が制作したものです。著作権法に定められた権利制限規定に該当する場合を除き、又貸し、複製等による第三者への提供はできません。 </dc:rights>

 
※2017/08/09 追記
DAISY3のメタデータを追加して原本出版社(sourcePublisher)や原本出版年(dtb:sourceDate)を入れていましたが、DAISY3のメタデータの語彙を定義するURIがみつからないので、原本出版社(sourcePublisher)や原本出版年(dtb:sourceDate)及び接頭辞”dtb:”の定義部分を削除しました。EPUB3の仕様にもあるとおり、dc:sourceに原本のISBNを入れることで、原本を一意に指定できるので、それでよしとしました。ISBNを持たない資料を原本とする場合は、<dc:source id=”###”>Publisher, YYYY, 1st edition, hardback</dc:source>のように原本の出版情報を直接、書けばよいみたいです(参考: Source of pagination for books without ISBN | International Digital Publishing Forum)。

<?xml version="1.0" encoding="UTF-8"?>
    <package
        xmlns="http://www.idpf.org/2007/opf"
        unique-identifier="uni_id"
        version="3.0"
        prefix="dtb: http://www.loc.gov/nls/z3986/2005/dtbook"
        >
<!-- 原本出版情報 -->
        <dc:source id="isbn_id">urn:isbn: 978-4-560-08354-3</dc:identifier>
        <meta refines="#isbn_id" property="identifier-type" scheme="onix:codelist5">15</meta>
        <!-- ↑原本のISBNが13桁の場合は"15"、原本のISBNが10桁の場合は"02" -->
        <meta refines="#isbn_id" property="source-of">pagination</meta>
        <!-- ↑EPUBに原本のページ情報を埋め込んだ場合にそのページ情報のソースがこの原本であるということをこれで記述 -->
        <meta property="dtb:sourcePublisher">白水社</meta>
        <meta property="dtb:sourceDate">2014</meta>

 余談ですが、EPUB 3.1の仕様 では、dc:sourceに対して言及はされているものの、dc:sourceそのものの項目がばっさり削除されていますね・・・。上のやり方(特に原本のページ番号を埋め込んでいるという”pagenation”という情報)は3.1でも使えるのかどうか・・