この文書は「EPUB Accessibility Techniques 1.1」の日本語訳である。最新の文書は https://www.w3.org/TR/epub-a11y-tech-11/ である。原文もしくは完全な情報は、EPUB Accessibility Techniques 1.1 を参照されたい。
この日本語訳は参考である。公式な文書ではなく、翻訳・解釈の正確性を保証していない。
Copyright © 2021 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.
EPUB アクセシビリティ達成方法集は、EPUB 出版物の発見及びコンテンツのアクセシビリティ要求事項を定義する。
このセクションは、発行時点におけるこのドキュメントのステータスについて説明する。他のドキュメントが、このドキュメントに取って代わることがある。現在の W3C 出版物のリスト及びこの技術報告書の最新の改訂版は、https://www.w3.org/TR/ の W3C 技術報告書インデックスに掲載されている。
このドキュメントは、最初の公開作業グループ ノートとして、EPUB 3 ワーキング グループによって発行された。
この仕様の議論は、GitHub イシューで行うことを推奨する。代わりとして、メーリングリストにコメントを送ることもできる。public-epub-wg@w3.org（購読、アーカイブ）へ送られたい。
最初の公開作業グループ ノートとしての発行は、W3C メンバーシップによる承認を意味するものではない。
これは草案のドキュメントであり、他のドキュメントによって、いつでも更新、置き換え、又は廃止される可能性がある。進行中の作業以外のものとしてこのドキュメントを引用することは不適切である。
このドキュメントは、W3C 特許ポリシーの下で運営されているグループによって作成されている。グループは、このドキュメントが W3C 勧告になることを期待していない。
このドキュメントは、2020年9月15日 W3C プロセス ドキュメントに準拠する。
このセクションは規定ではない。
このドキュメント、EPUB アクセシビリティ達成方法集は、EPUB® 出版物の [EPUB-A11Y-11] 発見及びアクセシビリティ要求事項を満たす方法のガイドラインを提供する。
このドキュメントは、適用の本質的な違いが存在しない [WCAG2] 及び [WAI-ARIA-1.1] で既に取り組まれている達成方法集とベスト プラクティスはカバーしていない。
このドキュメントは、EPUB 3 [EPUB-3] で定義された次の用語を使用する。
加え、[WCAG2] で定義された支援技術の定義を使用する。
支援技術は、必ずしもリーディング システムから切り離されたアプリケーションではない。リーディング システムは、例えば、音声合成の再生など、しばしば、スタンドアロンの支援技術の機能を統合している。
このドキュメントで説明されているアクセシビリティの達成方法は、本質的に助言である。これらは、製作者が [EPUB-A11Y-11] の要求事項に適合する EPUB 出版物を制作する際の手助けを目的としているが、あらゆるシチュエーションで全て適用できず、その仕様の要求事項を満たすために他の方法があるかもしれない。結果として、このドキュメントは、規範的な要求事項を提供するものとして読まれるべきではない。
これらの達成方法集は、一般的に、アクセシブルなソリューションが存在しないデジタル出版における問題にも対処していない。W3C のデジタル出版インタレスト グループは、これら問題 [DPUB-Accessibility] の多くを概説としてメモを公開している。ソリューションが利用可能になると、それを参照するひとつかふたつかは、適切な文書に組み込まれるであろう。
製作者がこれらや関連する達成方法集でカバーできない問題に遭遇したとき、アクセシビリティ規格を満たす方法の指導を受けるために適切なコミュニティに対してこの問題の報告をすることが推奨される。W3C アクセシビリティ インタレスト グループは、[WCAG2] と [WAI-ARIA-1.1] の要求事項を話題にする問題のミーティングである公開メーリング リストを持っている。W3C Publishing Community Group のイシュー トラッカーは、EPUB 固有の要求事項を実装するためのサポートを求めるために使用することができ、EPUB 3 Working Group のイシュー トラッカーは、このドキュメントのイシューを報告するために使用できる。
アクセス モードは「人間の感覚知覚システムまたは認知能力を介して、ユーザーが、デジタル リソースのコンテンツを処理または知覚する」 [ISO24751-3] として定義された。例えば、EPUB 出版物に画像と動画が含まれている場合、視覚は、作成されたとおりの完全なかたちでコンテンツを消費するために必要とされる。
一般的に、EPUB 出版物で指定された4つのアクセス モードがある。
EPUB 出版物が自分たちのニーズに適しているかどうかの決定をするユーザーのために、コンテンツを消費するために必要なこれらのアクセス モードを知る必要がある。各適用可能なモードのためのプロパティを繰り返し、[schema-org] accessMode プロパティにある適用可能な全てのアクセス モードを一覧にする。
コンテンツのアクセス モードは、提供された全ての適応が反映されないことに注意されたい。例えば、漫画が各画像の代替テキストもまた格納する場合、それはテキストのアクセス モードを持たない。コンテンツを他のモードで消費することを許可する利用可能な適応を示す方法の十分なアクセス モードについては次のセクションを見よ。
このプロパティとその値に関する詳細情報は、[schema-org] に定義される accessMode を参照されたい。
EPUB 出版物を消費するための十分なアクセス モードは、基本的なアクセス モードよりも潜在的なユーザビリティの広範な状況を表す。基本的なアクセス モードが、出版物で使用されているメディアのデフォルトの性質を識別する場合、十分なアクセス モードは、ユーザーが出版物全体を読むために必要なモードまたはモードのセットを識別する。十分なアクセス モードは、提供されたアフォーダンスとアダプテーションを考慮し、ユーザーが、そのコンテンツがデフォルトの性質にかかわらず利用可能かどうかを判断することを可能にする。
十分なアクセス モードは、[schema-org] accessModeSufficient プロパティで識別される。十分なアクセス モードの各セットのためにプロパティを繰り返す。
例えば、全ての画像のための説明だけでなく、グラフィックやチャートを含む EPUB 出版物も考慮する。出版物は、テキストと視覚コンテンツの両方を持ち、製作者は、これを示すために次のメタデータのエントリを格納するだろう。
<meta property="schema:accessMode">textual</meta>
<meta property="schema:accessMode">visual</meta>このメタデータは、テキストのアクセス モードが出版物全体を読むのに十分であるかどうか、または視覚的なアクセス モードが、二つのモードのみがデフォルトで必要かどうかを明確にしていない。この不一致が、十分性を知ることも重要である理由である。
製作者が入力した十分なメタデータの最初のセットは、テキストと視覚の要求事項を確立するであろう。
<meta property="schema:accessModeSufficient">textual,visual</meta>アクセス モードを記載する順番は、重要ではない。唯一の要求事項は、カンマで区切ることである。
製作者は全ての画像のための説明もまた格納していたので、製作者は純粋にテキストのアクセス モードがコンテンツを読むのに十分であることも示すことができる。
<meta property="schema:accessModeSufficient">textual</meta>このメタデータがないと、ユーザーはテキスト コンテンツを介してのみ出版物を読むことができるということを知らされないであろう。
visual の十分なアクセス モードは、コンテンツが全て画像ベースでないため提供されない。テキスト コンテンツ、視覚的及び聴覚的（音声合成）の両方で読むことができるので、別のモードと見なされる。テキストのない写真集は、純粋に視覚的なアクセス モードの作品の例であろう。
この例におけるエントリの完全なセットは、以下のとおりである。
<meta property="schema:accessMode">textual</meta>
<meta property="schema:accessMode">visual</meta>
<meta property="schema:accessModeSufficient">textual,visual</meta>
<meta property="schema:accessModeSufficient">textual</meta>アクセスの十分は、多くの場合、情報はテキストを理解するために不可欠であるという理解に基づく、著者の主観的な判断であることに注意されたい。例えば、一部の情報損失は、動画を見ることができないことによって発生するが、製作者は、転写物が伝達された概念を理解するために全ての必要な情報を提供する場合、取るに足りないとして視覚的または聴覚的な損失を見なすかもしれない。
このプロパティと値に関する詳細な情報は、[schema-org] に定義される accessModeSufficient を参照されたい。
[schema-org] に定義されている accessModeSufficient プロパティは、（例えば、値リストの定義と人間が可読可能な概要の格納など）EPUB 2 又は EPUB 3 のパッケージ ドキュメントで表現できる以上の、より複雑な表現を可能にする。EPUB の将来のバージョンでは、より豊かなメタデータが可能になるかもしれないが、このセクションに示されている基本的な表現は、発見の目的には十分である。
EPUB 出版物に格納されている全てのアクセシビリティ機能と適応を識別することは、ユーザーがコンテンツはアクセス モードよりもきめ細かいレベルで使用可能であるかどうかを判断することができる。
例えば、数学の教科書は、テキストのアクセス モードを持つかもしれないが、それだけでは MathML のマークアップが利用可能かどうかを示すものではない。ビジュアル作品が代替テキストのみを提供しているのか拡張された説明を格納しているかどうかは、ユーザビリティを正確に判断するときに知るためにも重要である。
アクセシビリティ機能は、[schema-org] accessibilityFeature プロパティで識別される。機能毎にこのプロパティは繰り返す。
EPUB フォーマットは、（例えば、目次など）いくつかのアクセシビリティ機能が常に存在ことが必要である。ユーザーは一般的に、フォーマットに組み込まれている機能が何であるか気づいていないので、アクセシビリティ メタデータからそれらの機能を除外してはならない。エントリの格納をしないと、ユーザーが特定の機能で検索をするとき、出版物の発見可能性は減少するだろう。
このプロパティとその値に関する詳細情報は、[schema-org] に定義される accessibilityFeature を参照されたい。
デジタル コンテンツの読者に影響を与える三つの広く認識された危険性がある。
閃光 — （例えば、動画やアニメーションなど）リソースが、1秒間に3回以上閃光する場合、それは発作を引き起こす可能性がある。[WCAG2] ガイドライン 2.3 も見よ。
動作シミュレーション — （例えば、ビデオ ゲームが [HTML] canvas 要素に描画されるなど）リソースが動作をシミュレートする場合、ユーザーは吐き気を引き起こす可能性がある。
音 — ベルの鳴る音やブザーの音など特定の音のパターンは、発作を引き起こす可能性がある。
製作者は、実際に物理的な影響を引き起こす可能性があるため、ユーザーに対してこれら危険性の全てを表現するリソースが、EPUB 出版物に含まれているかどうかを報告する必要がある。
危険性は、[schema-org] accessibilityHazard プロパティで識別される。それぞれの危険性に対してこのプロパティを繰り返す。
他のアクセシビリティ プロパティとは異なり、危険性の存在は、正と負の両方を表すことができる。この設計は、ユーザーが最も頻繁に、彼らに影響を与える危険性を取り除いたコンテンツの検索をするために決定されたが、彼らが検出する任意の出版物に存在する危険性が何であるかを知ることも望まれた。
EPUB 出版物は、リスクが存在する可能性のある任意のコンテンツを含んでいないという理由で、危険性の報告を省略してはならない。メタデータが存在しないと、ユーザーは意味を推測することができない。値「none」は、それぞれの非危険性を繰り返す代わりに、使用することができる。
EPUB 出版物が危険性を含んでいる場合、アクセシビリティ サマリーにあるソースと性質に関する追加情報を提供する。
危険性を明確に決定できない場合、値「unknown」を報告されたい。
このプロパティと値に関する詳細情報は、[schema-org] に定義される accessibilityHazard を参照されたい。
アクセシビリティ サマリーは、EPUB 出版物のアクセシビリティ特性又は不足を、簡素で人間が可読可能な説明で提供する。
EPUB 出版物が [EPUB-A11Y-11] にあるコンテンツのアクセシビリティ要求事項を満たしていない場合、その不足の理由を要約に書き留めるべきである。
アクセシビリティ サマリーは、[schema-org] accessibilitySummary プロパティを使用して提供される。
他の言語で要約が含まれていない限り、このプロパティは繰り返さない。複数の要約の場合、言語を区別するために、xml:lang 属性を使用する。
このプロパティに関する詳細情報は、[schema-org] に定義される accessibilitySummary を参照されたい。
schema:accesibilityAPI プロパティの使用は、EPUB 出版物においてもはや必要ない。製作者は、リーディング システム及び基礎となるプラットフォーム API 間の相互作用について責任を負わない。
[WCAG2] の要求事項を満たすことは、このプロパティが文書構造又はコントロールの識別に使用される ARIA マークアップを区別しないため、スクリプティングのアクセシビリティにおけるより良い基準となる。
schema:accesibilityControl プロパティの使用は、EPUB 出版物においてもはや必要ない。このプロパティは、リーディング システム インターフェースから発生するイシューと基礎となるコンテンツのイシューを区別しないため、その使用についての混乱が生じている。
[WCAG2] の要求事項を満たすことは、コンテンツに関する多くの既知のイシューを軽減し、オーサリングの目的としては十分である。
次の例は、テキストと、テキストとして読むために十分である視覚的なアクセス モードを持つ EPUB 出版物に追加されたメタデータを示し、代替テキストと MathML マークアップ、閃光の危険性が含まれている。
[WCAG2] の要求事項を満たすための達成方法集は、WCAG 達成方法集集に定義されている。このドキュメントは、これら達成方法集を繰り返さない。
一般的に、ウェブ ページ上の WCAG 達成方法集の適用と EPUB コンテンツ ドキュメントへの適用の違いは最小限だが、次のセクションでは、いくつかの重要な相違について説明する。
WCAG 達成方法集は、一般的に EPUB 出版物で検出される以上の技術とコンテンツ タイプの広大な範囲をカバーするので、多くを適用できないことが注意点である。
次の達成方法集のセットは、EPUB コンテンツ ドキュメントへ適応可能である。
他の達成方法集は、（例えば、EPUB 2 の [SWF] ビデオなど）使用されている技術や EPUB 出版物に埋め込まれた（例えば、PDF フォームなど））任意の代替フォーマットに応じて適応されるだろう。
[WCAG2] に詳しくない製作者は、できるだけソリューションを広範囲に提供することを意図しているため、達成方法集の数が膨大になるかもしれない。
EPUB コンテンツ ドキュメントにこれら達成方法集を適用する支援は、次のソースから入手可能である。
DAISY Accessible Publishing Knowledge Base — 適用可能な WCAG 達成方法集へのリンクのある、コンテンツ タイプごとのベスト プラクティスの概要。
BISG Quickstart Guide to Accessible Publishing — コンテンツをアクセシブルに制作するための最高のプラクティスを格納する。
[WCAG2] 達成基準 1.3.2 は、各ウェブ ページに意味のある順序が存在することを指定しているが、EPUB 出版物のコンテンツは、典型的に複数のドキュメントに及ぶ。それ故に、各 EPUB コンテンツ ドキュメントだけでなく、ドキュメントからドキュメントの順序も意味があることが重要である。
製作者は、全ての EPUB コンテンツ ドキュメントがスパイン [EPUB-3] に格納されており、読み取り順序が維持されるよう順番に置くことを保証する必要がある。
製作者はまた、リーディング システムがそのようなコンテンツを最適に表現できるよう、linear 属性 [EPUB-3] を使用し、主要または補足的な情報を含むスパインの項目であろうとなかろうと識別することを保証する必要がある。
[WCAG2] 達成基準 2.4.5 は、ウェブ ページのセット内のウェブ ページを見つけるために、複数の方法が存在することを要求している。デフォルトでは、EPUB 出版物は、製作者がスパインに全ての EPUB コンテンツ ドキュメントを格納し、全ての非線型ドキュメントへのアクセスを保証する [EPUB-3] EPUB 要求事項に従うのであれば、この WCAG 要求事項を満たす。
EPUB 出版物がこれらの要求事項を満たす理由は、ユーザーが EPUB 出版物内のドキュメントのセットとインタラクトする方法の違いに関係している。具体的に言うと、典型的に EPUB 出版物は、多くのコンテンツ ドキュメントで構成されているが、リーディング システムは、それらがスパイン [EPUB-3] に記載されているならば、自動的にあるドキュメントから次へとシームレスに移動するユーザーのための機能を提供する。ユーザーのために、EPUB 出版物は、進むためにリンクが必要な分離されたページのセットはなく、完全なアクセスを持つ単一のドキュメントである。
必須である目次は、出版物の主な見出しにアクセスするための第二の方法を提供する。ユーザーは、出版物がどのように分割されているかにかかわらず、任意の見出しにジャンプし、そこから移動を続けることができる。
従って、これら二つの要求事項を守ることにより、コンテンツにアクセスする複数の方法の必要性を満たす。典型的に、リーディング システムは、製作者が提供できない検索機能もまた提供し、そのようにして、ユーザーは多く場合、利用可能な第三の選択肢をも持つ。
製作者はこの基準を満たすためだけに、EPUB 要求事項に従う必要があるが、それらは最低限以上のアクセスを向上するための追加の方法を提供することが推奨される。いくつかの提案は、次を格納する。
可能な場合、目次にスパイン内の全てのコンテンツ ドキュメントへ少なくともひとつのリンクを追加し、
主要なトピックスを検索するインデックスを追加し、そして、
（例えば、図表のリストなど）EPUB ナビゲーション ドキュメントを支援するナビゲーションを追加する。
EPUB の目次に関するよくある質問は、出版物の見出しに関してどのような完全性が必要かということである。全てのセクションの全ての見出しを単純に集約するべきなのが明白な答えではあるが、実質的に、このアプローチにはいくつかのユーザービリティ上の課題がある。
デバイスのスクリーン サイズなどの要素は、見出しの階層が深い出版物の目次を読み難くするので、製作者は、読みやすさを保つために、一定の深さ以下にある見出しをトリムするであろう。 さらに、リーディング システムは常に、目次にある見出しへ構造化されたアクセスを提供するとは限らず、リンクをナビゲートするショートカットを提供するとは限らない。その結果、ユーザーは、どこに行きたいのか見つけるため、ひとつずつリンクを聞く必要があり、退屈で時間のかかるプロセスである。
リーディング システムは、EPUB のアクセシビリティ サポートが発展するにつれて目次へのアクセスが向上し、誰でも利用できる完全な目次を作成することが期待されているが、現在提供されていない正当なユーザビリティ上の理由がある。
しかしながら、製作者は全ての見出しへのリンクを提供しないことを選択した場合、全般的に最高の読書体験を提供するリンクの最適化をするべきである。これを達成する方法に関するいくつかの考慮事項は次を格納する。
全ての EPUB コンテンツ ドキュメントへのリンクがひとつ以上あることを保証する — ユーザーが各ドキュメントに到達できるようにすると、その中の小さな見出しへのナビゲーションが容易になり、そして、
目次からのマイナーな見出しのみを省略する — 主観的な判断だけれども、多くの場合、ナビゲーションの価値の減少にはレベルがある（例えば、第4レベルと下位の見出しは、しばしば、トピックの短いサブセクションを区切るだけである）。
目次は、ユーザーにコンテンツへのリンク以上のものを提供する。EPUB 出版物の構造と順序を理解する手段でもある。それ故に、ユーザーは、出版物のどこにいるのか、どこへ行きたいのか、又は目次の項目の順序が、直線的な読み上げ順序と一致しない時、前の場所に戻る方法を見つけるのに苦労するかもしれない。
従って、製作者は、目次の項目が常に、コンテンツの直線的な順序と一致することを保証するべきである。具体的には、項目の順序は、次の両方を反映させるべきである。
spine の EPUB コンテンツ ドキュメントの順序。及び、項目の代替の配置に論理的なケースがある場合にのみ、順序が異なるだろう。このようなシナリオは、典型的に、コンテンツを直線的に読む必要がない場合や目次の最後に追加情報が格納されている場合にのみ発生する。例えば、雑誌の目次は、全ての主要な記事を最初に、次に特集などを掲載するような順序になるかもしれない。
目次の順序がコンテンツと一致しない場合、製作者はアクセシビリティ サマリーにその理由の説明を格納するべきである。
製作者は、目次の最後に補足コンテンツへのリンクを格納することは避けるべきである。図、表、イラスト及び同様のコンテンツへのリンクは、別のナビゲーション要素（EPUB ナビゲーション ドキュメント又は spine のいずれか）として格納するのがよい。製作者は、目次にこれらの追加ナビゲーション リストへのリンクを格納できる。
[WAI-ARIA-1.1] role 属性は、支援技術へのホスト マークアップに関する追加のセマンティクス情報を提供するために使用される。ロールの使用により、支援技術はマークアップを自動的にスキャンし、ユーザーのためにランドマークの一覧を編纂し、コンテンツの主な機能への迅速なアクセスが可能になる。製作者は、全ての要素にこの属性を付けることができる。
role 属性は、EPUB リーディング システムの振る舞いを有効にするために追加のセマンティクス情報を提供する、type 属性 [EPUB-3] の性質に似ている。
これら属性の主な違いは、role 属性は、アクセシビリティを橋渡し、type 属性は、リーディング システムの振る舞いを有効にするためのフックを提供することである。言い換えると、ロールを省略すると、支援技術のユーザーのアクセシビリティは低下し、タイプを省略すると、（例えば、コンテンツのポップアップする脚注や特別なプレゼンテーションなど）リーディング システムの特定の機能が低下する。
各属性が異なる利益を提供するので、全ての読者へ良い読書体験を提供するために適用可能なときはいつでも、両方を使用することが推奨される。
多くの場合、属性は、類似するセマンティクスを持っている。このような状況では、両方の属性を要素に付けることが推奨される。
次のドキュメントは、両属性で使用するために利用可能なセマンティクスを記載している。
Digital Publishing WAI-ARIA Module [DPUB-ARIA-1.0] は、出版物ロールの中核のセットを提供するが、[WAI-ARIA-1.1] にある全てのロールが、role 属性で使用することができる。
EPUB Structural Semantics Vocabulary [EPUB-SSV] は、type 属性で使用することができるデフォルトの値を提供するが、属性は、他の語彙にあるセマンティクスを許可するために拡張されている。
次のドキュメントは、意味の変化のために EPUB 3 type 属性を使用することを既に慣れている製作者向けに ARIA ロールのアプリケーションを説明している。
EPUB Type to ARIA Roles Authoring Guide — 二つの属性間の顕著なオーサリング上の相違のガイドに加え、[DPUB-ARIA-1.0] 及び [WAI-ARIA-1.1] の等価な ARIA ロールに対する EPUB Structural Semantics Vocabulary の対応表を示す。
EPUB 出版物は読むときに、ユーザーに対して単一の連続的なドキュメンとして表示されるが、これらは典型的に、多くの独立した EPUB コンテンツ ドキュメントから構成されている。このプラクティスは、リーディング システムのロード時間を短縮するため（すなわち、ドキュメントが表示されるのを、ユーザーが待つ時間を最小限にするため）、レンダリングされた小さなマークアップの量を保持する。少なくとも本、EPUB 出版物は、コンテンツの全てがひとつのコンテンツ ドキュメントのみに含まれることは稀である。
コンテンツがこのようにチャンクされた場合、しばしば、製作者に情報を再構成する良い方法について決定が要求される。例えば、典型的に、ある部分は、それに属している全ての章を格納することはないであろう。その代わり、製作者は、各章の見出し部分で分割し、分割したドキュメントにそれぞれを配置するだろう。
視覚的にこれら再構築の決定は、読者から隠すことができるが、支援技術の機能性に影響を及ぼす。[WAI-ARIA-1.1] ロールの場合、結果は、現在読み込んでいる EPUB コンテンツ ドキュメント内に表現されるサブセットのみが、ユーザーへ見せられる。支援技術は、現在のドキュメントの外側を見ることができないので、出版物全体のランドマーク一覧を提供することができない。
この非構造化の影響を防ぐために、製作者は、（例えば、部品に属することを示すため章の周りに余分な [HTML] section 要素の追加したり、body タグにセマンティクスな部品を置いたりなど）全てのドキュメントにこの情報を持つことが、ユーザーの助けになると信じ、構築の再追加や再識別することを考えることがある。しかしながら、このプラクティスは全て、読む時に混乱するだけでなく、出版物の構造をより厳しくすることができる反復を追加する。したがって、製作者は、このような方法で構造を再構築することを推奨しない。
例えば、5つの部を持ち、各部は5つの章を含む本を検討する。構造的に、各章は次のマークアップのように、その部に属している（すなわち、グループ化されている）。
<section role="doc-part">
<h1>Part 1</h1>
<section role="doc-chapter">
<h2>Chapter 1</h2>
…
</section>
…
</section>これは肥大したコンテンツ ファイルの原因となるので、部の見出しは、それ自身のページとして表示されるように、それ自身のコンテンツ ドキュメント内で、典型的に分割される。
<html … >
…
<body role="doc-part">
<h1>Part 1</h1>
</body>
</html>各章は、別々のコンテンツ ドキュメントに分割されている。
<html … >
…
<body role="doc-chapter">
<h2>Chapter 1</h2>
</body>
</html>次の例のように、各章に部分的なラッパーを追加する必要はない。
<html … >
…
<body role="doc-part">
<section role="doc-chapter">
<h2>Chapter 1</h2>
…
</section>
</body>
</html>これにより、各ドキュメントに新しい part のランドマークが導入され、支援技術が、ランドマークがナビゲート可能であることをユーザーに通知するだろう。
[WAI-ARIA-1.1] ランドマークは、EPUB ランドマーク [EPUB-3] と本質的に似ており、両方とも、章や用語集、索引などの、ドキュメントの主要な構造へのすばやいアクセスを提供するために設計されている。ARIA ランドマークは、マークアップに適用されたロールから支援技術によって自動的にコンパイルされるため、製作者はユーザーが利用できるようにするためのランドマークのロールを格納する要求事項に従う必要がある。
ARIA ランドマークの自動生成はオーサリングを簡素化するが、それはまた ARIA ランドマークは、EPUB 出版物がコンテンツ ドキュメントにチャンクされている方法に制限されることを意味する。支援技術は、現在読み込まれているドキュメントで使用可能なランドマークのみを表示でき、複数ドキュメントの出版物にあるランドマーク全ての完全な図を提供することはできない（コンテンツのチャンクに関する詳細は、前のセクションを参照されたい）。
一方、EPUB ランドマークは、配布する前に製作者によってコンパイルされ、コンテンツ内の type 属性 [EPUB-3] の使用に直接リンクされない。リーディング システムは、ランドマークのために出版物全体をスキャンしないため、機械可読可能な方法で出版物の主要セクションへのリンクを容易にするよう設計されている。EPUB ランドマークは、ARIA ランドマークほど一般的ではなく、リーディング システムは、これらのナビゲーション支援の多くを紹介しているだけである。
しかしながら、活用の違いを考慮すると、ナビゲーションを容易にするために ARIA ロールの存在のみに依存せず、EPUB ランドマークの格納が重要であり、その逆も同じである。それぞれが、独自の方法でナビゲーションを支援する。
EPUB 仕様は、製作者が、ランドマークの特定のセットを格納することを要求しないが、全ての主要な参照セクション（例えば、目次、巻末注、参考文献、用語集やインデックスなど）と同様に本文の始まりへのリンクを格納することを推奨する。
次のリソースは、EPUB と ARIA ランドマークについて詳しく説明している。
EPUB 2 guide element
EPUB 3 landmarks nav
ARIA 1.1 landmarks
[WCAG2] 達成基準 2.4.2 は、各ウェブ ページにタイトルの格納を要求している。同様に EPUB は、EPUB 出版物の要求事項があり、出版物は、パッケージ ドキュメントのメタデータに [DC11] title 要素が必要である。しかしながら、[WCAG2] 要求事項は、EPUB 要求事項では満たされない。
EPUB 出版をオーサリングする場合、各 EPUB コンテンツ ドキュメントには、そのコンテンツに記述する説明的なタイトルも必要である。提供されていない場合、支援技術は大抵、ファイル名をユーザーに通知する。
（例えば、章の見出し部分や出版物の名前など）タイトルに構造的なコンテクストを格納する場合、現在のドキュメントの最も正確な記述が最初に来るようにタイトルを順序付ける。
タイトルに関するより詳細な情報は、達成方法 H25 を見よ。
コンテンツは多数の EPUB コンテンツ ドキュメントに分割されているにもかかわらず、ユーザーに対して、EPUB 出版物は最初から最後まで読む、単一のドキュメントとして表示される。結果として、実際のところ出版物は単一のドキュメントでないにもかかわらず、（例えば、ある部分の見出しが [HTML] h1 要素で表現される場合、その部分に属する各章は h2 の見出しを持つなど）出版物の全体的な階層における見出しの位置を反映しているというのが自然な期待である。
達成方法 G141：見出しを用いてウェブページを構造化するは、ドキュメント内で番号付き見出しを正しく使用することを製作者に指示しているが、EPUB 出版物の番号付き見出しは、ドキュメントを横断して一貫性を保つ必要がある。実質的に、最初の見出しがトップレベルの見出しでない限り、各 EPUB コンテンツ ドキュメントは、h1 見出しで始める必要がないことを意味し、最初の見出しには、出版物内における実際の位置を反映する番号付き見出しの要素を持つことが必要である。
製作者はまた、ドキュメント内の最初の見出しが、常にもっとも高い数字を持つように、コンテンツをチャンクする必要がある。例えば、ドキュメントが、h3 見出しで始まる場合、（例えば、前のサブセクションを引き継いで新しいセクションの開始を格納しないなど）ドキュメントの後に h2 見出しをつけるべきではない（should not）。最初と同じレベルで、それに続く見出しが存在することは可能である（例えば、あるドキュメント内の複数のサブセクションが、全て h3 見出しを持つことは可能である）。
これらの達成方法集の最初のバージョンは、画像の複雑さに関わらず、代替テキストのみが必須だった。この例外はもはや有効ではない。
製作者は、画像ベースのコンテンツが、[EPUB-A11Y-11] に準拠するために、代替テキスト及び拡張された説明の [WCAG2] 要求事項を満たしていることを保証する必要がある。
次のドキュメントは、拡張された説明を包含するためのガイダンスを提供する。
DIAGRAM Image Guidelines for EPUB 3 — 代替テキストと拡張された説明の格納の推奨事項。
[WCAG2] 達成基準 1.1.1 は、全ての非テキスト コンテンツがレベル A に合致するように同等のテキストが提供されることを要求する。（例えばアジアなど）一部の地域では、同等の Unicode 文字が提供できるにもかかわらず、個々のテキスト文字の画像を見出すことは珍しいことではない。このプラクティスは、例えば、古い文書の翻訳の容易さやリーディング システム全体の互換性など、さまざまな理由で発生する。しかしながら、多くのインスタンスでの画像の使用は、非視覚ユーザーがアクセスできないテキストに繋がる。
個々の文字が画像で置き換えられた時、代替テキストが提供されていても、（例えば、単語内のひとつの文字が画像で置き換えられている場合、その単語は、単一のテキストの単位として読むことができないなど）常にテキスト読み上げ（TTS）に悪影響がある。画像はしばしば、みすぼらしく拡大し、文字はユーザーの好みを満たす異なるフォント ファミリーに変更できないなど、視覚的なユーザーにとっても問題である。
全てのテキスト コンテンツのために Unicode 文字の使用は、この問題を回避し、コンテンツはレベル A の最小要求事項を満たすことができる。
レベル AA に適合するため、製作者は、必須のケースのみにテキスト画像の使用の制限を促進する達成基準1.4.5 に向けられる。
EPUB 出版物は、複数のレンディションで構成可能なため、コンテンツの異なるバージョンは、アクセシビリティの異なるレベルを持つ可能性がある。例えば、代替テキストや説明が欠落しているコンテンツの画像ベースのバージョンは、WCAG 準拠のテキスト ベースのシリアライゼーションにバンドルすることができる。[WCAG2] は、適合している代替バージョンが利用できるなら、非適合コンテンツを許可しているように、このアクセシブルなバンドル化のタイプは許容範囲である。
[EPUBMultipleRenditions-10] 仕様は、EPUB 出版物のこれらのタイプを作る機能のセットを定義している。ユーザーのために優先するレンディションを自動的に選択するか、または利用可能なオプションの中から手動で選択するためのオプションをユーザーに提供することをリーディング システムに許可する属性のセットを指定する。この機能は、ユーザーがアクセシブルなバージョンにアクセスできるよう担保する観点から、[WCAG2] の要求事項を技術的に満たしている。
しかしながら、実際には、[EPUBMultipleRenditions-10] 仕様は、出版時にリーディング システムで広くサポートされていない。その結果、複数のレンディションを含む EPUB 出版物を取得したユーザーは、初期設定のみにアクセスできる。このレンディションがアクセシブルなでない限り、EPUB 出版物はそれらによって読み取られないかもしれない。
したがって、製作者は、アクセシビリティ要求事項を満たすためにこの機能を実装するとき、最良の判断をする必要がある。少なくともひとつのレンディションがすべてのコンテンツ要求事項を満たす場合、複数のレンディションを含む EPUB 出版物は、[EPUB-A11Y-11] 仕様に適合しているが、製作者は、これらのアクセシビリティ サマリーに必要とされる複数のレンディションをサポートするリーディング システムが必要であることに最低限注意する必要がある。この依存関係を知らせるために、製作者が使用できる他の方法は、（例えば、配信メタデータ内など）が望ましい。
このセクションは、概括的にそれらの用途を推薦するために、リーディングシステムでの十分なサポートがあるとき、複数のレンディションを使用する達成方法集を更新するであろう。
EPUB Structural Semantics Vocabulary [EPUB-SSV] と Digital Publishing WAI-ARIA 1.0 Module [DPUB-ARIA-1.0] の両方は、静的ページ区切りのセマンティクスとして、それぞれ pagebreak と doc-pagebreak を格納している。
リーディング システムと支援技術との互換性を最大限に確保するため、両方のセマンティクスを EPUB 3 コンテンツに適用することを推奨する。
title または aria-label 属性は、ユーザーに通知される値を提供するため、要素に必要である。このプラクティスは、（例えば、文の途中でコンテキストが存在しない場合など）どこでそれが発生してもそのアナウンスを聞くことをユーザーへ強制するので、テキスト コンテンツとしてページ番号を格納しないよう。
EPUB 2 は、コンテンツ内の静的な改ページを識別するためのマークアップを格納していない。改ページの宛先は、ハイパーリンクを有効にするために格納することができるが、ページ リストは、ユーザーがその位置にジャンプすることができる唯一の方法である。
EPUB 3 出版物の改ページ位置を識別するために [HTML] a 要素を使用してはならない。以前、この要素はハイパーリンク先のアンカーとして定義されていたが、その目的はリンクとしてのみ使用されるよう [HTML] で変更されている。
読者は、新しいページ番号を確認するために読書を止めることはほとんどないので、ページ番号を出版物の音声再生中に読み上げると気を散らすだけでなく、（例えば、番号を文章の途中で読み上げるなど）混乱を招くことがある。
読者への潜在的な煩わしさを軽減するため、製作者は、EPUB 3 メディア オーバーレイ ドキュメント内に格納されているページのアナウンスを識別する必要がある。識別で、リーディング システムは番号を自動的にスキップする再生体験を提供できる。
EPUB 3 出版物のページ番号を識別するために、メディア オーバーレイ ドキュメントのページ番号を識別する各 par 要素 [EPUB-3] に値「pagebreak」 [EPUB-SSV] を持つ epub:type 属性を付加する。
EPUB 2 は、テキストと音声の同期を提供しないため、この達成方法は適用されないことに注意されたい。
ページ リスト — 静的な改ページ位置へのハイパーリンクのリスト — は、ユーザーが静的なページ位置を見つける最も効果的な方法である。ページリストがない場合、ユーザーはテキスト内の各ページマーカーを移動しなければならず、それらが利用可能であるならば、リーディング システムはそのような機能を提供するだろう。
ページ リストが格納されている場合、リーディング システムは、ユーザーにリストへの直接アクセスを提供し、自動的なページ ジャンプ機能を提供して使用することができる。
EPUB ナビゲーション ドキュメントは、page-list nav [EPUB-3] の格納を可能にするが、EPUB 2 NCX ファイルは、pageList 要素 [OPF-201] を介して同様の機能を提供する。
ユーザーは、典型的に、静的なメディアから生成された EPUB 出版物に格納された改ページ マーカーのソースを知りたいと思う。出版社またはインプリント（訳注：日本の出版文化に近い単語は「レーベル」）による印刷の考慮事項、ハードまたはソフト カバー版に由来する改ページかどうかは、（例えば、教室で使用されている印刷本の改ページと正確に一致する場合など）その有用性に関する決定に影響するだろう。
改ページの適合性をユーザーが判断できるようにするには、パッケージ ドキュメントのメタデータ内にあるソースとなる作品の ISBN を識別する。
ISBN が利用できない場合、（例えば、出版社や日付、版、製本など）ソースの出版物に関するできるだけ多くの情報を格納する。
改ページのマーカーが、EPUB 出版物に固有のものである場合、底本を特定しない。
典型的に、EPUB 出版物は、（例えば、オンライン書店を介して個別販売したり、図書館システムを介して配信することができるよう）配信時に出版社や著者の知的財産の保護を要求する。このニーズに対処する最も一般的な方法は、パッケージ化された EPUB 出版物へデジタル著作権管理（DRM）スキームの適応を通じてである。DRM は、単一のユーザーに対してアクセスを制限したり、（例えば、図書館内など）出版物にアクセスできる時間を制限する機能のような、EPUB 形式に固有ではない様々なセキュリティ機能を可能にする。
一般的に、DRM は、支援技術と相互運用可能であるが、DRM の制限で EPUB 出版物への直接的なアクセスが排除されたり、コンテンツへのアクセスが制限される問題を生じる。リーディング システムが、コンテンツへの API レベルのアクセスを提供しない限り、テキスト読み上げ（TTS）再生をもたらしたり、再生可能な点字ディスプレイが潜在するテキストにアクセスできるようにしたりすことは困難か不可能に等しく、他のアクセシビリティの課題が発生する。
したがって、デジタル著作権管理の適用は、ユーザーがアクセスの権利を持つ EPUB 出版物に対する支援技術の機能を減じたり、妨げてはならない。
EPUB 出版物が、書店や図書館などの配信システムに取り込まれる場合、メタデータ レコードは、しばしば、配信業者へ別々に提供される。このシナリオにおいては、出版物の発見を可能にするために使用されるメタデータは、通常、パッケージ ドキュメントのメタデータからではなく、配信レコードのみから取得される。
その結果、語彙が許す限り、配信レコードに多くのアクセシビリティ メタデータを格納する必要がある。
配信レコードの使用は、パッケージ ドキュメントにアクセシビリティ メタデータを格納する要求事項を排除しない。パッケージ ドキュメントのメタデータは、アクセシビリティ情報が、パッケージで常に利用可能であることを保証する。
配信レコードにアクセシビリティ メタデータを格納することに関する詳細な情報については、次のリソースを参照されたい。
この変更履歴は、EPUB 出版物の適合性に影響を与える、又は同様に — 注目すべき実質的な変更のみを識別することに注意されたい。
改訂中に取り組んだ全てのイシューのリストについては、ワーキング グループのイシュー トラッカーを参照されたい。
このセクションは規定ではない。
編集者は、この仕様に貢献してくれた EPUB3 ワーキング グループのメンバーに感謝する。