3.1 なぜ schema.org メタデータが選択されたのか？

Schema.org メタデータは、EPUB のメタデータ モデルに適合する包括的な一連の記述メタデータを提供するので、パッケージ ドキュメントに必須である。

EPUB は、Open Web Platform と融合し続けるので、（schema.org メタデータは、情報をカタログ化する時に、主要な検索エンジンによって使用される）規格の将来のバージョンにも安定して適合することを表している。

3.2 なぜ ONIX は、検出のメタデータに必要ないのか？

ONIX は、電子書籍の流通チャンネルにおける重要なメタデータであるものの、EPUB 出版物は、本である必要はなく、主要な電子書籍チャンネルを介して流通されている。ONIX レコードの包含を全ての EPUB コンテンツの製作者に要求すると、制作が複雑になり、アクセシビリティ メタデータを包含することから製作者を遠ざけるかもしれない。ONIX レコードを作成および編集できるオーサリング ツールと情報を取得するためにレコードを解析するリーディング システムが必要になるであろう。既存のエコシステムへの影響を最小限にし、メタデータを常に容易に検索できる方法で利用できるようにするため、schema.org メタデータが選択された。

パッケージ ドキュメントで schema.org メタデータを選択しても、ONIX レコードのリッチなアクセシビリティ メタデータの必要性は損なわれるものではなく、これらは、EPUB 出版物に添付する全ての配信レコードにアクセシビリティ メタデータを包含するための要件である。

アクセシビリティ グループは、同様の情報を、フォーマットを横断してエンコードできるように、将来の目標として、これらのアクセシビリティ語彙に調和するために様々なメタデータ機関に働き掛けることを予定している。

3.3 私の検出可能な出版物をアクセシブルと呼ぶことはできますか？

あなたの出版物が、検出可能性のメタデータのみを包含している場合（つまり、アクセシビリティ要件を満たさず、最適化ではない）、それは、この仕様を通じてアクセシブルであると宣伝してはならない。

検出の要件を満たすことで、読者は、コンテンツを自分で利用できるかどうかを判断できるが、それ自体は認識しておく必要がある成果ではない。

4.1 これら全ての要件を満たすことができない場合はどうなりますか？

製造方法を変えることは決して簡単ではないが、達成を開始するために満たす明確なベンチマークも必要である。EPUB ワーキング グループは、これらの要件を満たす能力は、製作されたコンテンツの性質と、それがどのように作られたかによって変わると理解している。

ワーキング グループはまた、コンテンツのユーザビリティを損なうことなく、できるだけ行動を緩和する仕様もまた計画された。例えば、仕様は、多くの規制の枠組みが、ウェブ コンテンツ（そのような管轄においては、出版社はすでに、より高いレベルを満たす必要がある）にレベル AA 適合を要求しているけれども、WCAG 2.0 レベル A 適合のみ要求している。適合は、出版社がプロセスを改善している間、アクセシビリティが流通の障壁とならないように、EPUB 出版物が妥当であるための強制ではない。

ワーキング グループは、従うルールの選別と選択の試みは、特定の視聴者のみアクセシブになるコンテンツに繋がり、そして、それらの視聴者が誰であるかを証明することは複雑な作業であるため、閾値を WCAG 適合以下に下げることはできない。

制作品質の向上に関する核心は、なぜ検出のメタデータの包含が非常に重要かにある。出版社は、コンテンツが仕様に対して完全に準拠しているか述べることができないかもしれないが、実施された作品を表面化できる場合、ユーザーはそれがいつでも自分のニーズを満たすかどうかについて決定できる。

4.2 この仕様は WCAG の拡張ですか？

いいえ、WCAG を利用し、追加の要件を包含しているが、公式の拡張ではなく、それらの一つとして参照するべきではない。

4.3 なぜ WCAG に EPUB の要件を含めないのですか？

IDPF は将来的に、デジタル出版物のアクセシビリティを調和させるために、W3C および Web Accessibility Initiative と協力する予定である。

異なる改訂スケジュールと EPUB 出版物の適合性要件を確立する必要性のために、EPUB ワーキング グループは、別々のアクセシビリティ仕様を追求することに決定した。

