search

Advanced-Publishing-Laboratory / A11Y

アクセシビリティWGにおける議論
2 stars 0 forks source link

accessibilityFeatureはどう指定すべきか？ #2

Open murata2makoto opened 7 years ago

murata2makoto commented 7 years ago

〇accessibilityFeature 　アクセシビリティのために追加された機能や配慮に関する情報を提供する語彙です。代替テキストを提供しているなどの情報を伝えるものですが、これにルビ情報が付与されていることを示す“rubyAnnotations”という値があります。 ルビが一部で振られていれば、rubyAnnotations”は入れるべきなのか（それとも総ルビ？）。また、ルビの目的に制限はないのか(ルビはアクセシビリティ情報の追加のみで使用されるわけではないので、)というあたりが、よくわかりません。

imagedrive commented 7 years ago

資料：

murata2makoto commented 7 years ago

rubyAnnotationについては、工藤さんの資料があります。

メールのほうでも、ルビについての一般的な議論はするつもりです。ルビについてのより具体的な議論は、別のissueを立てようと思っています。

kzakza commented 7 years ago

accessibilityFeatureには、rubyAnnotationを入れるか入れないか、つまり、０か１の選択肢しかないので、工藤さんの資料にある総ルビ、一部ルビ、ルビなし、あとで図書館や点字図書館がルビを加えたという情報をこれで表現するのは、難しいと思います。工藤さんの資料にある議論とは、切り離したほうがよいように思いましたが、どうでしょうか。

kzakza commented 7 years ago

出版社も使うということを前提に考えると、少なくとも図書館や点字図書館がルビを加えた（つまり、オリジナルの図書にないルビがある）をrubyAnnotationの付与の基準にするのは、変な気もします（それだと、たとえば、児童書などは総ルビのものも多いのに出版社はこの値を入れることができない）。総ルビ、一部ルビ、ルビなしを基準にするか、それを問わずにルビの目的（アクセシビリティ情報追加を目的としたルビであれば入れるなど）を基準にするかなのかなぁと思います。

murata2makoto commented 7 years ago

accessibilityFeatureには、rubyAnnotationを入れるか入れないか、つまり、０か１の選択肢しかない

いえ、これはそうではありません。

<meta property="schema:accessibilityFeature">rubyAnnotation/partial</meta>
<meta property="schema:accessibilityFeature">rubyAnnotation/none</meta>

なんていう表記を許すように決めることはわれわれの裁量でできます。

しかし、どこまでEPUB中のメタデータで書かせるかは議論すべきと思います。ある程度意見が出そろったところで、電話会議するのがいいかもしれないと思っています。

murata2makoto commented 7 years ago

ルビについては、GitHubを見ていない人も関心があると思われるので、メーリングリストに移しましょう。。

imagedrive commented 7 years ago

本題に戻って、各値の定義？について確認したく。まず以下の4つから話ができれば。

highContrastAudio

判断基準が明覚なので記述自体は困難でないと思います。ただ、WebSchemas/Accessibilityの日本語訳にも注を入れましたが、達成基準 1.4.7はレベルAAAです。満たせば当然のことながら記述するべきですが、注意を払う必要があるのか疑問です。

highContrastDisplay

WCAGに判断基準がわりとしっかり書いてあるので、記述は困難でないと思います。ただ、達成基準 1.4.6もレベルAAAです。

largePrint

まず大きな印刷物のガイドラインが不明です。そのガイドラインが複数あった場合、何れかに従っていればいいのか？どのガイドラインに適合しているのかに関する情報は必要ないのか？疑問があります。 これはコンテンツが実際に印刷されたときのことを想定してるんですよね？

displayTransformability

考慮するまでもなく、相対値で指定しているなら細かく指定せずdisplayTransformabilityだけで良いような気がします。

kzakza commented 7 years ago

私見ですが、

highContrastAudio メディアオーバーレイをつかって作成されるDAISY的なコンテンツ（本文音声のみor テキスト＋音声同期）で使用される音声はこの基準を満たせるものが控えめに言っても一定数あるので、そこでは使用されうると思います。こういうコンテンツは入れてもらうことになるのでしょうか。ノイズがひどいもの中にあり、同じタイトルの録音図書があれば、利用者はノイズのないものを選びたいと思うはずですので。

