2015年に「メタデータを電子書籍のアクセシビリティの議論の俎上にそろそろのせませんか」というエントリで、アマゾンのKindle Storeが Kindeコンテンツについて、合成音声による読み上げが可能かどうかの情報を、個々のタイトル詳細画面で提供していないと書いたことがありましたが、いつの間にかアマゾンのKindleストアが、それをメタデータとして提供するようになっています。
合成音声による読み上げが可能となっているKindleコンテンツについては、登録情報欄に「Text-to-Speech（テキスト読み上げ機能）: 有効」という情報が掲載されています。
逆に読み上げができないコンテンツについては、「Text-to-Speech（テキスト読み上げ機能）: 有効になっていません。」というメタデータが記載が掲載されています。
PC版のサイトで、「有効」の横にあるリンクをクリックすると「テキスト読み上げは、Alexa が有効になっている端末で利用できます。」というポップアップが表示されます。iOS版のKindleでも利用できるようになっているはずで、「ちょっと、あれ？」という感じもします。 Alexa対応スマートスピーカーがKindleコンテンツの読み上げに対応した時期に読み上げ可否のメタデータが提供されるようになったのかもしれませんね。
ちなみにモバイル版のサイトだと、PC版のポップアップに相当する箇所には、「Kindle端末のみ有効」と記載されています。PC版とモバイル版の情報の違いは、なんなんでしょうか。
カテゴリー: 電子書籍
アクセシビリティメタデータを提供する、ということ
このブログ記事はWeb Accessibility Advent Calendar 2017の14日目の記事です。
2017年というと、年明け早々にIDPFからの1月5日付けでEPUBの公式のアクセシビリティ仕様であるEPUB Accessibility 1.0が公開されました（ちなみに同じ月の1月31日にIDFPはW3Cと統合）。この EPUB Accessibility 1.0 では、EPUB 自身にアクセシビリティに関するメタデータ（以下「アクセシビリティメタデータ」）を包含させ、コンテンツのアクセシビリティに関する情報をユーザーに提供することを最低限満たすべき要件としています。アクセシビリティメタデータの提供を最優先とする考え方もそうですが、Schema.orgに由来する提供するアクセシビリティメタデータの考え方も個人的に深く共感するところがあったので、個人的に今年一番注目していた仕様でした。
今回は、2017年の締めくくりとして、EPUB（ウェブコンテンツだから、広い意味でウェブアクセシビリティの範疇ということで）を中心にアクセシビリティメタデータの話をしたいと思います。
アクセシビリティメタデータを提供することの意義
アクセシビリティメタデータを提供する意義は、具体的には以下の２つがあると考えています。
- ユーザーが自分の能力でそのコンテンツが利用できるものかどうかをメタデータから判断することができる。逆にいえば、利用できないコンテンツをメタデータを確認する段階で選択肢から排除することができる。
- ユーザーが自分の能力で利用できるコンテンツに絞り込んで検索できることができる（メタデータがコンテンツへのリーチを担保する基盤になる）
上の２つを一言で表すなら、「対象の”discovery”（発見可能性）を担保する」という言葉でまとめられるでしょうか。
1については、以前、アマゾンを取り上げて、以下のエントリで書いた事があります。
２のコンテンツへのリーチの話も、1と同じくらい、あるいはそれ以上に重要です。アクセシビリティメタデータが適切に提供されていないと、他のコンテンツに埋もれてしまい、本当に必要とする人にそのコンテンツへのリーチを担保することができません。１つ１つのコンテンツをアクセシブルに制作して、アクセシブルなコンテンツを総量として増やしてくことは、もちろん重要なことです。しかし、見つけられないコンテンツはそのユーザーにとって存在しないと同義ですので、必要とする人が既存のコンテンツを利用できるようにすることも、ユーザーの選択肢を増やすという意味においては同程度以上に重要です。コンテンツへのリーチを担保する基盤として、アクセシビリティメタデータの提供は非常に重要だと考えています。
「障害者向け資料」とそれ以外の資料へのリーチの現状
少しEPUBから離れますが、アクセシビリティメタデータの周辺の話として、いわゆる「障害者向けの資料」へのリーチの現状を少し紹介します。
いわゆる障害者の利用を想定して制作された資料（電子データ含む）というものがあります。点字資料、録音図書、拡大図書、布の絵本、マルチメディアデイジー、LLブックなどです。便宜上、「障害者向け資料」という言葉を用います。
国内で障害者向け資料をもっとも広い範囲で検索できるのが、おそらく国立国会図書館サーチ障害者向け資料検索です。この検索サービスで検索できる書誌件数は、現在、83万件ほど。ちなみに国立国会図書館の全蔵書数が約4188万点、それを図書、雑誌、新聞という資料種に限定しても約2778万点です。若干大雑把な計算ですが、いわゆる健常者が利用できる資料点数として、4188万点や2778万点を母数とすると、国立国会図書館サーチ障害者向け資料検索で検索できる83万点という数字は、健常者が利用できる資料の2%から3%ほどにすぎないということになり、決して多くはありません。その最大の理由は、そもそも障害者向け資料が少ないということにありますが、点字図書・録音図書全国総合目録やサピエ図書館などのように、障害者向け資料に特化したデータベースに収録されたものか、点字図書、録音図書などのように、資料のジャンル（あるいは分類）で特定できるものくらいしか、検索サービスの検索対象として拾うことができないということもあります（また、現状、国立国会図書館サーチも全てのジャンルの障害者向け資料を検索できるわけではありません。布の絵本やLLブックなど、検索できないジャンルもあります）。
障害者の利用に特化したものでなくても、一般に流通しているもので、障害者が利用できる資料は多くあります。しかし、現時点では、アクセシビリティメタデータがきちんと提供されておらず、多大な資料群に埋もれてしまっているため、障害者がこの中から自分が利用できるものを探し出すことは、かなり困難だと思います。
例えば、DVDです。最近では、普通に販売されるDVDに視覚障害者向けの音声解説や聴覚障害者向けの日本語字幕が付いているものが増えてきています。特にテレビ放送での聴覚障害者向け字幕放送が増えてきているということもあり、「聴覚障害者向け」と書いていなくも、実際は聴覚障害者向けとなっている日本語字幕のついたDVDがかなりの割合で出てきているように感じています。その一部は「特定非営利活動法人メディア・アクセス・サポートセンターのサイトで検索することも実は可能なのですが、網羅されているものではありませんし、普通に発売されているDVDなので、アマゾンや図書館のデータベースなどで検索する段階でそういう情報がほしいところですが、なかなかありません。メタデータに記述があっても、「バリアフリー再生機能:音声ガイダンス/バリアフリー日本語字幕」とあるものもあったり、単に「日本語字幕」とかいてあるだけであったり、表記がバラバラなので、検索のキーとして使用ことができません。
以上のようなこともあり、実際に資料を探す場合には、点字図書、録音図書などのような「障害者向け資料」のジャンルによって検索範囲を絞らざるを得ないところもあります。
EPUB のアクセシビリティメタデータ
障害のある人も含めて多くの人が利用できる可能性のあるコンテンツとして現在進行形で量として急速に増え、アクセシビリティメタデータの提供が急務になっているのが、電子書籍です。そして、電子書籍フォーマットのEPUBについては、2017年に出た EPUB Accessibility 1.0 でアクセシビリティメタデータを提供することが要件として規定さました。EPUB Accessibility 1.0 とこの仕様が提供を求めるアクセシビリティメタデータについては、以下でまとめたことがありますので、詳しくは以下をご参照ください。
EPUB Accessibility 1.0 でEPUBに含むことを求められるアクセシビリティメタデータは端的にいって
- そのコンテンツを利用するには、どのような機能を読者が備えている必要があるのか。
- アクセシビリティのためにそのコンテンツはどのような機能や配慮がなされているのか
という観点からメタデータを記述するようになっています。
EPUB というコンテンツにアクセシビリティメタデータが含まれるということは、コンテンツを知悉しているはずのコンテンツ制作者がアクセシビリティメタデータをEPUBというコンテンツを通じて提供するということを意味します。EPUB がアクセシビリティメタデータが持つだけでは意味がなく、コンテンツをユーザーに提供するアマゾンなどのサービスプロバイダが、検索などに活用されるところに至らないといけませんが、その大前提として制作される段階で制作者が個々のEPUBについてアクセシビリティの要素を判断して、メタデータを提供するというフローがあることが重要です。
だれでもない、自分が今、読むことができるコンテンツを探せることが重要
上で「障害者向け資料」の資料のジャンルの話をしましたが、読書に困難な理由は非常に様々で診断書に名前がのるような明確なものとも限りませんし、読書に困難を感じても本人が障害そのものを自覚していない可能性があります。自分の障害の特性を理解し、かつ、点字資料、録音図書、拡大図書、マルチメディアDAISYのような資料の特徴の理解した上で資料のジャンルから、自分が利用できるもの選ぶということはかなり難しいことです。
また、「障害者」と「健常者」という言葉を便宜上使用しましたが、いわゆる「健常者」でも一時的な状況下において、読みたくても読めない状況はだれでもあるはずです。暗いので読めない、両腕がふさがっているので本が持てない、満員電車で本を拡げることができないという状況などです。私も子どもがまだ小さく、家の中が騒がしくてテレビなどがとても観れたののではないので、よく聴覚障害者向けに提供されている字幕を表示させるということを普通にやっています。アクセシビリティを必要とする人と環境の境はとてもあいまいです。
ユーザーにはメタデータの提供を通じて、資料のジャンルだけではなく、さらに一歩踏み込んで、コンテンツ1点1点に対してアクセシビリティの観点からどのような性質を持つものかという情報を提供し、ユーザーが自分の能力、置かれた状況を勘案して利用の可否を判断することができる情報の提供が必要だと感じていましたが、EPUBアクセシビリティメタデータの考え方はまさにそれです。
こういう情報が広い範囲で提供できるようになったら、「障害者向け」とそうでない資料の区別なく、広い範囲から自分が利用できるコンテンツを探し出すことができます。繰り返しになりますが、見つけられないコンテンツはそのユーザーにとって存在しないと同義です。障害者向け資料とそうでない資料は、数において後者が圧倒的に多いのですから、その1%でも利用できることがわかれば、選択肢が大幅に広がります。１つ１つのコンテンツをアクセシブルに制作して、アクセシブルなコンテンツを総量として増やしてくことも重要ですが、既存のコンテンツを利用できるようにすることも、ユーザーの選択肢を増やすという意味においては同程度以上に重要です。
私が知る限り、国内ではこれまでアクセシビリティメタデータの議論はあまりされてはいない印象でしたが、今年は、Advanced Publishing Laboratory Accessibility WGの場において、EPUB についてアクセシティメタデータの議論も行われるようになりました。議論の内容もさることながら、議論される事自体が画期的かもしれません。来年以降はこの動きが他にも広がることを期待しています。
明日12月15日は、kobatatakayuki さんの記事です。
W3C Publishing Working Groupで軽量SMIL（次世代SMIL?）について議論始まる
W3CのPublishing Working Group の2017年9月18日の電話会議で、SMIL lite（軽量のSMIL）が（おそらく）始めて議論されています。先のエントリで紹介したWeb Pulications
での利用が想定されています。Web Pulications はEPUBと統合されて、EPUB4的な立ち位置になる可能性も示唆されているので、次世代SMILといえる立ち位置になりうるのかもしれません。まだ、議論は始まったばかりのようで、どこに向かうのかはわかりませんが。
- PWG Meeting 2017-09-18
- （要件リスト及び検討事項）Requirements and design options for synchronized multimedia · w3c/publ-wg Wiki
要件リストは、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.０の仕様では、動画をサポートしないことがわざわざ言及されています（最新の 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.