Pdf.js: タグ付きPDFのサポートを含める

[トリアージが必要]ラベルを追加しました。 タグ付きPDFに関連する開発には、新しいラベル（4-tagged-pdf）が必要ですか？

PDFの例はありますか？ 私は個人的にそのようなPDFを見たことがありません。 それらは実際にどのくらいの頻度で使用されますか？

はい、いくつかあります。

$ cd test/pdfs/
$ grep -rla '/Marked true'
i9.pdf
fips197.pdf
issue1169.pdf
smaskdim.pdf
issue3879.pdf
bug816075.pdf
pdf.pdf
issue1709.pdf
f1040.pdf
wdsg_fitc.pdf
annotation-border-styles.pdf
ecma262.pdf
bug887152.pdf
issue1133.pdf
issue2442.pdf
issue1796.pdf
type4psfunc.pdf

さらに必要な場合は、 https： //encrypted.google.com/search？q = filetype％3Apdf + "％2FMarkInfo" + "％2FMarked + true"

ありがとうございました！ その場合、これを調べることは間違いなく興味深いことです。

HTML属性とARIA属性を組み合わせて使用​​することでこれを実装するのは比較的簡単かもしれないと思います-レンダリングに変更を加える必要はありません-いくつかの新しい属性を追加するだけです。

PDFのタグ付け情報はStructTreeRootツリーに保存されます。このツリーには、代替テキスト、言語、セマンティックタイプ（H1、TH、LIなど）などのアクセシビリティ情報を含む構造要素が含まれています。 構造要素には、ページコンテンツストリーム内のオブジェクトへの参照が含まれています。 ここにこれを示すグラフィックがあります：
https://stackoverflow.com/a/34047585

次のようなものを使用して、PDFのタグ付け情報を_layoutText(textDiv)挿入できると思います。

1）レンダリングされているPDFオブジェクトのStructTreeRootツリーで対応する構造要素を検索します
2）構造要素の構造タイプがH1、H2、LIなどの場合は、divにrole属性を追加します。
3）構造要素に/ Altエントリがある場合は、divにaria-label属性を追加します
4）構造タイプH1〜H6の見出しレベルに対応するdivにaria-level属性を追加します

これにより、見出し、リスト、画像にスクリーンリーダーでアクセスできるようになります。 テーブルの実装はより複雑になる可能性があります。

PDF構造タイプは、セクション14.8.4.3にリストされています。 の
https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf

見出しの場合、レンダリングは次のように変更されます。

<span style="left: 173.529px; top: 237.049px; 
font-size: 5.99874px; font-family: sans-serif; 
transform: scaleX(1.05905);">
7.  Evaluation
</span>

これに：

<span style="left: 173.529px; top: 237.049px; 
font-size: 5.99874px; font-family: sans-serif; 
transform: scaleX(1.05905);" 
role="heading" aria-level="1">
7.  Evaluation
</span>

これはスクリーンリーダーによって「7.評価、見出しレベル1」として読み取られ、さらに重要なことに、ユーザーは「次の見出し」キーを使用して見出し間をスキップできます（これにより大きなドキュメントのナビゲートがはるかに簡単になります）

4-tagged-pdfラベルが削除されていることに気づきました。 これはまだ追求されているものですか？

未解決の問題は、検討中であることを示しています。 これは機能であり、ラベルは少し並べ替えられています。

うわー、それは素晴らしいです！ 検討中のこの機能には、タグ付きPDFの生成のサポートが含まれていますか？ 既存のPDFのパーサー/アナライザーのようなものの実装を容易にすることができますが、508cPDFの生成のサポートも提供します。

508c PDFの生成に必要なコア機能：

• ドキュメントにタグを付けます（言語とタイトル、場合によっては他のタグを付けます）
• PDF内の構造オブジェクト（ヘッダー、テーブル、th、td、リストなど）にタグを付けます
• ビジュアルメディア（画像、ビデオ、図など）に代替テキストを追加する
• 要素のタブ順序を作成/維持する

これら4つのコア機能が存在する場合、508cPDFを生成するロジックをPDF生成プロセスに実装することが可能です。 この機能がサポートされているOpenSourcejavascriptツールをまだ見つけていないので、正直なところ、これは巨大です。

これを書いた後、これが別の機能要求として適格であるかどうかはわかりません...その場合は、喜んで新しい問題を作成します。

私は@cuhallerとWCAG2.0のSC2.4.10および1.1.1へのコンプライアンスを向上させてきました。

この問題が実行する必要があることのサブセットには、変更で十分であると思います。 寄稿ガイドラインに従って、来週かそこらでPRを行います。 送信時にこのスレッドを更新します。

このリポジトリのheadings -and-img-alt-textブランチにあるます。

マスターとのマージの競合があり、現在それらを解決する時間がないため、PRを開くのをためらっています。

誰かがこのブランチをマスターと最新のものにするための可用性を持っているなら、連絡を取りましょう！

Edgeは、タグ付きPDFのネイティブサポートを宣伝しています。 Chromeもこれをサポートするようになり、タグ付けされたPDFをWebページからエクスポートする機能も宣伝されています。

現在、FirefoxはPDFのタグ付けをアクセシビリティツリー/アクセシビリティAPIに公開していません。 ただし、このテキストはFirefox80のます。

FirefoxをデフォルトのシステムPDFビューアとして設定できるようになりました。

ATに依存しているユーザーがこれを行う場合、またはユーザーの構成を知らないシステム管理者がこれを行う場合、Edge、Chrome、またはAdobeのReaderに依存しているユーザーがタグ付きPDFを解析するのは問題になる可能性があります。