highContrastDisplay については、特に意見ありません。該当するなら入れるということになるのかもしれませんが、文字色と背景色を指定しなければ、結構満たせてしまう要件ですか？そういうのは、displayTransformabilityをいれるべきで、highContrastDisplayは入れないのでしょうか？highContrastDisplayとdisplayTransformabilityが排他的な関係かはわかりませんが。

largePrint ガイドラインは、たとえば、こういう　http://www.aph.org/research/design-guidelines/　ガイドラインなのでしょうか。large print guidelinesなどで検索すると、いろいろなところが公開しているようです。日本だと、教科書については、文部科学省が拡大教科書について基準をつくっています。ほかにもあるかもしれません。http://www.mext.go.jp/component/a_menu/education/detail/__icsFiles/afieldfile/2010/01/15/1235124_1.pdf いずれにしても、これは拡大版として印刷されることを想定した電子ファイルに使用するのではないかと思いますので、少なくともdisplayTransformabilityを入れることができるEPUBには使用しないのではないかと思います。

displayTransformability imagedriveさんのおっしゃるとおり、ＲＳの表示変更機能を阻害しない作り方をしているなら、この値を入れてよいのではないかと思います。

murata2makoto commented 7 years ago

AAAなものは、先送りしていいのではないかと思います。となると、ＲＳの表示変更機能を阻害しない作り方をしているならdisplayTransformabilityを指定するというだけで、変換のための機能についてはいいのではないでしょうか。

kzakza commented 7 years ago

DAISY図書（音声のみ、音声＋テキスト）で作成される音声ファイルは、highContrastAudioの要件はだいたい満たせると思いますので、近い将来のDAISYからEPUBへの移行も考慮すると、highContrastAudioは、入れておいていただいてもよいかなという気がします。音声の品質をメタレベルで区別したいというニーズがDAISYでは確かにありますので。

imagedrive commented 7 years ago

WebSchemas/AccessibilityのFeatures for transformationにある上記4項目の意見をまとめると。

highContrastAudio

レベルAAAなので現状は考慮しない。ただし、DAISYなどに備えて指定方法を決める必要はある。

highContrastDisplay

レベルAAAなので現状は考慮しない。多くのRSが前景/背景の色の変更に対応可能である。

largePrint

印刷物ではないので考慮しない。大活字版が必要なら設定を変更して出力すればよい。

displayTransformability

電書協EPUBガイドラインなどに従い、RSの表示変更機能を阻害しない作りであれば、displayTransformabilityを指定。 もし、CSSなどで個別に表示の制御をしているなら、オプションを使用する（例：displayTransformability/font-sizeなど）。

imagedrive commented 7 years ago

少人数でさっさと進めるのもどうかと思いますが、取り敢えず叩きを作るということで、次の項目に移りたいと思います。

imagedrive commented 7 years ago

と言いつつlargePrintですが、私もlarge print guidelineで検索し、いくつかそれらしいものを発見しました。しかし、標準なのか独自なのか判断できず仕舞いです。

ちなみに文部科学省のガイドラインってこれですかね？　障害のある児童及び生徒のための教科用特定図書等の普及の促進等に関する法律 第6条第1項の規定に基づき定める教科用拡大図書の標準的な規格の策定等

一般向けですぐ思いつくのは講談社の「大きな文字の青い鳥文庫」です。内部で持っているだろう制作ガイドラインを知りたいところです（そんなに複雑かつ詳細な内容ではなさそうだけど）。

kzakza commented 7 years ago

文部科学省のガイドラインは、それですね。教科書バリアフリー法で教科書会社は、標準規格にあった教科用特定図書等の発行が努力義務として定められています（努力義務ながら小中の教科書は全点発行されている）。

海外で、標準というものは私も見つけることができませんでしたが、さきほど上にあげたAmerican Printing House for the Blind(APH)は、視覚障害者のための出版物を製作する米国最大の団体で、視覚障害児のために点字版、拡大文字版、録音版、電子データ版等のアクセシブルな形式の教科書や教材の製作を行っているそうなので、米国ではそれなりの位置にあるかもしれません。 http://www.aph.org/research/design-guidelines/

imagedrive commented 7 years ago

