> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/ja/sononotopikku/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md). # タグ付きPDFファイル入門: 内部構造とアクセシビリティの課題 ## 更新：2026年1月 こちらをご覧ください [Overleafのタグ付きPDF作成手順](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs). この [LaTeXチーム](https://latex-project.org/) PDFのアクセシビリティにおける中心的要件である自動PDFタグ付けを可能にする新機能をリリースしました。これらの新機能はOverleafの [TeX Live 2025](http://\(https//www.overleaf.com/blog/tex-live-2025-is-now-available)、さらに新しい更新は、次を通じて利用できるローリング版TeX Liveリリースで利用できます [Overleaf Labs](https://www.overleaf.com/labs/participate). 今では、次に従うことで、WCAG 2.1レベルAAに準拠したタグ付きPDFをLaTeXソースから作成できます [ユーザードキュメント](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs) Overleafで利用可能なTeX Liveリリースを使用して。 以下の2020年の記事は、LaTeXアクセシビリティに関する最新情報は反映されていませんが、参考として、またPDFタグ付けの背景情報として引き続きお読みいただけます。 *** ## この記事では何を扱いますか？ この記事の目的は、タグ付きPDFの入門と、タグ付きでアクセシブルなPDFファイルの作成を目指すTeXエンジンやLaTeXを含むソフトウェアが直面するいくつかの技術的課題の概要を提供することです。アクセシビリティ、とくにPDFのアクセシビリティは幅広く複雑なトピックであり、PDF内の複雑な数式をアクセシブルに表現する方法のように、技術的課題には必ずしも単一で普遍的に合意された、または受け入れられた解決策があるとは限りません。MathMLを使うのか、LaTeXコードを使うのか？ すべてのトピックを深掘りし、細部の多くを簡略化することはできませんが、PDFの内部を見て、PDFをタグ付けすることが実際に何を意味するのかを示すことはできます。Overleafは、この記事が役立つ入門として機能し、読者が技術的課題をよりよく理解し、タグ付きPDFとアクセシビリティについてさらに読み進め、探求するための十分な背景知識を提供できることを願っています。この記事内の資料には次が含まれます： * [8分の動画](#video-showing-the-logical-structure-of-a-tagged-pdf) LaTeXによって作成されたタグ付きPDFを探るもの； * [Overleafプロジェクト](#using-luatex-an-example-in-the-overleaf-gallery) LuaTeXにおけるスペース文字の使用を探るためのもの； * [音声録音](#tagged-yes-but-the-reading-order-is-incorrect) PDFのアクセシビリティ上の問題を示すもの。 ## はじめに デジタルコンテンツのアクセシビリティを確保することは、コンテンツの制作と配信における重要な側面として当然ながら認識されています。さらに、次を含む各国政府も [英国](https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps) と [米国](https://www.hhs.gov/sites/default/files/Intro%20to%20Accessibility%20and%20508.pdf)、自国の管轄下で作成されたコンテンツに定められたアクセシビリティ基準への準拠を求める法律を制定しています。HTMLでコンテンツを配信することで準拠するのはそれほど大きな負担ではありませんが、PDF形式で配布される文書に必要なレベルのアクセシビリティを確保することは、PDFファイルとして出力されるコンテンツを作成するために使用するソフトウェアによっては、重大な技術的課題となり得ます。 PDFは1990年代初頭、信頼性の高い文書転送をめぐる問題の解決策として登場し、歴史はその大成功を示しています。しかしPDFは、文書内容のアクセシビリティを促進する必要性が広く認識・受容される以前に生まれた複雑なファイル形式でもあります。それでも時とともにPDF仕様は進化し、Adobeが呼ぶ「様式化された」PDFの一種を用いて、アクセシブルなPDF文書の作成を可能にし支援する機能を提供するようになりました *タグ付きPDF*. 実際には、タグ付き—*かつ完全にアクセシブルな*—PDFファイルの作成は、PDFを出力するソフトウェアに大きな追加の技術要件を課します。これにはTeXエンジンや、マクロおよび追加のLaTeXパッケージからなるLaTeXエコシステムも含まれます。 ## 最終形のデジタル紙としてのPDFの誕生 この [Portable Document Format（PDF）の誕生](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) は、コンピュータ間での文書転送が困難に満ちていた時代に由来します。しばしば、ファイル変換によってページの再流し込みやその他の不一致が生じ、それが異なるオペレーティングシステム（特にWindowsとMacintosh）で使われる互換性のないフォントや文字エンコーディングによってさらに悪化していました。この文書の著者は当時出版業界で働いており、そうした課題に対処した鮮明な記憶があります！ PDFは、普遍的な最終形（編集不可）のデジタル紙を導入することでファイル共有の問題に対処するよう設計され、表示に必要なフォントを含む自己完結型文書をシームレスに転送できるようにしました。これにより、受信者がどのコンピュータ環境であっても開いて読めるという十分な確信をもって、あらゆる種類の文書をようやく転送できるようになりました。文書の忠実性は保たれ、煩わしいページ再流し込みやフォントの互換性／入手性の問題は過去のものとなりました。 ### デジタル紙：すべてのユーザーにとって良いもの？ デジタル紙の形態としてのPDFの系譜は、当然ながら、画面上でも紙上でも、その内容を視覚的にたどる手がかりとして、印刷されたページ番号、タイポグラフィ、またはデザイン要素の使用を前提としていました。しかし、そうした視覚的な手がかり／仕組みは、もちろん重度の視覚障害を持つ人々には無意味です。今日では、デジタルコンテンツのアクセシビリティ向上は、コンテンツの制作と配信における重要な側面として当然ながら認識されています。PDFにとっての課題は、もともと印刷ページの視覚的媒体を再現するために設計された「コンテナ」に閉じ込められたコンテンツへの非視覚的アクセスを促進する仕組みを提供することでした。 PDF仕様の最初の版（PDF 1.0）は [1993年6月15日に正式に公開され](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) その後、新版と更新が続き、2001年（PDF 1.4）には「タグ付きPDF」の導入が含まれ、これは [「…支援技術の利用者を可能にした」](https://www.adobe.com/accessibility/pdf.html)。その後のPDF仕様のリリースでは、PDFの機能が拡張・強化され、最新リリース（PDF 2.0）に至りました。これは、次に基づくと [報告](https://www.pdfa.org/tagged-pdf-2-0/)、アクセシビリティ機能が大幅に見直されています。ただし、PDF 2.0はまだTeXエンジンによるサポートが十分ではありません。 ## PDF内のコンテンツ 関連する問題を理解するには、PDFファイルが実際に含まれるページコンテンツをどのように表現しているかを調べる価値があります。PDFファイルの深部では、各ページのコンテンツはそのページの *コンテンツストリーム*：テキストや図形を特定のページ位置に配置し、使用中のソフトウェアによってレンダリング（表示）するためのPDF演算子（「コマンド」）の連なりです *表示する* PDFの中にあります。実質的に、コンテンツストリームは図形的な説明、つまり「レシピ」を提供し、PDF閲覧アプリケーションに各ページをどのように「描画」するかを指示します。すなわち、ページに何をどこに表示するかを定義します。当然ながら、その一連の演算子には、特定のサイズで特定のフォントを選ぶ、色を選択する、線幅を定義する、線や曲線を描く、といった指示が含まれます。ページを視覚的に提示するための完全な図形的説明に必要なすべてがそこにあります。 ファイルサイズを小さくするため、PDFのコンテンツストリームは圧縮され、コンパクトなバイナリ形式で保存されますが、Adobe Acrobat Pro DCのような適切なソフトウェアがあれば、ページのコンテンツストリームの「解凍された」プレーンテキスト版を表示できます。 PDF演算子がどのように表を「描く」かを考えてみましょう。PDFのコンテンツストリームには、水平線／垂直線を引き、異なるフォントを選択し、さまざまなページ位置にテキストを出力して表の内容を作り出すための適切な演算子列が含まれます。これを示すために、非常に単純なタグなしPDF文書を考えます。そこには基本的な表と少しのテキストしか含まれておらず、この記事の後半で理由が明らかになるようにMicrosoft Wordで作成されています。以下は、その単純なPDFを示すスクリーンショットです： ![Microsoft Wordで作成した表](/files/df17c8cadf30d24454aafb7b3ef5684fd39ff06e) このファイルの（解凍された）ページコンテンツストリームを抽出し、最初の数行をテキストエディタに貼り付けると、いくつかのPDF演算子を要約して、PDFファイルがこのページに表示されるコンテンツをどのように「記述」しているかの「雰囲気」をつかめます。 ![PDFファイル内のコンテンツストリームの画像](/files/ebbe680b1b3a483d6fc1397acd1d1f5e3f4149b6) Adobe Acrobat Pro DCを利用できるなら、PDFページのコンテンツストリームに含まれる演算子の一覧を表示できます。以下はAcrobatの *PDF内部構造* 同じPDFの表示で、基本的な表を含む1ページを「描画」するために使用された各演算子について1行の説明を示してくれます。なお、これらの短い説明はAdobe Acrobat Pro DCによるもので、PDFファイル自体には *実際の* 含まれていません： ![Adobe Acrobat Pro DCで表示したPDFコンテンツストリームの画像](/files/15072b949c3c1d6f110f5c2d4bbbf997a0978085) しかし、これらの描画指示（演算子）のいずれも、実際に生成しているものの「意味」や「説明」を保存していないことに注意してください。それらは単なる図形演算子の集合であり、結果として *視覚的に見える観察者が認識する* 表が構築されるだけです。明らかに、重度の視覚障害を持つ人にとって、PDFのコンテンツストリーム内のその図形演算子から生じる表を表示することは、その内容にアクセスするための実用的な方法ではありません。必要なのは、PDFファイルにその表、そしてもちろんPDFファイル内の各ページに含まれるその他すべてのコンテンツ項目について、適切な非視覚的（機械可読な）説明を含める仕組みです。 非視覚的にコンテンツへアクセスできるようにするには、PDFファイルには、特定のコンテンツを「描く」ために使われる演算子の集まりやグループに「意味」または意味論を付与する追加データが必要です。必然的に、この「意味」を割り当てたり与えたりする原則は、PDFに含まれるあらゆる形式のコンテンツに及ばなければなりません。その仕組みは存在し、 *タグ付け* PDFにタグを付けて、当然ながら次のように呼ばれるPDFの「変種」を作ります *タグ付きPDF*. ## タグ付きPDFの導入 タグ付きPDFとは、タグなしPDFファイルにはない追加データ（およびデータ構造）を含む特定の種類のPDFファイルの名称です。タグ付きPDFの背後にある原理や考え方は概略説明に向いていますが、詳細は複雑で、正式なPDF仕様の多数のページを占めています。 Adobeは、視覚障害のあるユーザーにコンテンツをアクセシブルにすることを含む、いくつかの目的を達成するためにタグ付きPDFを設計しましたが、それには次の一覧も含まれます。これは次の10.7節から [AdobeのPDF 1.7仕様](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf): * 他のアプリケーションに貼り付けるためのテキストや図形の簡単な抽出； * 元のレイアウトで想定したものとは異なるサイズのページに合わせて、テキストと関連図形を自動的に再流し込みすること； * 検索、索引付け、スペルチェックなどの目的でテキストを処理すること； * 文書構造と基本的なスタイル情報を保持したまま、他の一般的なファイル形式（HTML、XML、RTFなど）へ変換すること。 さらに、タグ付きPDFには次も必要です： * PDFコンテンツ内のテキストがUnicodeに変換できる形式で表現されること； * 単語の区切りは明示的に表現されなければなりません。なお、TeXエンジンは単語を区切るためにスペース文字を使わず、glueと呼ばれるTeXの柔軟な間隔を使います（下記参照）； * 実際の（「本物の」）コンテンツが、レイアウトやページ区切りの副産物と区別されること。 タグ付きPDFの基盤には、これから確認する2つの重要な概念があります： * PDFファイル内のコンテンツの論理構造を定義すること； * 標準的なコンテンツ型のセットによるPDFコンテンツのマークアップ（タグ付け）。 ## 論理構造 長い文書では、コンテンツは通常、より小さなコンテンツ項目の連なりに分割されます。たとえば、書籍は通常、章に分かれ、さらにその章は段落、表、図／チャート、箇条書きまたは番号付きのリスト、脚注、参考文献などを含む節や小節に分かれます。こうした書籍や他のあらゆる文書種類におけるコンテンツの構造と組織は、その *論理構造*. 文書の論理構造という概念はPDFのアクセシビリティにおいて重要な役割を果たしますが、概念としては少し曖昧で理解しにくいように思えるかもしれません。次の定義は [データベースシステム百科事典](https://link.springer.com/referenceworkentry/10.1007%2F978-0-387-39940-9_213) から、参考になる洞察を与えてくれます： > 「論理構造とは、文書内の情報がどのように整理されているかを指す。情報の階層と文書の各部分の関係を定義する。論理構造は、文書に何が含まれているかではなく、文書がどのように構築されているかを示す。」 この論理構造の定義は、正確に *どのように* その構造情報が物理的に保存されていることには触れていません。単に、文書の構造と組織の表現を提供するということです。文書の論理構造がどのように保存または表現されるかの正確な詳細は実装依存であり、それを生成・処理するソフトウェアに依存します。 ### PDFにおける論理構造 PDF仕様は、文書の論理構造をPDFファイル内に記録できる仕組みを提供しています。たとえば、PDFの内容をXML、HTML、Microsoft Wordなどの他形式に書き出したいソフトウェアが利用できます。そうした書き出し処理では、変換先のファイル形式の規則に準拠した、正しく構造化されたテキスト文書を生成する必要があります。その最も良い達成方法は、PDF内で提供される論理構造情報に基づいて書き出し処理を行うことです。 さらに、PDFファイルの論理構造は、たとえば視覚障害のある人に内容を読み上げる音声合成処理を行いたいアクセシビリティソフトウェアにとって不可欠です。読み上げ処理では、内容が正しい順序／順番で読まれるようにしなければならず、そうでなければ意味をなさない結果になります。また、ページという概念そのものが、PDFの内容と文書構造にのみ関心があり、視覚的な区切りやページサイズの塊としての表示には関心のないアクセシビリティアプリケーションにとっては、意味を持たない場合があることにも注意してください。 #### コンテンツ項目の命名 PDF文書の論理構造を記録（保存）するには、さまざまな *種類* 一般的なPDF文書の一部として見つかると考えられるコンテンツ項目に対して、意味のある名称を割り当てる必要があります。これには、見出し、段落、表、リストなどを表すコンテンツの区画を識別することが含まれます。さらに、目次、番号付き／箇条書きリスト、表形式の資料など一部のコンテンツ項目は、それ自体がかなり複雑な構造を持つため、それらのより複雑なコンテンツ項目がどのように構成されるか、その下位構造を指定するための指針／規則も必要です。さらに、PDFを処理する支援ソフトウェアによって無視されるべきPDFコンテンツを明確に識別する必要もあります。たとえば、ページのヘッダーとフッターはページ付けの副産物であり、重度の視覚障害のある人にとっては不要なテキストを含むため、そのコンテンツは無視されるべきです。 PDFが文書の論理構造を定義するために用いる仕組みは柔軟に設計されているため、原理的には、PDFファイルを生成・処理する異なるアプリケーションが、任意の慣例でコンテンツ型の名称を使うことができます。しかし、文書交換を最大化し、異なるPDF処理アプリケーションが一貫した結果を出せるようにするため、AdobeはPDF生成ソフトウェアが従うべきコンテンツ項目の種類に対する標準名のセットを定義しました。PDF仕様では、これらの標準名はタグと呼ばれ、その結果として *タグ付き* PDF。 ### PDFコンテンツのマークアップ：「内部」のぞき見 議論を少し抽象的でないものにするため、タグ付きPDFファイルの内部を簡単に見てみましょう。もっとも、タグ付きPDFは非常に大きく複雑な話題なので、すべての詳細を扱うことはできません。 #### マークされたコンテンツシーケンス：タグ付きPDFの構成要素 最も低いレベルでは、PDFページ内に含まれるコンテンツ（つまり、そのコンテンツストリーム内）の意味を記録する処理は、次から始まります *マークされたコンテンツシーケンス* これはPDF演算子の集まりやグループを識別し（「意味」を与え）るために使われます。マークされたコンテンツシーケンスには、その `MCID` (*マークされたコンテンツ識別子*）が割り当てられます。これは各ページで0からある最大値Nまでの整数です。これらの `MCID` 値は、特定のページのコンテンツストリーム内に含まれる演算子列を一意に識別する方法を提供します。明確に言えば、各ページごとに `MCID` 識別子は0から始まり、そのページのコンテンツストリームに含まれるマークされたコンテンツシーケンスの数に応じた最大値まで順に増加します。 マークされたコンテンツシーケンスは、実質的に、次と呼ばれるより高次のデータ構造を組み立てるための基本的な「構成要素」です *構造要素*。 #### 構造要素の例 ここでは少し先取りしますが、例を確認する価値があります。ページコンテンツの小さなテキスト断片が3つあり、それぞれがコンテンツストリーム内で異なるマークされたコンテンツシーケンスによって識別されているとします。その3つのテキスト断片はそれぞれ、タグ付きの独自の構造要素にまとめることができ、さらに3つすべてを別の構造要素を使って「リンク」し、目次の1行のようなより高次のコンテンツ項目を表現できます。 ![構造要素とマークされたコンテンツシーケンスを説明する画像](/files/88bd3a9705e7dcde321bead0c61ed12f4c476635) 親子関係の一形態によって、構造要素の集合が組み合わされ、番号付き・箇条書きリスト、表、数式など、より複雑なデータ項目を表す連結データ構造が作られます。最終的には、PDFファイル全体に含まれる構造要素の集合すべてがさらに相互にリンクされ、組み合わされてPDF文書の論理構造が作られます。これは記事の後半で再び取り上げます。 ### マークされたコンテンツシーケンスとは何ですか？ 上の議論では表を含む単純なタグなしPDF文書（Microsoft Wordで作成）を使いましたが、Wordにタグ付きPDFを作成させると、ページのコンテンツストリームに追加のマークアップが現れるのがわかります。ここではコンテンツストリームの最初の数行だけを見ています（数百行あります）が、次のような追加の演算子の存在に注目してください `/P <> BDC` や `EMC` これはマークされたコンテンツシーケンスを識別するために使われます。マークされたコンテンツシーケンスの完全な構文は扱いませんが、読者には次を参照してください：の862ページ [Adobeの公式PDF 1.7仕様](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf). ![タグ付きPDFコンテンツストリーム内のマークされたコンテンツシーケンスを示す画像](/files/d14deeb86dd9d889f9c7cf3ca0f816539bed5797) 参考のため、タグなし版も再掲します： ![PDFコンテンツストリームを示す画像](/files/ebbe680b1b3a483d6fc1397acd1d1f5e3f4149b6) その *タグなし* PDFでは、次のような演算子 `/P <> BDC` や `EMC` は存在しませんが、残りの演算子は変わりません。タグなしPDFには、特定の演算子列／集合を識別するための追加マークアップがありません。ここでもAdobe Acrobatの *PDF内部構造* 機能を使って、コンテンツストリーム内のマークされたコンテンツシーケンスを表示できます。ここでは緑の枠で強調しています： ![Adobe Acrobat Pro DCで表示したタグ付きPDFコンテンツストリーム内のマークされたコンテンツシーケンスを示す画像](/files/0d6126914876daf5e4b8b70e29a4af10a78abf90) いくつかのコンテンツは次でマークされていることに注意してください `/Artifact` これはPDFページ上の、次のように扱われるべき素材を識別します *無視される* 視覚障害のある人向けに読み上げるソフトウェアアプリケーションなどによって。 次のスクリーンショットは、最初のマークされたコンテンツシーケンスの拡大表示です。つまり、 `MCID` 値が `0`。 `EMC`. ![マークされたコンテンツストリームに含まれる演算子の詳細を示す画像](/files/164fdad2edfc342454cab41353d0f5179db357ad) ### 論理構造の保存 述べたように、個々のコンテンツ項目（段落、リスト、表など）の説明を提供することに加えて、アクセシブルなPDFには文書全体をその論理構造の形で表したものを含める必要があります。アクセシブルなコンテンツの個々の断片は、完全でナビゲート可能なアクセシブル文書を作るために相互にリンクされなければなりません。これは、1つのHTML文書が段落、図、表などから構成されてWebページを作るのに似ています。さらに、PDF文書の論理構造は、すべてのコンテンツが正しい *読み上げ順*でナビゲートできるようにすることが不可欠です。これは、ページコンテンツがPDFページのコンテンツストリームに書き出された順序とは独立しています。読み上げ順については以下で詳しく見ていきます。 #### 論理構造：構造要素の「ツリー」 PDFでは次 *構造要素* のものを使うことに触れました `StructTreeRoot` これは、文書の論理構造ツリーの開始点、つまり「ルート」として機能する構造要素を含む（指し示す）ものです。通常、構造ツリーの「ルート」は、タグが付けられた単一の構造要素から始まり `Document` その中に多数の *子* の構造要素が含まれ、それらが総体として文書全体の内容を表します。タグ付けによってアクセシブルなPDFを生成するよう設計されたソフトウェアは、この非常に複雑なデータ構造（および他の構造も！）を構築しなければなりません。これにはTeXエンジンやLaTeXも含まれます。 そのような文書構造ツリーの例（`StructTreeRoot`）は、Adobe Acrobat Pro DCで開いたタグ付きPDFの次のスクリーンショットに示されています： ![タグ付きPDF内のStructTreeRootを示す画像](/files/e3c9d51417fb2967211d9df3d32e2589288053cb) 上記の構造をタグなしPDF版と比較してください： ![タグなしPDF内でStructTreeRootがないことを示す画像](/files/0964a42e0b631cd750907c3674ea1e49b28601ef) ### PDFの論理構造を探る ここまで扱ってきた内容を要約する図から始め、最後にAdobe Acrobat Pro DCを使ってタグ付きPDFファイルの論理構造の詳細を示す動画で締めくくります。まずは、一般原理を示す概略図から始めます。つまり、マークされたコンテンツシーケンス（MCS）でマークアップされたコンテンツストリームを持つPDFページです。 ![PDF文書ページにおけるマークされたコンテンツシーケンスの概念を示す図](/files/2b199a92fcd03caf60e1580b8d1f6944af78c0ee) それらのMCSは、その後次へ組み合わされます *構造要素* それらは、さらに相互にリンクされてPDFの論理構造を次のオブジェクト内に保存する、より大きなコンテンツ型の基礎を形成します `StructTreeRoot`. ![タグ付きPDFファイルの論理構造を示す図](/files/d3d9f8388106aff1f286ac8f85723baca593d803) #### タグ付きPDFの論理構造を示す動画 次の動画（8分）では、Adobe Acrobat Pro DCを使って、LaTeXで作成されたタグ付きPDFファイルの論理構造の詳細を巡る「ガイドツアー」にご案内します。動画で使用されているタグ付きPDFファイルは `tagpdf.pdf`という、実験的なLaTeXパッケージの文書を含む優れた例です [`tagpdf`](https://ctan.org/pkg/tagpdf?lang=en)。その `tagpdf` パッケージの目的は、「pdfLaTeXとLuaTeXを用いてタグ付けとアクセシビリティを試すためのツールを提供する」ことです。 {% embed url="" %} ### タグ付けと柔軟性についての注記 HTML仕様は、ウェブページを構築するための多数の事前定義タグを提供しますが、それらを組み合わせて選んだHTML文書を作る方法にも柔軟性があります。同様に、Adobeのタグ付きPDF仕様も一式の事前定義タグ名を提供しますが、PDF内で複雑なコンテンツ項目を表現するためにそれらのタグをどのように組み合わせるかについては、ほとんど制約を課しません。設計上、非常に大きな柔軟性があります。さらに、PDFのように大規模で複雑な仕様では、文書化された仕様に曖昧さや不明瞭さが入り込むのは避けられません。そのような複雑な仕様の実装を任されたソフトウェア開発者は、書かれた説明を実際に動作するコードへ変換する必要があるため、解釈にあたって「判断を下す」必要があるかもしれません。 タグ付きPDF本来の柔軟性と、仕様（またはアクセシビリティ標準）の解釈は、当然ながら文書作成アプリケーションの開発者に影響します。タグ付きPDFファイルとして出力する際、ユーザー作成コンテンツを表すためにどのタグの組み合わせを使うべきなのでしょうか。文書作成ソフトウェアの機能を使ってユーザーがあらゆるコンテンツを作成できる無限の可能性を考慮すると、アクセシブルなタグ付きPDFの自動生成はかなりの難題であることがわかります！ アクセシビリティ標準に完全準拠したタグ付きPDFの作成には避けられない複雑さがあることの表れかもしれませんが、Web上には、Adobe InDesignやMicrosoft Wordなどのソフトウェアを使ってタグ付きPDFを作成するための「やり方」「ヒント」「ベストプラクティス」の助言があふれています。さらに、PDF Associationは次のような有用な文書を作成しています [Tagged PDFベストプラクティスガイド](https://www.pdfa.org/wp-content/uploads/2015/12/StructureElementsBestPracticeGuide_2016-01-19.pdf) これは、タグ付きPDFとPDF/UAの実装に取り組む開発者を支援するために書かれたものです。 ## PDFはあるけれど、アクセシブルですか？ あるPDFファイルがPDF/AやPDF/UA（下記参照）のような必要なアクセシビリティ基準に準拠しているかどうかを判断するには、それを *検証* 合意された検証プロセスまたはソフトウェアツールを使って行う必要があります。ただし、検証は通常、文書完成後に行われますが、その処理を行うのは文書の著者ではなく、準拠を求めた組織や団体内のアクセシビリティ専門家かもしれません。PDFが検証に失敗した場合、（可能であれば）Adobe Acrobat Pro DCを使ってタグ付けを修正するための熟練した手作業が必要になることがあります。あるいは、元の文書を修正するために著者へ差し戻されることもあり、その場合は問題を引き起こした作成ソフトの機能の使用を避ける必要があるかもしれませんが、これは著者の制御を超えている可能性があるため、実現が非常に難しいことがあります。 ### 読み上げ順とコンテンツ順 述べたように、真にアクセシブルなPDFの作成は、作成ソフトウェアに追加の技術要件を課し、場合によっては、作成ソフトウェアの機能の使い方／適用の仕方に「執筆上の規律」を求めることで文書著者にも影響します。タグ付きPDFは、次を可能にする仕組みですが *可能にします* 完全にアクセシブルなPDFの作成を、PDFにタグが付いているからといって *実際の* 自動的に完全にアクセシブルだという意味にはなりません。これは下の例で見ていきます。 完全にアクセシブルなPDFを作成するには、PDF内のすべてのコンテンツ項目にタグを付けて、コンテンツを正しい順序でアクセスし読み取れるようにする論理構造を作る必要があります。これは次のように呼ばれます *読み上げ順*。これは「当然」のように見えるかもしれませんが、ソフトウェアがPDFファイルを書き出すとき、図形とテキストをページのコンテンツストリームに任意の順序で出力できます。たとえば、あるページがテキストで始まり、次に表が続き、最後に図で終わるとすると、自然な *読み上げ順* 順序は次のとおりです： 1. テキスト 2. table 3. 図 PDFに書き出す際、そのページのコンテンツストリームを生成するソフトウェアは、表を描く演算子から始め、その後に図を生成する演算子、続いてテキスト用の演算子を出力することができ、その結果コンテンツストリームでは *コンテンツ順* 順序は次のとおりです： 1. table 2. 図 3. テキスト もちろん、そのページが表示されるときにはすべてが正しい位置に配置されます。完全に視覚のある読者にとっては、それらの項目がページのコンテンツストリーム内にどの順序で保存されているかは関心事ではありません。すべてが正しい場所にある完成した描画済みページを見ているからです。 しかし、支援ソフトウェアがコンテンツストリーム内の項目の順序（コンテンツ順）に頼らざるを得ないとしたら、コンテンツ順が自然な読み上げ順と異なる場合に問題が生じます。たとえば、読み上げツールは内容を誤った順序で読み上げてしまいます。幸い、支援ソフトウェアはタグ付きPDFの論理順（構造）を利用できます。これは、コンテンツが読み上げられるべき順序を反映するように整理されていなければなりません。文書の論理構造を表すデータが、表示されるページ上に出ている実際のコンテンツとは別に保存されるのは、これらの理由によるものであり、次を可能にするためです > 「…論理コンテンツ要素の順序付けと入れ子化を、文書のページ上にある図形オブジェクトの順序や位置から完全に独立させること。」（の856ページ [The PDF Reference、第6版、2006年11月](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf)) 実際には、読み上げ順を保つ論理順を保証することは見た目以上にずっと難しいので、関係する問題の一端を示す、単純ではあるものの作り話の例を使ってみましょう。 #### 読み上げ順の誤り：Microsoft Wordを使った例 文書の著者は、特定の視覚効果を得るために、選んだ作成ソフトの機能を使うことがあります。たとえば、表を使って特定のテキストレイアウトを作るなどです。以下のスクリーンショットは、前の例で使用したMicrosoft Word文書を示しています。そこには、横並びの番号付き段落を作るために使われた表が含まれています。しかし、このコンテンツにタグを付ける場合、どのように扱うべきでしょうか。表としてタグ付けするのか、番号付きリストとしてタグ付けするのか。これらのコンテンツ型はいずれも、正しく表現するために複雑なタグ付け構造を必要とします。次の画像では、番号付き段落がどの順序で読まれる想定かに注意してください。行ごとではなく、列ごとです。 ![Microsoft Wordで作成した表の画像](/files/128149ffe4fbb0b4a9fc344d9fbb07772a948f0e) Word に、この文書を Acrobat PDFMaker プラグインではなく内蔵のエクスポート機能を使って PDF として保存させる場合、タグ付き PDF を作成するよう指示できます: ![Microsoft Word のエクスポート処理のオプション ダイアログ ボックス](/files/03d323af938ee2e2d3542075b83d478a01eed6bb) では、Word はこのレイアウトをどのようにタグ付けするのでしょうか。次の非常に短い動画（14秒）では、Adobe Acrobat Pro DC を使って Microsoft Word が生成したタグ構造を確認します。 {% embed url="" %} この文書では、Word はタグ付き PDF 文書を作成しており、次のものを使用しています: `表` というタグで、2 つのサブタグを含んでいます: `THead` 表ヘッダーの行グループを表すものと、さらに `TBody` 表本体の行グループを表します。 `THead` や `TBody` どちらも `TR` というタグを含み、個々のコンテンツ行を表します。 `TR` 各タグには、各セルにある番号付きリスト項目を表すさらなるタグが含まれています。次のスクリーン画像は、入れ子が深いタグ構造と、それに対応して必要となる論理構造の複雑さを示しており、このきわめて基本的な文書でさえ表現するのに必要なものです! ![Microsoft Word で作成した単純な表の、深く入れ子になったタグ構造と論理構造を示す画像](/files/60f22d8f6f4c3f099891ea11f1fb6eeddb53bf9b) TeX や LaTeX で生成された PDF と比べると、この Word の例は非常に単純な文書ですが、それでも表現するには複雑な論理構造が必要です。複雑な数式や表を含む LaTeX 生成の PDF を表現するために必要なタグ付けの複雑さを想像してみてください! #### タグ付きではありますが、読み順が正しくありません Word は確かに [タグ付きPDF](https://assets.ctfassets.net/nrgyaltdicpt/3vcgZmG5mkCPYUPTjV30CF/4c34ae919212fa19e979e4cf852e66c1/ReadAloud.pdf) これでも、完全にアクセシブルな PDF を作成しようとするあらゆるアプリケーションが直面する根本的な課題の 1 つ、つまり内容の意図された読み順を正しく表現することを示しています。タグ付き PDF の作成時に、Word の内部処理は対応するコンテンツストリームを、列単位ではなく行単位で表を出力するように決定しました。PDF を見る視覚のある読者にとっては、こうした低レベルの詳細は問題になりません。表は正しく表示されるからです。しかし、視覚障害のある人にとっては、Word の論理文書構造は望ましい読み順（列単位）が保持されていないため、誤った結果になります。つまり、内容が間違った順序で読み上げられるのです。 次の音声録音は、Adobe Reader DC の「Read Out Loud」機能を使って作成されました。明らかなように、テキストは列単位ではなく行単位で、誤った順序で読み上げられています: ![Microsoft Word で作成した表](/files/3b06bbd0e20a7b1705fbb8f43136be2eebf80417) 上で述べたように、この例はやや作為的ですが、アクセシビリティ問題を引き起こすソフトウェア機能の組み合わせを適用することがいかに簡単かを示しています。しかし、文書作成者はそれを事前にどうやって知ればよいのでしょうか。おそらく、この問題は、結果としてできた PDF に対して実際のアクセシビリティ利用テスト、たとえば支援ソフトウェアを用いたテストを行って初めて検出されるでしょう。場合によっては、そのような文書は PDF/A 適合/検証テストには合格しても、「現実世界」での使用では失敗する可能性があります。このような PDF ファイルの正しい読み順を確保するには、Adobe Acrobat Pro DC のような高度な PDF 編集ツールを用いた熟練の手作業による介入が必要であり、時間もコストもかかります。別の方法として、文書作成者はこの特定の表現形式やレイアウトの使用を控えることもできますが、それが問題だと知っている場合に限られます! ### 空白文字を使って単語を区切る ワープロやテキストエディタに文字を入力するとき、空白文字を使って 1 つの単語の終わりと次の単語の始まりを示します。後でその文書から PDF を作成すれば、入力した空白文字はもちろん出力され、PDF に保存されるテキストの一部になります。しかし、TeX エンジンは組版テキストの単語区切りに空白文字を使いません。代わりに、空白文字を glue と呼ばれる柔軟な空き量の形式に変換します（詳細はこの [Overleaf の記事](/latex/ja/xiang-xi-ji-shi/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md) を参照してください。TeX のボックスと glue について詳しく説明しています）。 TeX エンジンで作成された PDF ページのコンテンツストリームでは、個々の単語の区切りは、空白文字を出力するのではなく、ページ上の別の位置に移動して次の単語のテキストを開始することで実現されます。さらに、TeX エンジンで組版されたテキスト段落における単語間の空白量は、TeX の行分割アルゴリズムによって行ごとに異なります。その変化は、PDF ページのコンテンツストリームに書き出される位置データに反映されます。 TeX の組版におけるこの側面は、その PDF からテキストをコピー/貼り付けする場合や、TeX エンジンで生成された PDF 内の組版テキストを読み上げようとする支援ソフトウェアに影響します。支援ソフトウェアは、処理に必要なテキストを抽出するために PDF ページのコンテンツストリームを解析しなければなりません。当然、そのようなソフトウェアには単語の開始と終了を検出する仕組みが必要で、最も明白な解決策は空白文字を使うことです。この点を踏まえると、アクセシビリティ標準では個々の単語が明確に区切られていること（たとえば空白文字によって）が求められますが、TeX エンジンは単語間 glue を使うため、これは問題になります。 #### しかし、まだ希望はあります! 2014 年、pdfTeX は出力する PDF において単語間に空白文字を使えるようにし、アクセシビリティ支援を改善するための 2 つの新しいプリミティブを導入しました: * `\pdfinterwordspaceon` * `\pdfinterwordspaceoff` これらのコマンドは、空白グリフだけを含む「ダミーフォント」を使用します。詳細と例は、次の文書の 29 ページにあります: [pdfTeX User Manual](http://texdoc.net/texmf-dist/doc/pdftex/manual/pdftex-a.pdf). #### LuaTeX の使用: Overleaf Gallery の例 LuaTeX はそれらの pdfTeX プリミティブをサポートしていませんが、LuaTeX のいわゆるコールバック機構を使って、pdfTeX と非常によく似た結果を得るようプログラムできます。glue を空白文字に変換するための Overleaf プロジェクトは、Overleaf Gallery で次のタイトルのもと公開されています: [LuaTeX を使って単語間 glue を空白とカーニングに変換する](https://www.overleaf.com/latex/examples/using-luatex-to-convert-interword-glue-to-spaces-and-kerns/sfdkdkybrvkv). LuaTeX（つまり Overleaf の LuaLaTeX コンパイラオプション）を使って LaTeX コードを組版すると、Lua コードを用いて、組版済みの段落を後処理し、単語間 glue を見つけて、それを空白文字と適切なカーニングに置き換えることができます。空白文字の幅によって提供される間隔は、単語間 glue が提供していた空白量を保つために、適切な kern 値を計算して加算（または減算）できるため、組版結果の見た目は変わりません。 アクセシビリティソフトウェアの利用者にとってこれがどれほど違うかを理解するには、Adobe Reader DC の *Read Out Loud* 機能で取得したこの音声録音をお聞きください。このプロジェクト内の 2 行のテキストが、glue を空白に変換する前と後で読み上げられています。空白を使った 2 回目の読み上げが、単語間 glue を使った行に比べて、どれほど速く滑らかに読み上げられるかに注目してください。 Overleaf のプロジェクトは LuaTeX でコンパイルされる plain TeX ファイルで、実験用にのみ提供されています。完全な本番品質の解決策として意図されたものではありません。主として、アクセシブルな PDF に関する技術的問題の理解を助けるために設計されています。そのプロジェクトで使われている Lua コードは、かなり以前の Overleaf の記事に含まれていた作業を基にしています [ボックスとグルー：LuaTeXを使った、簡潔だが視覚的な入門](/latex/ja/xiang-xi-ji-shi/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md). 注: 簡略化のため、このプロジェクトでは次のコードから派生した、非常に最小限の独自 OpenType フォントローダーを使用しています: . ### その他のアクセシビリティ上の問題とタグ付き PDF タグ付けによって PDF 内に存在するコンテンツ項目を識別できますが、グラフィックや複雑な数式のような種類のコンテンツは、視覚障害者を支援するためのソフトウェアで利用可能にするには、追加のデータや情報が必要です。幅広い種類のコンテンツに対してアクセシビリティを提供し支援するため、PDF 仕様ではコンテンツ項目に「代替説明」または「ActualText」を付加できるようになっており、適切なテキスト説明や他の機械可読な表現を提供します。たとえば、PDF 2.0 仕様では、この目的のために MathML が指定されています。 #### それは「本当のコンテンツ」なのか、それとも単なるアーティファクトなのか？ 視覚障害のある人にとって、コンテンツを長方形のページサイズの区画に分割して表示する過程には、単語のハイフネーションのような望ましくない副作用があります。さらに、視覚的な表現を強化するために使われるページデザインやレイアウトの要素は、それを見ることができない人にとってはほとんど意味がありません。そのため、PDF コンテンツのタグ付けでは、PDF 内の一部のコンテンツは *アーティファクト* として扱われるべきだと認識しなければなりません。たとえば、ページ番号、ページヘッダーとフッター、網掛け背景、その他のデザイン上の目印は、コンテンツを処理するアクセシビリティソフトウェアが無視するように識別しておく必要があります。 ## PDF/A 標準の概要 アクセシブルな PDF の作成を求める場合、通常は次の ISO 規格が参照されます: [ISO 19005](https://www.iso.org/standard/38920.html)。これは一般に PDF/A と呼ばれます。ただし PDF/A は *ファミリー* の規格群であるため、「PDF/A 適合」を求めるだけでは実際の要件を完全には特定できない場合があります。その理由を見るために、まず PDF Association の次の簡単な概要から始めましょう: [PDF Association のウェブサイト](https://www.pdfa.org/resource/iso-19005-pdfa/) （2020 年 5 月 21 日アクセス）にある、ISO 19005（PDF/A）を次のように説明したものです: > 「ISO 19005 の主目的は、PDF を基盤とし PDF/A として知られるファイル形式を定義することであり、ファイルの作成・保存・レンダリングに使用されるツールやシステムに依存せず、時間の経過に伴って静的な外観を維持する方法で電子文書を表現するための仕組みを提供することです。 > > ISO 19005 の副次的な目的は、適合するファイル内で電子文書の論理構造およびその他の意味情報を表現するための枠組みを定義することです。 > > ISO 19005 のもう 1 つの目的は、適合するファイル内のメタデータに、電子文書の文脈と履歴を記録するための枠組みを提供することです。」 明らかに、PDF/A にはいくつかの主要な目的があります。 ### PDF の進化と拡大 この [PDF 1.0 仕様](https://web.archive.org/web/20150617123515/http://acroeng.adobe.com/PDFReference/PDF%20Reference%201.0.pdf) は 1993 年に公開され、わずか 230 ページでした。しかし 13 年後には、 [Adobe の PDF バージョン 1.7](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf) は 1000 ページをはるかに超えています! 時間の経過とともに、PDF 仕様の規模と複雑さは、サポートされる機能セットの拡張によって増大してきました。新しい技術や、さまざまな市場やコミュニティにおける、ますます洗練された PDF ベースのワークフローやユースケースの要件を包含してきたのです。しかし、どのユーザー、あるいはどのユーザー集団も、そのすべての可能性を使い尽くすことはないでしょう。PDF は、できるだけ幅広い市場のニーズに応えられるよう、「万全を期す」必要があります。たとえば、高度な商業印刷を支援するために設計された多くの PDF 機能は、文書を保存したり共有したりする形式としての日常的なオフィス利用では必要ありません。 ### PDF/A: PDF の「基本への回帰」 PDF/A の中核目的は、適合 PDF が長期アーカイブに適していること、またはそれらの PDF を「利用」するさまざまな支援技術を使う人にとってアクセス可能なコンテンツを含むことを保証することです。これらの目的を達成するため、PDF/A は適合 PDF ファイルで許可される PDF 機能の集合を制限し、アーカイブ性やアクセシビリティを損なう可能性のある機能の使用を禁止します。PDF/A は、適合 PDF ファイルが完全な PDF 仕様の一部をどのように使うべきかを規定する規格群だと考えることができます。長期アーカイブに適したファイルを生成し、またその内容のアクセシビリティを確保するためです。PDF/A の制約により、PDF は PDF 読み取り技術や、その内容にアクセスするために使うコンピューティング環境から独立した「アーカイブ用デジタル紙」として利用できます。適合 PDF には、その振る舞いが「実装依存」、つまり閲覧や処理に使う特定のソフトウェアやオペレーティングシステムに依存するものを含めるべきではありません。PDF はまた *サブセット* 完全である必要もあります *完全である*：フォントやカラープロファイルなどの重要な文書リソースはファイルに埋め込まれていなければなりません。 ### PDF/A のバージョンと適合レベル PDF/A 標準にはさまざまな *バージョン* があり、それぞれ正式な PDF 仕様（PDF 1.4、1.7、2.0）の特定のバージョンを反映しています。さらに、さまざまな *適合レベル* があり、PDF ファイルが PDF/A 標準のどの側面に適合するかを指定します。したがって、「PDF/A 適合」を主張または要求する場合は、次に適合する PDF ファイルを想定すべきです: **PDF/A-** 例えば * PDF/A-1a: PDF/A バージョン 1、適合レベル a を意味します * PDF/A-2b: PDF/A バージョン 2、適合レベル b を意味します これらについて少し詳しく見ていきます。 #### PDF/A のバージョン PDF/A 標準は ISO の管理下にあり、ISO 19005 という規格として公開されています。前述のとおり、PDF 仕様は時間とともに進化し、その結果、ISO 19005 も更新する必要が生じ、下表のようになりました: | | | | | --------------- | ---------------- | -------------------- | | **PDF/A バージョン** | **ISO 規格** | **基準となる PDF バージョン** | | PDF/A-1 | ISO 19005-1:2005 | PDF 1.4 | | PDF/A-2 | ISO 19005-2:2011 | PDF 1.7 | | PDF/A-3 | ISO 19005-3:2012 | ISO 32000-1（PDF 1.7） | 本稿執筆時点（2020 年 4～5 月）では、更新版の PDF/A-4（ISO 19005-4）が [準備中です](https://www.iso.org/standard/71832.html). #### PDF/A の適合レベル 3 つの PDF/A バージョン（PDF/A-1、PDF/A-2、PDF/A-3）に加えて、3 つの *適合レベル*: * レベル A（アクセシブル）: アクセシビリティ向け（レベル B のアーカイブ要件を含む） * レベル B（基本）: アーカイブ向け * レベル U（Unicode）:（アーカイブに加え、テキストに Unicode を使用） これらの適合レベルの簡単な説明です: * **レベル B（基本）** は PDF/A における適合の最低要件です。適合 PDF 文書が長期アーカイブに適していること、つまり特定のソフトウェア、ツール、オペレーティングシステムに依存せず、常に確実に閲覧または印刷できることを保証する要件を定義しています。 * **レベル A（アクセシビリティ）** はレベル B 適合の要件を含みますが、それに加えて、文書のテキストにアクセスできるように Unicode を使用するとともに、論理構造と読み順情報を提供するためのタグ付き PDF の使用を要求します。 * **レベル U（Unicode）** は PDF/A-2 に追加された適合レベルで、レベル B を基礎としつつ、文書テキストに Unicode の使用を追加で要求しますが、構造情報を必須とするレベル A ほどではありません。 PDF/A のバージョンと適合レベルは、次の表にまとめられます: | | | | | | -------------- | --------------------- | -------- | -------- | | **適合レベル** | **PDF/A-** | | | | レベル A（アクセシブル） | PDF/A-1a | PDF/A-2a | PDF/A-3a | | レベル B（基本） | PDF/A-1b | PDF/A-2b | PDF/A-3b | | レベル U（Unicode） | 該当なし（PDF/A-1 には存在しない） | PDF/A-2u | PDF/A-3u | ### PDF/UA（「Universal Accessibility」） PDF/A 標準のレベル A 適合は、アクセシブルな PDF の要件をある程度定義するものですが、次の別の ISO 規格は [ISO 14289](https://www.iso.org/standard/64599.html)、PDF/UA と呼ばれるこの規格はさらに踏み込みます。PDF/UA はアクセシビリティ要件を強化し、PDF/A 標準に含まれるガイダンスを明確化しており、アクセシブルな PDF の推奨標準となっています。 #### Matterhorn プロトコル PDF/UA 適合についてさらに深く知りたい読者は、次に関心を持つかもしれません: [Matterhorn Protocol](https://www.pdfa.org/resource/the-matterhorn-protocol-1-02/) これは「PDF/UA 適合に失敗する可能性のあるあらゆる方法の一覧」です。 ### 検証ソフトウェア PDF ファイルが特定の標準に適合しているかどうかを確認するには、それを *検証* PDF をスキャンして、その内容と構造がその標準の要件に適合しているかを確認する適合性ソフトウェアを使って検査する必要があります。たとえば PDF/UA や PDF/A-*x*a（ここで *x* = 1、2、3）。PDF の検証、つまり好みの検証ツールで処理することは、診断メッセージや警告を生成する場合がありますが、それらは専門家でないユーザーにはかなり不可解に見えることがあります。おそらく、何らかの低レベルの PDF データ（または構造）が関連標準を満たしていないためでしょう。多くの著者にとって、そのような警告を解釈し、文書に対する実行可能な修正へと変換するのは、かなりの難題です。 #### 無料の検証ソフトウェア * [veraPDF](https://verapdf.org/) は、そのウェブサイト（2020 年 5 月 28 日アクセス）によると、「PDF/A のすべての部分と適合レベルを対象とする、目的特化型のオープンソースのファイル形式検証ツール」です。 * （Windows のみ） [PDF Accessibility Checker（PAC 2024）](https://pac.pdf-accessibility.org/en/download) は「…2010 年以来、試用と検証を重ねてきた無料の PDF アクセシビリティチェックツール」です。 #### 商用の検証ソフトウェア * [Adobe Acrobat](https://acrobat.adobe.com/uk/en/acrobat/pricing.html) は、PDF の検証テスト一式に加え、非準拠の PDF ファイルにあるタグを編集・修正するためのツールを提供します。 ### PDF Association: 情報源として優れています この [PDF Association](https://www.pdfa.org/) は多くの *優れた* PDF/A、PDF/UA、その他多くの PDF 関連トピックに関する資料を提供しています。さらに、その [YouTube チャンネル](https://www.youtube.com/user/ThePDFAssociation/playlists) の動画に加え、ウェブサイトで利用できる記事や無料の技術出版物もあります。そのような出版物の 1 つが [PDF/UA in a Nutshell](https://www.pdfa.org/resource/pdfua-in-a-nutshell/) で、PDF/UA 標準とその要件について非常に有用な入門となっています。 ## TeX エンジンと LaTeX によるアクセシブルな PDF おそらく、これまでの議論から、完全にアクセシブルで正しくタグ付けされた PDF ファイルの作成が、要求の高い技術的課題であることが見えてきたはずです。さらに、先ほどの単純な Microsoft Word の例でさえ、著者が非常に簡単に、アクセシビリティ基準を満たさないタグ付き PDF 文書を生み出してしまうソフトウェア機能の組み合わせを使えてしまうことを示しました。 著述ツールとしての LaTeX は、作成できる文書の種類や複雑さにおいて、ほぼ無限の柔軟性を著者に提供します。これがそもそも LaTeX を選ぶ理由かもしれません。LaTeX は、著者が文書の一部として利用できる何千もの追加パッケージによる拡張性も備えています。それだけではなく、著者は新しい TeX または LaTeX マクロを作成したり、既存のものを再定義したりして、特定の効果を実現する自由もあります。しかし、この自由と柔軟性には代償があるのかもしれません。というのも、LaTeX が正しくタグ付けされたアクセシブルな PDF 出力を自動生成するには、これら膨大な LaTeX パッケージやマクロの相互作用によって生まれるコンテンツを「何らかの形で」調整する必要があるからです。 実際には、LaTeX が与える拡張性、機能の強さ、多用途性、そして著述の「自由」は、PDF/UA または PDF/A-{1|2|3}a 標準に適合する、完全にアクセシブルでタグ付きの PDF 文書を、シームレスかつ透過的に（「自動的に」）生成することに対して技術的な課題をもたらします。より広い TeX および LaTeX コミュニティはこれらの課題に懸命に取り組んでおり、TeX User Group（TUG）は PDF アクセシビリティおよび PDF 標準の [作業部会](https://www.tug.org/twg/accessibility/)。そこには [議論用メーリングリスト](https://tug.org/mailman/listinfo/accessibility) があり、関心のある人々が TeX と LaTeX を使ったタグ付き PDF ファイルの作成について議論する手段を提供しています。 こうした議論では、LaTeX は実際には実行可能な組版プログラムではなく、TeX と呼ばれるより低レベルの言語で書かれた高度なマクロ（コマンド）の大規模な集まりであることを忘れないことが重要です。丹念に作り上げた LaTeX 文書と最終的に組版された PDF の間にあるのは、TeX エンジンと呼ばれるソフトウェアで、その役目は文書の記述と構成に使われた LaTeX コマンド（つまりマクロ）の集まりを「実行」し、それらを PDF ファイルとして保存される文書の組版表現に変換することです。TeX/LaTeX エコシステムに初めて触れる人は、出会うツールに使われる謎めいた名前の多さに、しばしば、そして当然ながら困惑します。TeX、LaTeX、pdfTeX、pdfLaTeX、XeTeX、XeLaTeX、LuaTeX、LuaLaTeX です。もし同じように感じるなら、Overleaf の記事 [名前に何があるのか：TeXの多様なバリエーションへのガイド](/latex/ja/xiang-xi-ji-shi/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md) で、それらすべての用語の由来と意味を説明しています。 pdfTeX、XeTeX、LuaTeX のような TeX エンジンは、次のように呼ばれるソフトウェアの一種です: *文書コンパイラ*：LaTeX コードを受け取り、LaTeX マクロ（コマンド）をより低レベルの TeX 言語の命令に「変換」し、それらを「実行」して組版結果を生成することで、組版形式にコンパイルします。TeX ベースの組版システムは、高度な数式、楽譜、化学構造式、図版、洗練された多言語の組版テキストを含む、極めて複雑なコンテンツを生成できます。そうした複雑な文書をアクセシビリティ標準や規制に適合させるためには、TeX エンジンは LaTeX マクロ群や LaTeX パッケージとともに、生成する PDF ファイルに大量の追加データを埋め込むことで、適切にタグ付けされた PDF ファイルを生成する必要があります。 TeX エンジンは非常に複雑な PDF ファイルを生成できますが、その内部処理、アルゴリズム、機能には *組み込みの* 機能 *特に* タグ付きでアクセシブルな PDF の生成を支援するよう `StructTreeRoot`設計されたものはありません。代わりに、タグ付けとアクセシビリティの支援は、TeX エンジンが生成する PDF に追加データを「注入」する複雑なマクロプログラミングによって実現しなければなりません。その結果として、マークされたコンテンツのシーケンス、構造要素、そして ### 著者のニーズ 多くの人にとって、LaTeX は、目的を達成するためのパッケージを自由に選べる、美しく組版された文書を作成できる単なるツールにすぎません。LaTeX の著者の大多数は、単に文書が「動く」こと、つまりエラーなく組版され、学位論文や論文、レポートを提出したり、長年待ち望んだ本を完成させたりできることを望んでいます。もっともなことですが、LaTeX ユーザーは、選んだ LaTeX パッケージ群が平和に共存し、シームレスかつ透過的に連携して、文書作成に必要なコマンドや機能を提供してくれることを期待しています。LaTeX からタグ付き PDF を生成するという要件に直面した場合にも、同じような期待があるでしょう。つまり、それは「ただ動く」べきであり、透過的で、著者の介入は最小限であるべきです。残念ながら、私たちは「ほら見ろ、どんな奇妙なことをしてもタグ付けは勝手に起きる」という体験からはまだかなり離れています。アクセシビリティとタグ付き PDF の技術要件を LaTeX と著述の自由に結びつけることは本質的に複雑であり、技術的課題を実用的な実装と解決に適したものにするためには、何らかの「著者の規律」が必要になることも避けられないのかもしれません。 別の、しかし関連する問題として、不正確なタグ付けは最終的な PDF に視覚的な影響を与えない可能性があります。見た目は完全に問題なさそうで、印刷してもおそらく問題はありませんが、著者が知らないうちにタグ付けが「壊れて」いるかもしれず、それは後になって PDF/A 適合/検証チェックの失敗や、スクリーンリーダーのようなアクセシビリティソフトウェアによるさらなる実地テストで初めて発見されることになります。 ### Overleaf で生成された PDF ファイル Overleaf は、標準的な TeX Live インストールの上に構築された、ブラウザベースの LaTeX エディタと、共同著述を容易にするプロジェクト管理・文書管理ツールをユーザーコミュニティに提供しています。実質的には、Overleaf によってユーザーは Web ブラウザ経由で「離れた場所から LaTeX を実行」でき、完全な TeX Live システムの管理・維持の複雑さからある程度切り離されます。 Overleaf が標準的な TeX/LaTeX インストールを使っている結果として、Overleaf のエディタで書かれた LaTeX コードから生成される PDF は、ユーザーがローカルデバイスにインストールした環境を含め、同じバージョンの他の TeX Live インストールに存在するのとまったく同じ技術を使って作成されます。違いは、Overleaf の LaTeX コードをコンパイルして処理する TeX エンジンがローカルマシンではなくリモートサーバーで動作することだけです。Overleaf は TeX で生成された PDF を、ブラウザでの効率的なダウンロード/表示のために線形化しますが、その処理は PDF コンテンツ自体のアクセシビリティとは無関係です。 Overleaf を通じたアクセシブルな PDF の生成は、標準的な TeX エンジンに組み込まれた機能と、ユーザーが文書の一部として展開できる適切な LaTeX マクロパッケージの利用可能性に依存しています。Overleaf で作成された LaTeX 文書は、他の TeX および LaTeX インストールとの互換性を保つ必要があります。というのも、ユーザーは Overleaf から LaTeX プロジェクトをエクスポートして、さまざまな出版社やジャーナルシステムに提出する必要が頻繁にあるからです。Overleaf 固有の機能をその LaTeX 文書や下層の TeX エンジンに導入すると、ユーザーがその作業を別の場所で使う自由が大きく損なわれます。 Overleaf は、TeX/LaTeX 著述システムで生成される完全にアクセシブルな PDF の必要性を認識し、これを支援しています。私たちは、アクセシビリティの問題を調査し、タグ付き PDF をサポートする TeX エンジンや実験的な LaTeX パッケージの最新動向を探ることに時間を投資しています。最終的に、本稿執筆時点では、LaTeX 作者が（ `\usepackage`）を使って、一般的な LaTeX 文書から完全にアクセシブルで PDF/UA 準拠の PDF をシームレスかつ透過的に生成できる「箱から出してすぐ使える」解決策は存在しません。これらの解決策が TeX Live の更新を通じて利用可能になれば、もちろん Overleaf のユーザーコミュニティでも利用できるようになります。 ### タグ付けとアクセシビリティを探るためのいくつかの LaTeX パッケージ 多くの人にとって、 [tex.stackexchange](https://tex.stackexchange.com/) は、TeX、LaTeX、ConTeXt について助けを得るための最初の相談先です。これは驚くべきリソースであり、 [アクセシビリティ](https://tex.stackexchange.com/questions/tagged/accessibility?tab=Newest) や、LaTeX を通じたアクセシブルな PDF の生成に関する多くの質問があります。これらの質問や、その後に続く回答とコメントを読んだり眺めたりすれば、結論は 1 つしかありません。現時点では、あらゆる種類の LaTeX 文書から完全にアクセシブルで標準準拠のタグ付き PDF を自動的に作成する完全な本番レベルの解決策は存在しません。ただし、タグ付けを支援するいくつかのパッケージはあります。とはいえ、その適用範囲は限定されたユースケースや文書タイプにとどまるかもしれません。以下の一覧は、LaTeX ベースの PDF タグ付けを探求したい読者のために示しています: * [`tagpdf` パッケージ](https://ctan.org/pkg/tagpdf) （Ulrike Fischer）：PDF タグ付けの実験のために設計された、非常に高機能なパッケージです。pdfTeX と LuaTeX をサポートし、TeX エンジンを通じてタグ付き PDF を作成する際の技術的課題についての優れた注記を含む、非常に有用で興味深い文書を提供しています。関係する問題をよりよく理解したい人には、ぜひ読むことを強く勧めます。今後の方向性の焦点は LuaTeX になる可能性が高いです。 * [`axessibility` パッケージ](https://ctan.org/pkg/axessibility?lang=en) （Boris Doubrov とトリノ大学）：支援技術によって PDF ファイル内の数式にアクセスできるようにします。 * [`アクセシビリティ` パッケージ](https://ctan.org/pkg/accessibility) （Andy Clifton）：タグ付きで構造化された PDF ファイルを作成します。CTAN の注記によると、このパッケージは「KOMA-Script 文書クラスのユーザー向け」を意図しています。 * [`accsupp` パッケージ](https://ctan.org/pkg/accsupp) （Heiko Oberdiek）：PDF ファイルによりよいアクセシビリティ支援を提供するための実験的パッケージです。 さらに注目すべき参考文献として、2018 年の論文があります [数学出版のための PDF 規格の実装](http://web.science.mq.edu.au/~ross/TaggedPDF/PDF-standards-v2.pdf) マッコーリー大学数学科の Ross Moore 博士によるものです。その論文で Moore 博士は、LaTeX における PDF タグ付けの課題について簡単な概説を示しています: > 「難しさの主な原因は、さまざまな環境が互いにどう相互作用するかにあります。LaTeX には、ある環境や構造が、次のものが始まるまで完全には完了しない多くの状況があります。したがって、提供された各コンテンツの周りに開始タグと終了タグを単純に巻き付ければよい、という話ではありません。代わりに、周囲の सामग्रीによって確立された文脈の中で、さまざまな環境や他の構造が実際にどのように始まり、どのように終わるのか、その微妙さを理解する必要があります。」 ムーア博士はまた、現在次のパッケージの保守担当者でもあります: [`pdfx`](https://ctan.org/pkg/pdfx) パッケージであり、TeX/LaTeX を使ったタグ付き PDF の専門家であり先駆者でもあります。彼の仕事はぜひ検索する価値があります。YouTube のこの動画も含め、興味深い洞察を与えてくれます: {% embed url="" %} #### pdfx パッケージに関する注記 この [`pdfx`](https://ctan.org/pkg/pdfx) パッケージ（Ross Moore ほか）は PDF/A-1|2|3b（アーカイブ）やその他のオプションを非常によくサポートしますが、まだタグ付き PDF は生成しません。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://overleaf-pro.ayaka.space/latex/ja/sononotopikku/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.