80のリリースノートからアドバイスを削除し、このバグの優先順位を上げることを強くお勧めします。 私はMozillaが現在リソースに制約があることを理解していますが、競合するブラウザーでより適切に提供されるアクセスできない機能を促進するための光学は見栄えが良くありません。

私たちの組織は、支援技術のユーザーのためにアクセシブルなPDFソリューションを実装しようとしています。 セマンティックマークアップがないため、PDFJSでPDFをプレビューすることはできないという結論に達しました。 セマンティック情報の欠如は、スクリーンリーダーソフトウェアを操作するユーザーにとって障壁となります。 PDFはプレーンテキストで表示され、注釈をアナウンスしますが、見出し、表、画像、またはリンクにはマークアップは提供されません。

テーブルを取り巻くユースケースは、スクリーンリーダーのユーザーにとって特に困難です。 セマンティックマークアップがないテーブルは、ユーザーにコンテキストを提供せず、スクリーンリーダーユーザーがPDFに表示される情報を完全に理解することは不可能です。

リンクは特定のリンクテキストではなくURLとしてアナウンスされるため、リンクの目的を理解するのが困難です。 ユーザーがコンテキスト内のリンクを理解できるように、リンクはリンクURLの代わりに表示可能なリンクテキストを使用することをお勧めします。

このサポートがなければ、PDFJSを広く実装することに懸念があります。 セマンティックマークアップを提供する機能のサポートに関する更新またはタイムラインはありますか？ この問題は、コンテンツを認識して操作するユーザーの能力に影響を与えるため、より高い優先度と見なされるようお願いします。

私の知る限り、貢献は大歓迎です

これに取り組んでくれてありがとう

pdf.jsマスターで@trjohnstのブランチを手動でリベースし始めました。 このアプローチは、単一のレベルのみを必要とするタグに適しています。 例：見出しや代替テキスト付きの画像。 コンテンツストリームをウォークするときに、マークされたコンテンツシーケンスに遭遇すると、関連する構造要素を検索し、pdf.jsテキストレイヤーによって出力されるHTMLのテキストスパンに適切なARIAロールを配置します。

残念ながら、これはネストされたタグを必要とするものには十分ではありません。 例：リストまたはテーブル。 少なくとも多くのトリッキーなエッジケースがなければ、アプローチを拡張してそれらをカバーすることはできないと思います。 さらに、リンクとフォームフィールドを適切にサポートするには（ @trjohnstの投稿時にフォームフィールドがpdf.jsでサポートされていなかったことに注意してください）、アノテーションレイヤーだけでなく、アノテーションレイヤーも考慮する必要があります。テキストレイヤー。 さらに前向きに考えると、タグなしPDFの見出し、リンク、テーブル、フォームフィールドなどを検出（および正しく配置）するためのヒューリスティックを実装できると便利です。

テキストレイヤーでこれを実行しようとするのではなく、構造ツリーをウォークし、それに基づいてノードをレンダリングし、出力する要素にARIAプロパティを設定する必要があると思います。 構造ツリーは、テキストレイヤーと注釈レイヤーの両方のデータを参照できます。 構造ツリーに基づいてテキストと注釈レイヤーのDOMノードを並べ替えることができます（視覚的なレンダリングを壊さずにトリッキーかもしれませんか？）、またはaria-ownsを使用して、DOMを並べ替えずにa11yツリーだけを並べ替えることができます。

アーキテクチャ的には、テキストレイヤーとアノテーションレイヤーがすでに別々にレンダリングされているため、これは注意が必要です。次に、両方のノードを移動（または参照）できる構造ツリーである3番目のレイヤー（または少なくとも真実の情報源）を確認する必要があります。他のレイヤー。 これを行う最も簡単な方法は、おそらくすべてのマークされたコンテンツシーケンス（テキストレイヤー内）とリンク/フォームフィールド（注釈レイヤー内）にIDを添付することです。 フォームフィールドには、IDを指定するデータ属性がすでにあるようです。 aria-ownsを使用する場合は、とにかくid属性を設定する必要があるため、1つのスコーンで2羽の鳥に餌を与える可能性があります。 idは、新しい構造レイヤー内から、テキストレイヤーとアノテーションレイヤーの外側から計算できるものである必要があります。 構造ツリーを処理するときは、構造要素の要素を出力し、IDに基づいてテキスト/注釈レイヤーから要素を移動/所有します。

タグ付けされたPDFを超えてヒューリスティックに移行するには、次のようなことができる必要があります。リンクまたはフォームフィールドの注釈が与えられた場合、その長方形はテキストレイヤー内の何かを包含しますか？ 含まれている場合、注釈はそのテキストに関連付ける必要があります（aria-ownsまたはDOMmove）。 繰り返しになりますが、テキストレイヤーと注釈レイヤー（およびそれらの入力）が分離されており、使用できるこれらのレイヤーからキャッシュされた状態がないと思うため、これはアーキテクチャ的に注意が必要です。 ただし、テキストレイヤーと注釈レイヤーによってレンダリングされたノードの境界を確認できる可能性がありますが、それによってコンテンツとプレゼンテーション処理の間のアーキテクチャ上の境界があいまいになり始めます。

タグ付きPDFの最初の実装は、必ずしもヒューリスティックをサポートする必要はありませんが、これをアーキテクチャ設計の一部と見なすことを強くお勧めします。 現実には、タグなしのPDFは残念ながら非常に普及しており、これらをよりアクセスしやすくすることを許可しないアーキテクチャに固定されるのは悲しいことです。 （Acrobat Reader、およびそれほどではないがChromiumは、ヒューリスティックを使用して、タグなしPDFをよりアクセスしやすくしようとしていることに注意してください。）