情報ありがとうございます。 海外事情についてはここで深掘りするのは避け、別の機会に情報収集したいところです。

imagedrive commented 7 years ago

次のお題はFeatures for structure and navigationに8項目です。なお原文の詳細にはtableOfContentsがありません。

annotations

よくある本文と巻末または章末にある注釈との相互リンクがあれば指定可能で良いかと。 理想的にはEPUB 3 Structural Semantics Vocabularyのendnote/endnotesまたはfootnote/footnotes、noterefを使用してマークアップすることでしょうか。 epub:typeを利用したマークアップで、具体的に機能を提供しているのはiBooksですが、他にもあるんですかね？

bookmarks

"The work includes bookmarks to facilitate navigation to key points."とあるので、EPUBにこれに該当するのもは、ナビゲーションドキュメントlandmarksかなと考えています。 このあたり村田さんの意見を伺いたいです。

index

索引が提供されていれば指定可能で良いかと。 理想的にはEPUB 3 Structural Semantics Vocabularyのindexを使用することですかね。annotationsも含め、具体的なマークアップ例があると親切だと思います。

printPageNumbers

EPUB Accessibility Techniques 1.0の「PAGE-001: 改ページのマーカーを提供する」を実装していれば指定可能で良いかと。 ナビゲーションドキュメントのpage-list navを使えばさらに良いといったところでしょうか。

readingOrder

WebSchemas/Accessibility日本語訳にも書きましたが、EPUBのアクセシビリティ評価は個々のドキュメントではなく作品全体とあるので、それを拡大解釈すれば、スパインで読み上げる順番が設定されているので、EPUBであれば自動的にこの値は指定できる（むしろしなければならない）のだと思います。

structuralNavigation

EPUB Accessibility Techniques 1.0の「TITLES-002: 番号付きの見出しが出版物の階層を反映するように保証する」が反映されていれば指定可能で良いかと。 ただ、TITLES-002は読んでて理解し難いので、解説が必要でしょうね。

tableOfContents

EPUBはナビゲーションドキュメントがあるので、自然と設定されるものだと思います。コンテンツに含める目次というなら話は別ですが、原文に解説がないのでなんともいえません。

taggedPDF

無視で。

kzakza commented 7 years ago