4.4 なぜテクニックの中でいくつかの HTML 要素だけのガイドラインがあるのですか？

テクニクス ドキュメントは、WCAG 2.0 の要件を重複していない。ガイダンスが出版物によって異なる場合、またはガイダンスが存在しない場合のみ対処する。

4.5 掲載されていないコンテンツをアクセス可能にする他の方法の場合はどうなりますか？

EPUB Accessibility 仕様および WCAG 2.0 の両方のテクニクス ドキュメントは、本来は助言である。新しいテクニクスは、新しい状況へ対処するため、常に開発されている。新しいテクニクスで、アクセシビリティの同じレベルを提供する場合、それは利用において受け入れることができる。

4.6 要件のチェックリストはありますか？

（例えば、包含されるコンテンツの形式に応じて）適合性の要件は出版物毎に変わるため、テクニクスは、チェックリストを包含していない。

検証を処理するドキュメントは、適合性の要件をチェックするガイドとして、現在開発中である。さらに、ソフトウェアは、処理を支援するために開発している。検証の処理とソフトウェアを一緒に使用する場合、特定のテストには依然として人間の知性が必要になることが予想される。

4.7 なぜ適合性のメタデータは URL なのですか？

a11y:conformsTo プロパティ（訳者注：リンク先変更）は、適合性のステートメントを常に同じにできるように URL を取得し、（例えば、検証や、流通システムへの取り込みなどのために）機械によるチェックを容易にできる。

適合性に関する人間が可読可能なステートメントは、schema:accessibilitySummary プロパティ（訳者注：リンク先変更）に包含されている。EPUB Accessibility 仕様は、そのようなステートメントに対する言い回しを要求していない。

5.1 なぜ最適化を特定するのですか？

最適化の識別は、検出のメタデータの重要性と紐付いている。特定のユーザー グループのアクセシビリティ要件を満たすコンテンツは、たとえコンテンツが（例えば、点字や音声に最適化した出版物など）広くアクセシブルを考慮していなくても、それらのグループによって検出可能である必要がある。

コンテンツが適合しているサードパーティの標準を識別することで、不足しているコンテクストをユーザーに提供する。

5.2 どのように最適化の標準を識別するのですか？

サードパーティ標準への適合性は、標準が定義されている場所を指す URL を持つメタデータに、リンク タグを包含することで識別される。

<link
   rel="a11y:conformsTo"
   href="http://www.daisy.org/guidelines/epub/navigable-audio-only-epub3-guidelines"/>

前述の例は、ナビゲーション可能な音声のみの出版物に対する DAISY ガイドラインに適合する出版物を示している。

さらに、schema:accessibilitySummary プロパティ（訳者注：リンク先変更）で、適合性の人間が可読可能な要約を包含することが推奨される。

5.3 最適化された出版物をアクセシブルと呼ぶことはできますか？

EPUB Accessibility 仕様は、最適化を支持するものではなく、メタデータ内でそれらを識別する方法のみを扱う。

最適化のアクセシビリティに関するいかなる主張も、EPUB Accessibility 仕様または IDPF を参照してはならない。そのような主張は、出版物が適合している規格およびその標準を作成した組織を識別するべきである。

5.4 なにが最適化の標準レジストリですか？

IDPFは、識別子の検索を容易にするため、既知の最適化の標準レジストリを管理している。

このリストは、情報提供のみを目的にしている。IDPF は、最適化の標準を開発しておらず、それらの使用の支持も推奨もしていない。

5.5 標準を登録する必要はありますか？

いいえ、レジストリは、規定ではない。唯一の要件は、コンテンツが適合する標準を識別することである。

5.6 どのように標準を登録するのですか？

新しい標準の包含は、GitHub リポジトリのイシューを開くことで登録できる（GitHub アカウントが必要）。高度な GitHub ユーザーは、レジストリ ページ（訳者注：リンク切れ）を直接更新して、プル リクエストをすることもできる。

リクエストは、標準に関してできるだけ多くの情報を提供するべきである。