annotations これは、注釈があるというだけではなく、 Digital Publishing Annotation Use Cases(（Web annotation関連の文書ですが）に"An annotation provider (personal or retailer) wishes to provide annotations that give additional information about resources for the purposes of accessibility. "とあるように、アクセシビリティ情報の提供の注釈がある場合に使用するのかとおもったのですがどうなのでしょうか。具体例として思いつくのが、点訳や音訳（録音図書の製作）時にそのまま、点字化、音声化しただけでは、落ちてしまう原本の情報を補うことを目的に点訳者、音訳者がつける注記でしょうか。テキストの場合も引用が２文字分の字下げなどで表現されていて、読み上げだとそれが判別できない場合は、[引用開始]　～[引用終わり]と注記を補記する事例はあるかと思います。ちょっとこれは自信ありません。

bookmarks はよくわかりません。landmarkですか。なるほどです。

printPageNumbers 以降は、imagedriveさんと同意見です。

structuralNavigation　は、確かに悩みます（特定のタイトルが該当するのかどうか悩みました）ので、解説がほしいところです。部、章、節ぐらいには一冊を通した一貫した番号がついていることが多いですが、さらにその下やさらにその下の見出しには、番号がついていないことが多いので、その場合は、該当しないということになるのでしょうか。録音図書の製作だと、音声のみで構造や位置関係がわかるように、見出しに番号がついていないものにも番号を振ることがあります。DAISY領域の製作だと、テキストベースのEPUBでも同様の処理がなされる可能性はあります。

imagedrive commented 7 years ago

情報ありがとうございます。

annotationsをよくある相互リンクの注釈とした理由は、これが構造とナビゲーションのための機能にカテゴライズされているからです。 Digital Publishing Annotation Use Casesの例なら、拡張のための機能にカテゴライズされたaudioDescriptionやlongDescriptionが近い用途なのかなと。

kzakza commented 7 years ago

なるほど。EPUBの構造として、注釈という本文と区別されるべき情報がある場合にannotationを入れるということでしょうか。納得しました。

imagedrive commented 7 years ago

あくまで私がそう思っただけなので、拡張的な注釈の機能として適切な値が容易されていなければ、annotationsの含めるべきかも。

imagedrive commented 7 years ago

その下の見出しには、番号がついていないことが多いので、その場合は、該当しないということになるのでしょうか

私は見出し要素でマークアップされているものを解釈しました。数字以外にもアルファベットなどでナンバリングされることもあるので

kzakza commented 7 years ago

EPUBの構造に含まれるのナビゲーションに係る情報として、index 、printPageNumbers などと並んで annotations（注釈）があるというということを、メタデータとして伝えることは、アクセシビリティ的には、意味があることなので、妙に得心したところはありました（annotationsが「重要なナビゲーション補助」に係る構造なのかは若干ひっかかるのですが）。その意味では、その延長でepub:typeを使ってセマンティクスを埋め込むことが、メタデータとして提供する趣旨にはかなっているのかなと思いました（実装が伴っていないのかもしれませんが）。一方で、全然違うコンテキストで、EPUBにもOpen Annotation（W3CでWeb Annotationとして仕様になっていますが）をつかった注釈の仕様があるので、OA準拠のannotationが付いた場合につけるという考えもなくはないかもしれません（とはいえ、「構造とナビゲーションのための機能」ではないかなという気も）。

imagedrive commented 7 years ago

annotations値を除くと、Open Annotationの目的に対応する値がないので、annotationsに含めるか新しい値を提案する必要がありそうです。 それが単純な相互リンクではなく、情報を補う目的の注釈の有無をユーザーに知らせることは重要だと思います。 ただ、よくよく考えると注釈や脚注の大半は、追加の情報を提供したり、著者や訳者の解釈を提供するために用いられるので、annotationsに入れたほうが良いような気がしてきました。

annotationsが「重要なナビゲーション補助」に係る構造なのかは若干ひっかかるのですが

重要なナビゲーションだと確信しています。実装方法ひとつとっても本によって雲泥の差ありますから。

imagedrive commented 7 years ago

Web Annotationについては神崎さんが詳しそうなので、話を伺ってみたいですね。

http://www.kanzaki.com/works/2016/pub/image-annotator

kzakza commented 7 years ago

はい。うかがってみたいですね。神崎先生はお詳しいと思います。以前、こちらでも記事を書いていただいたことがあります。 E1916 - 情報の分散記述と共有をうながすWeb Annotation | カレントアウェアネス・ポータル 話がそれてしまいますが、神崎先生も紹介しているIIIFというデジタルアーカイブのフレームワークが、デジタルアーカイブ関係では盛り上がっていて、対応しているところもでてきています。これがOpen Annotationを採用しているので、Open Annotation（あるいはWeb Annotation）がデジタルアーカイブ領域では普及しそうです（たぶん）。 今、まさに広まりつつある国際的なデジタルアーカイブの規格、IIIFのご紹介

imagedrive commented 7 years ago

もう少し目的がはっきりしてきたらコンタクトをとってみます。電子書籍関係は興味あられると思うので。

kzakza commented 7 years ago

はい。よろしくお願いします。 私は、Web AnnotionのいうところのAnnotionは、オリジナルコンテンツとは別のレイヤー及びそのレイヤーに書き込まれる情報で、オリジナルコンテンツを改変せずに作者以外によって追加されるオリジナルコンテンツに追加される情報（オリジナルと区別できる付加的な情報）なんだと理解してます。もし本当にＥＰＵＢでWeb Annotionが使えるようになるのであれば、アクセシビリティ的には、これまでオリジナルの本文に入れこむ形でたとえば、引用が始まった個所に[ここから引用開始]～[引用ここまで]とDAISY製作者が注記を追記していたものがアノテーションに移せるので、本文と製作者注記との関係が明確になってすっきりしますし、読者にとっても利便性が高いのではと期待しています。

kzakza commented 7 years ago

話もどしますと、annotattionのほうは、Web Annotationはとりあえず除いて、当初のimagedriveの案でよいと思います（話をかき回してしまいましたが　汗）。

murata2makoto commented 7 years ago

私も、Hypothes.isのソースコードを見ているところです。注釈のデータがどう表現されているかもわかって面白いです。

Open Annotationsは、本体からはまったく離れたところに置くものなので、本体のメタデータではつけられませんよね？なんで、Features for structure and navigationにannotationsが入っているのか私には分かりません。

murata2makoto commented 7 years ago

話もどしますと、annotattionのほうは、Web Annotationはとりあえず除いて、当初のimagedriveの案でよいと思います（話をかき回してしまいましたが　汗）。

では、文書に<p epub:type="footnote">があったら指定する？

kzakza commented 7 years ago

はい。あったら、指定するでよいかと。

Open Annotationsは、本体からはまったく離れたところに置くものなので、本体のメタデータではつけられませんよね？

あ、そうなんですか。アノテーションドキュメント（JSON?）はEPUB本体と離しておいても、本体に梱包してもよいものかと思っていたのですが、そうではないですね・・。

murata2makoto commented 7 years ago

EPUB本体に埋め込むことも可能でしょう。しかし、実態としてannotationサーバを立てて、そこに注釈を保持するのがhypothes.isのやり方です。いま開発中のAppache annotator(これはhypothes.isのサーバをほかのクライアントから使えるように改善したもの）も、やはりそうなっています。本体にopen annotationsが埋め込まれることが多いとは考えにくい。

kzakza commented 7 years ago

epub:type:"endtnoteもでしょうか（あと、使用する要素そのものは、上のfootnote含めて、p要素とはかぎらず、span要素などもあると思います）。ただ、epub:type属性があるものに限定してよいかどうか・・

imagedrive commented 7 years ago

annotationsの解釈をいわゆる本文と注釈部のリンクとして考えるなら、annotationsを記述する判断に、epub:typeの有無は必須でないほうが良いと思います。単純に相互リンクだけで機能としては成り立つので。 少なくとも相互リンクされていれば、annotationsを宣言する方向が望ましいと思います。

footnote(s)やendnote(s)などの使用は自動的に付与する場合のトリガーとして使いたいところです。

imagedrive commented 7 years ago

この発見のためのメタデータは、OPFだけで完結できるので、メタデータを付与するために、コンテンツ側の修正が必要になることはできれば避けたいです。

kzakza commented 7 years ago

annotationをメタ情報として、提供する意義は、注釈という本文とは区別するべき情報がこの本には含まれている（から、例えば、読み上げソフトで利用するときなどは注意してください）ということを伝えることかと思うので、epub:typeが設定されていないと、その情報がメタに含まれないというのも趣旨からすると違うのかもしれません（あると望ましいのは言うまでのないのですが）。Amazon のパブリッシングガイドラインでは、相互リンクを求めるようになっているようですが、本文と注釈との相互リンクは普通にされているものですか？

kzakza commented 7 years ago

ちょとと話を戻してしまうのですが、indexについてです。「索引が提供されている」の定義ですが、ただ、索引が掲載されているだけで、該当するとするか、例えば、索引に「織田信長　23ページ」とあり、「23ページ」にそのページに飛べるリンクがはってあって初めて該当するか、どちらでしょうか。後者の例はあまり見ないような気もしますし、ページ単位で飛べるリンクはそこまで求めないでよいような気もしますし（索引に項目が立てられているという情報は、電子書籍化されていても重要だと思うのですが）。「索引が提供されている」とすると、後者で解釈する人が多い気がするので確認です。

imagedrive commented 7 years ago

epub:typeが設定されていないと、その情報がメタに含まれないというのも趣旨からすると違うのかもしれません（あると望ましいのは言うまでのないのですが）

同意見です。

本文と注釈との相互リンクは普通にされているものですか？

実装方法はまちまちですが、注釈があって相互リンクされていない本はいまのところ読んだことないです。

imagedrive commented 7 years ago

例えば、索引に「織田信長　23ページ」とあり、「23ページ」にそのページに飛べるリンクがはってあって初めて該当するか

こちらを該当にしないといけないと考えています。ただ項目が羅列されているだけでは、電子書籍の索引機能として不十分だと思うからです。 索引からのリンクを持つ電子書籍はあまり見ませんが、デザイニングWebアクセシビリティが索引から本文へのリンクをつけていました。

kzakza commented 7 years ago

ありがとうございます。

実装方法はまちまちですが、注釈があって相互リンクされていない本はいまのところ読んだことないです。

なるほどです。でしたら、注釈は相互リンクがあることを前提としてよいのではと思いました。

索引からのリンクを持つ電子書籍はあまり見ませんが、デザイニングWebアクセシビリティが索引から本文へのリンクをつけていました。

これもなるほどです。索引として項目から該当箇所（あるいはページ？）にリンクがはられて、索引として機能している事例があるのですね。索引の項目をみて、または、ページマーカーが埋め込まれていれば、リンクがはられていなくても全文検索やページリストで最低限、そこに飛ぶことができるかなと思ったりしたのですが、メタデータとして識別させる意味があるのは、おっしゃるとおり、該当箇所（ページ？）へのリンクありのものでしょうか。

imagedrive commented 7 years ago

取り急ぎFeatures for structure and navigationの8項目をまとめると

annotations

必須：本文と注釈部の相互リンクを設ける 推奨：EPUB 3 Structural Semantics Vocabularyのendnote/endnotesまたはfootnote/footnotes、noterefを使用してマークアップ

検討事項：拡張的な注釈をどうするか 例）点訳や音訳（録音図書の製作）時にそのまま、点字化、音声化しただけでは、落ちてしまう原本の情報を補うことを目的に点訳者、音訳者がつける注記

bookmarks

ナビゲーションドキュメントlandmarksを実装する

index

必須：索引として独立したページを設置し、本部の該当する箇所/ページへのリンクを設ける 推奨：EPUB 3 Structural Semantics Vocabularyのindexを使用する

printPageNumbers

必須：EPUB Accessibility Techniques 1.0の「PAGE-001: 改ページのマーカーを提供する」を実装する。 推奨：ナビゲーションドキュメントのpage-list navを使用。

readingOrder

読み上げ順序はスパインで指定するので、EPUBは自動的に達成

structuralNavigation

EPUB Accessibility Techniques 1.0の「TITLES-002: 番号付きの見出しが出版物の階層を反映するように保証する」を満たす

tableOfContents

EPUBはナビゲーションドキュメントが必須なので自動的に適合

taggedPDF

無視

kzakza commented 7 years ago

整理ありがとうございます。異論ありません。

imagedrive commented 7 years ago

続けてFeatures for content controlの3項目について検討したいと思います。

synchronizedAudioText

メディアオーバーレイやマルチメディアDAISYのようなテキストと音声が同期するコンテンツを含んでいれば指定する。

timingControl

再生や一時停止、停止などが可能であれば指定する。 （機能はユーザーエージェントのマルチメディア機能依存だし、コンテンツ側で制御できるものではないので、指定自体が微妙だけど）

unlocked

EPUBなど成果物の段階で暗号化などをしていることはまず考えにくい。 テキストの難読化や画像に透かしをしてパッケージ化していることがあるのか？フォントはあるかもしれないけど、フォントをコンテンツに含めることがまた稀。配信後ならともなく単体のEPUBではほぼ指定することになるのでは？

kzakza commented 7 years ago

synchronizedAudioText 異論ありません。

timingControl おっしゃるうとおり、RS次第な気がしますが、入れるとするなら動画や音声がEPUBに同梱されているとして、RS側のコントロールを阻害するもの（勝手に再生する、RS側で再生が止められないなど）がない場合に該当するとするのでしょうか。

unlocked 　DRMフリーかどうかということですよね。DRMをつけるプラットフォームがユーザーに配信後にこの値が入っていると、まずい気がします。出版社もEPUBを製作する段階（外部に製作を依頼する段階）で提供するプラットフォームもある程度想定されていると思いますので、それを見越して入れてもらうしかないでしょうか。本来は提供に責任を負うプラットフォームが判断するべき値なんでしょうね。

imagedrive commented 7 years ago

勝手に再生する

これに関してはWAI的に勝手に再生すること自体は否定していないようです。達成基準 1.4.2 を理解する

RS側で再生が止められないなど

この制御が（UIを消すなど）果たしてコンテンツ側でできるのかどうか一応調べる必要はありそうです。 記憶が定かではないのですが、Edgeでtrigger要素を使い動画/音声を制御した場合、video/audio要素のUIが消えていたような気がします。家に帰って確認してみます。

DRMをつけるプラットフォームがユーザーに配信後にこの値が入っていると、まずい気がします。

私もそうだとは思うのですが、中小の出版社などは直販はDRMフリーで配信する場合もあります。そうなるとunlocked値有無だけのEPUBを2種類作らないといけなくなり、これは負担になるかなと。 Webを前提に作られたものなので、込み入った事情を持つ電子書籍では、どの段階で反映するべきなのかが難しいですね。 まぁ、消費される段階、つまりユーザーがRSで読む段階を想定するのが良いのでしょうが。

imagedrive commented 7 years ago

ちょっと戻りますが、annotationsやprintPageNumbersは、4.4 読み飛ばし機能と回避機能[EPUB Media Overlays 3.1]を考慮しておく必要があるかもしれませんね。 この機能を実装したRSが登場するとは考えにくいですが。

murata2makoto commented 7 years ago

皆さんが判断に迷うものは、だいたい現場ではつけられないでしょう。そして、EPUB reading systemsが明らかに利用できるもの以外は、苦労してつけても有難味がないから普及が危ぶまれます。WebSchemas/Accessibilityのほうでも、AAA/AA/Aのようなレベル分けは出来ないもんでしょうかね？

kzakza commented 7 years ago

ちょっと戻りますが、annotationsやprintPageNumbersは、4.4 読み飛ばし機能と回避機能[EPUB Media Overlays 3.1]を考慮しておく必要があるかもしれませんね。 この機能を実装したRSが登場するとは考えにくいですが。

なるほどです。考慮しておく必要ありそうです。考えてみると、読み飛ばし機能を実装したRSを利用するユーザー向けに対しては、「このEPUBには、annotationがあるぞ、ページ番号があるぞ」とメタデータで知らせることが、より重要かもしれません。これらをユーザーがRSの設定で読み飛ばし設定（表示しない設定）にしていると、annotationやページ番号の存在そのものに気が付かない可能性がありますので。DAISY3でも読み飛ばしは設定できるようになっていて（DAISY3の場合は、製作者側が製作段階で予めコンテンツに読み飛ばしてよい箇所を構造的に指定するというものですが）、DAISY系でEPUBに対応したRSで実装する可能性もなくはありません。

kzakza commented 7 years ago

これに関してはWAI的に勝手に再生すること自体は否定していないようです。達成基準 1.4.2 を理解する

　これは不勉強でした　汗。

この制御が（UIを消すなど）果たしてコンテンツ側でできるのかどうか一応調べる必要はありそうです。記憶が定かではないのですが、Edgeでtrigger要素を使い動画/音声を制御した場合、video/audio要素のUIが消えていたような気がします。家に帰って確認してみます。

ありがとうございます。実際にコンテンツ側で阻害することが可能かどうか具体的に存じ上げずに書いてしまいました　汗。F93: 達成基準 1.4.2 の失敗例 － 自動再生する HTML5 のメディア要素を一時停止または停止する方法がない にかいてある事例に近いのですが、audio要素やvideo要素の設定で、controls属性（再生や停止ボタンなどを表示させる）なしで、autoplay属性とloop属性を付けて、延々再生を繰り返させることもRSによっては可能なのかもしれません。 RSでの制御を阻害するなんてことは、作る側の意図が明確にないとできないことなので、入れやすい値だろうと思っていたのですが、改めて考えてみると、自分が作ったものがRSを阻害しないようにできていると判断することも、それなりに技術的な知識を備えていないと確信もってできないことかもしれませんね。

　

imagedrive commented 7 years ago

WebSchemas/Accessibilityのほうでも、AAA/AA/Aのようなレベル分けは出来ないもんでしょうかね？

私の脳内計画としては、

  1. EPUBであれば自動的に付与する値
  2. コンテンツの性質や実装状況により人間が判断して付与する値
  3. 無視する値

の三つに分類したいと思っています。 特に1に関しては、テンプレートとなるEPUBを用意し、記述しておく感じです。電書協EPUBガイドのテンプレートEPUBに組み込めればなお良いですが。

また、各項目についてもレベルを設け、必須と推奨などを設定できればと考えています。