PDFs are the “document of record” globally, offering high-value, long-context data with higher information density than typical HTML. But for AI and ML engineers, the format remains a notorious challenge, often dismissed as “black magic” due to its binary nature, compression, and encryption.

Join the PDF Association for an essential technical webinar using our new FAQ: Artificial Intelligence and PDF as a jumping-off point.

This discussion is intended for AI & ML engineers, AI research scientists, and data scientists to move beyond basic text extraction and master PDF ingestion for maximum model performance.

What you will learn:

• The Semantic Imperative: Tagged PDF: The alternative to error-prone and computationally expensive Document Layout Analysis (DLA) is to leverage Tagged PDF’s unpaginated logical structure as the most efficient and reliable path to understanding document context, tables, and reading order, thereby avoiding “pagination artifacts”.
• Learn why down-converting PDFs to formats like plain text or Markdown is “inevitably lossy” and an unnecessary “dumbing down” process that actively increases the risk of hallucinations.
• Explore why OCR is unnecessary for most “born digital” PDFs, and why it only recovers text content while missing critical semantics.
• Understand the necessity of ingesting *all* PDF components, including annotations (like digital signatures and text markup) and XMP metadata, which are essential for context and trustworthiness.
• Identify mechanisms that allow your systems to honor publisher rights and TDM preferences for AI mining.

Mastering PDF ingestion is the key to training more accurate and grounded models. Equip your engineering teams with the technical knowledge to unlock the vast, high-quality data trapped within the world’s most pervasive document format.

We look forward to a deep, technical discussion.

The panelists will take live questions. The recording will be made available to those who registered.

Panelists

• Boris Doubrov, Dual Lab
• Matthew Hardy, Adobe
• Jamie Lemon, Artifex

Moderator: Peter Wyatt, PDF Association

Register now!

The webinar will be held on September 9 at 0800 PT / 1100 ET / 1700 CET / 0000 KST.

The registration form includes a way to provide the panel with your question ahead of the webinar.

A PDF is not a plain text document. It is a complex format that contains layout information, text objects, images, tables, fonts, annotations, metadata, and sometimes a logical structure tree. The visual appearance of a PDF page does not always represent the correct reading order or semantic relationships between elements.

If PDF content is extracted incorrectly before reaching the LLM, the model receives incomplete or disorganized information. Problems such as broken reading order, corrupted tables, missing hierarchy, and lost relationships between elements directly affect the quality of AI-generated answers.

Even the best prompt cannot fix incorrect document parsing.

The solution is simple:

Parse the PDF first, then send structured content to the LLM.

Parse first, prompt second

A common mistake in AI workflows is sending a raw PDF directly into an LLM or RAG pipeline.

A better approach is:

PDF ⇒ OpenDataLoader ⇒ Structured Data ⇒ LLM

OpenDataLoader PDF converts PDF documents into AI-ready formats while preserving the original semantics of the document.

Supported output formats include:

Markdown, JSON, HTML, plain text.

Instead of forcing an LLM to interpret a complex PDF file, developers may provide clean, structured information optimized for AI processing. 

Example: Convert a PDF for LLM processing

We provide a Python Installation guide 

Requires: Java 11+ and Python 3.10+

Before you start: run java -version. If not found, install JDK 11+ from Adoptium.

Installing OpenDataLoader:

pip install -U opendataloader-pdf

Python script to convert multiple  PDFs into AI-friendly formats:

Code from OpenDataLoader.com https://github.com/opendataloader-project/opendataloader-pdf

The user can run it from a Python shell or can create a Python script file first and then run it from the shell.

Instructions for  Node.js | Java is also available on OpenDataloader official website.

The generated Markdown can be used directly for LLM conversations and summarization, while the JSON output is suitable for RAG pipelines, vector databases, and AI agents that require structured document information.

Figure 1.  Results with PDF

Figure 2.  Results with Markdown

In the first Figure, the LLM had to interpret the 1.4 MB, 16-page PDF file  directly, relying on its vision capabilities. In the second example, the same file was provided as structured Markdown, allowing the model to immediately understand the document hierarchy and data relationships. By separating document parsing from LLM reasoning, OpenDataLoader produces more reliable, consistent, and efficient AI workflows. 

Conclusion

Using OpenDataLoader to convert the 1.4 MB, 16-page PDF file into Markdown before sending it to an LLM significantly reduces both processing time and cost.

Compared with processing the PDF directly:

• API processing was approximately 2.4× faster (38 s – 16 s).
• Inference cost was approximately 2.9× lower ($0.35 – $0.12), a 66% cost reduction.
• Input token usage decreased by approximately 64% (29.2k – 10.6k tokens).
• The LLM received structured Markdown instead of having to reconstruct the document layout itself, allowing it to focus on reasoning rather than PDF parsing.

While the exact savings depend on the document and the LLM, this example demonstrates that preprocessing PDFs with OpenDataLoader can substantially improve the efficiency of AI workflows while reducing both latency and inference costs. To perform this operation, users should have basic scripting skills.

Why Raw PDF Parsing Breaks AI Applications

PDF files are designed primarily for visual presentation, not direct machine understanding. A document can appear perfect to a human reader while still being difficult for an AI system to interpret correctly.

This is especially important for RAG systems, where incorrect extraction can lead to incomplete or misleading context. OpenDataLoader preserves document structure and converts PDFs into structured outputs optimized for AI workflows, including LLM applications, Retrieval-Augmented Generation (RAG), semantic search, knowledge bases, and document automation.

The key difference is that OpenDataLoader provides structured understanding of documents, not just extracted text.

Tell your LLM to use OpenDataLoader

For AI assistants, agents, and custom GPT workflows, OpenDataLoader can become the default PDF preprocessing step.

Instead of:

Analyze this PDF.

Use instructions such as:

Whenever a PDF is provided, first process it with OpenDataLoader. Use the generated Markdown or JSON output as the source for all analysis, retrieval, and reasoning. Do not rely on built-in PDF parsing unless OpenDataLoader output is unavailable.

This creates a consistent workflow where every PDF is processed before the LLM starts generating answers.

Clean Markdown for Chat, JSON for RAG

Different AI applications require different output formats.

Markdown

Markdown is ideal for: AI assistants; document summarization; question answering; conversational workflows. 

It keeps headings, paragraphs, and lists structured while remaining easy for LLMs to process.

JSON

JSON is recommended for: RAG pipelines; vector databases; AI agents; structured extraction; document search. 

OpenDataLoader JSON includes structured elements together with bounding box information. This allows applications to connect retrieved information back to its original location in the PDF, improving transparency and citation workflows. 

Local, Deterministic Processing for AI Pipelines

One of the important advantages of OpenDataLoader is that it can run locally.

This provides:

• deterministic results : the same PDF produces the same output; 
• improved privacy : documents do not need to be uploaded to external services; 
• predictable processing pipelines; 
• no dependency on external APIs for basic parsing. 

For organizations processing confidential documents such as contracts, financial reports, technical documentation, or research papers, local processing is often an important requirement. 

Conclusion

The quality of an LLM response depends heavily on the quality of the information provided to it. Feeding raw PDFs directly into an LLM often transfers the hardest part of the problem document understanding to the model.

A more reliable workflow is:

PDF → OpenDataLoader → Markdown / JSON → LLM

By using OpenDataLoader as the PDF parsing layer, developers can provide LLMs with structured, layout-aware, and machine-readable content. This improves retrieval accuracy, reduces parsing errors, and creates more reliable AI applications built on PDF documents. 

Analysis of 20.6 Million PDF Documents from the June 2026 Common Crawl Dataset

Executive Summary

PDF remains one of the most widely used formats for publishing digital information, yet accessibility continues to be a major challenge. To better understand the current state of PDF accessibility, Dual Lab analyzed the complete June 2026 Common Crawl dataset (CC-MAIN-2026-25), containing 20,578,394 PDF documents.

This report extends our previous study of approximately 15 million PDFs from CC-MAIN-2026-04 and presents new data on encryption, permission flags, document size, page counts, annotations, PDF versions, and document age.

The analysis provides a large-scale view of how PDF technology is used across the public web and establishes a foundation for future reports on PDF in general with focus on Tagged PDF, PDF/UA adoption, and accessibility trends.

Research Scope and Methodology

The study analyzed every PDF referenced in the June 2026 Common Crawl (CC-MAIN-2026-25) dataset.

Because Common Crawl stores only the first 5 MB of each PDF, documents exceeding this size were downloaded directly from their original URLs to enable complete analysis.

The final dataset contains:

• 20,578,394 PDF documents
• approximately 38 TB of source data

For each PDF we extracted:

• basic metadata:
  • page count
  • file size
  • creation and modification dates
  • PDF version (including Version entry in the document catalog)
  • producer and creator
• encryption information and permissions
• annotations
• presence of interactive forms
• presence of optional content layers
• presence of digital signatures
• image only (scanned) pages
• Tagged PDF information:
  • stats on the use of structure element types
  • logical structure tree validation against ISO 32005

The dataset contains:

• 1,905,490 PDFs (9.26%) with interactive forms
• 419,069 PDFs (2.04%) with digital signatures
• 888,237 PDFs (4.32%) with optional content (layers)

Distribution of PDF documents by date

To understand the distribution of documents by timeline we analyzed document dates using ModDate when available; otherwise, CreationDate was used.

Because PDF metadata is not always reliable, the analysis was limited to documents dated between 1990 and June 2026. Approximately 974,000 files (about 5%) were excluded because their dates were missing, had invalid syntax, or were outside this range.

Figure 1. Distribution of PDF modification date, 1990–2026

Most publicly available PDFs from June 2026 Common Crawl dataset were created or modified within the last several years.

Distribution of page counts in PDF Files

 Figure 2. Number of pages in PDFs

Most PDFs published on the web are relatively short.

Single-page documents represent the largest group (5.8 million files), followed by:

2–3 pages (4.9 million), 4–7 pages (3.4 million), 8–15 pages (2.7 million).

Document frequency decreases steadily as page count increases.

Methodological note. Around 8000 PDFs had malformed page trees resulting in missing page information. They were excluded from the page-count analysis.

Distribution of PDF Files by PDF Version

The reported PDF version was determined using both the document header and the optional /Version entry in the Catalog, as defined in PDF 2.0 ( ISO 32000-2).

Only valid PDF versions were included. During processing, 81 documents with invalid version numbers (for example, 1.8, 1.9, 2.3, 7.0, 112.0, and 990.0) were excluded.

PDF 1.7 remains the dominant version with more than 6 million documents, followed by: PDF 1.4, PDF 1.5, PDF 1.6. Together these four versions account for the majority of PDFs on today’s web.

  Figure 3. PDF files by by header+catalog version (1.0-2.0)

Total Number of Annotations by Type

Annotations are one of the most widely used interactive features of the PDF format. Across the 20.6 million PDF documents analyzed, we identified hundreds of millions of annotations of different types.

The three most common annotation types are:

• Link — 265.3 million
• Widget — 20.4 million
• Square — 6.4 million

Other frequently used annotation types include Popup, FreeText, Stamp, Ink, Highlight, Watermark, and Text.

 Figure 4. Top 20 Annotation types total count

Figure 4 presents the total number of annotations of each type across all analyzed PDF documents. The Figure is displayed on a logarithmic scale, allowing less frequent annotation types to remain visible and enabling meaningful comparison across the full distribution.

 Figure 5. Top 20 Annotation Types by Document Count

Figure 5 shows Top 20 Annotation Types by the number of documents in which they appear. The vertical axis is plotted on a logarithmic scale.

Besides the annotation types defined by the PDF specification (such as Link, Text, Highlight, or Stamp), the dataset contains dozens of proprietary subtypes created by specific PDF applications and workflows, such as BatesN, InstaSign, MultiSig, SILANIS_SIGNATURE, GoldGrid:AddSeal, TrapNet, and numerous specific annotations generated by products such as GdPicture, BJCA, FICL, and others.

 Figure 6. Full list of annotation types by document count

PDF Encryption and Permission Flags

 Figure 7. Percentage of Permission Flags

Only 513,342 documents (2.5%) were encrypted with an empty open password. The page-count analysis excludes malformed PDFs with missing page information and 80,062 password-protected PDFs with unknown passwords. For encrypted documents with empty open passwords we analyzed the permission flags stored in the PDF encryption dictionary.

The majority of encrypted PDFs permit normal document use.

• Printing — 91.8%
• High-resolution printing — 84.1%
• Accessibility text extraction — 83.9%

The high percentage of documents allowing accessibility extraction is encouraging because the PDF specification defines this permission independently of general content copying, allowing assistive technologies to access document text even when copying is prohibited.

However, approximately 16% of encrypted PDFs, or 0.4% of the total analyzed document count, disable accessibility extraction (this permission flag was deprecated in PDF 2.0), potentially creating unnecessary barriers for users of screen readers and other assistive technologies.

Overall, encrypted PDFs on the public web are primarily configured to prevent document modification rather than document access.

Implications of analysis

This first part of the June 2026 Common Crawl PDFs analysis reveals several long-term characteristics of PDF usage on the public web:

• Most PDFs remain relatively small, short documents.
• Encryption is uncommon and generally does not prevent document access.
• Accessibility text extraction is enabled in most encrypted documents, although a significant minority still disables it.
• PDF 1.7 continues to dominate document production.
• Proprietary extensions remain common, particularly in annotation workflows.
• Link annotations dominate all other annotation types combined.

Conclusion

This first part of the report provides an initial statistical overview of more than 20.5 million PDF documents collected from the June 2026 Common Crawl dataset.

The findings establish a baseline for understanding how PDFs are created, distributed, and protected on today’s web.

Stay tuned. In the next parts we analyse the evolution of a median size of PDF documents for the past 20 years, top producers of PDFs, and Tagged PDF trends.

What is a Structure Tree?

The Structure Tree represents the logical structure of a tagged PDF document. It consists of structure elements such as headings, paragraphs, lists, tables, and figures, organized in a hierarchical tree that is interpreted by assistive technologies. It also defines the reading order of the document content.

Accessibility validation is performed against these logical structure elements rather than the document’s visual appearance, making the Structure Tree an essential component of PDF accessibility analysis.

The Structure Tree defines how assistive technologies interpret and navigate a tagged PDF. In PDF4WCAG Accessibility Checker, users can inspect this hierarchy to verify that headings, paragraphs, lists, and other structure elements are organized correctly and follow a logical reading order.

Accessibility Checker and the Structure Tree

Accessibility checkers can detect an empty paragraph (<P>), but without a Structure Tree it is often impossible to determine which paragraph caused the error. Unlike many visual accessibility issues, an empty structure element usually has no visible representation on the page and therefore cannot be highlighted in the document view. As a result, users are often left searching through the document to locate the offending element.

PDF4WCAG Accessibility Checker 1.10 addresses this problem by introducing an interactive Structure Tree. When a validation error is selected, the corresponding structural element is highlighted in the Structure Tree panel, allowing users to quickly locate the issue within the document hierarchy. An empty paragraph is just one example; the same approach can be used to investigate other structural accessibility problems.

So, when an empty paragraph is detected, users can navigate directly to the corresponding <P> structure element in the tree. This makes it immediately clear where the error occurs and allows users to inspect the element’s parent and child nodes, understand its context within the document hierarchy, and resolve the issue more efficiently.

Structure Tree and Roadmap Navigation

PDF4WCAG Accessibility Checker 1.10 also enhances navigation through both the Structure Tree and the Roadmap.

The Structure Tree provides a hierarchical view of the document’s logical organization, while the Roadmap presents the logical reading sequence of the document. Together, these complementary views help users understand both the document hierarchy and its reading order, making it easier to investigate and remediate accessibility issues in complex PDF documents.

Conclusion

The Structure Tree is one of the most valuable tools for PDF accessibility remediation. While validation reports identify what is wrong, the Structure Tree shows where the problem exists within the document’s logical structure.

By combining synchronized navigation between the validation results, Structure Tree, Roadmap, and document view, PDF4WCAG Accessibility Checker 1.10 enables accessibility specialists to locate and understand structural issues such as empty paragraphs much more quickly than with traditional validation reports alone. For large and complex tagged PDFs, this significantly reduces remediation time and improves the efficiency and accuracy of accessibility corrections.

Why fonts matter for accessible PDFs

For textual content, PDF/UA and Well-Tagged PDF (WTPDF) require text to be represented in a way that supports reliable Unicode extraction and interpretation by assistive technologies.

Proper font implementation helps ensure:

• Reliable text extraction
• Searchable and selectable text
• Accurate Unicode mapping
• Reliable interpretation by assistive technologies

If font encoding or accurate Unicode character mapping is incorrect, text may appear correctly on screen while being interpreted incorrectly by assistive technologies or accessibility validation tools.

What the Fonts panel shows

The new Fonts panel in PDF4WCAG 1.10 provides detailed technical information about every font used in the document, including:

• Embedded fonts – displays information about fonts embedded in the document
• Font type and subset information – displays the font type and whether a font is embedded as a subset or in full
• Encoding information – provides information about font encoding to assist in diagnosing Unicode mapping issues

Users can immediately inspect all font resources from a single location. This makes troubleshooting much faster, especially in complex documents containing multiple embedded fonts.

How font information supports accessibility

Screen readers rely primarily on correctly encoded text, Unicode mappings, and the tagged PDF structure. Incorrect font encoding or missing ToUnicode mappings can prevent assistive technologies from interpreting text correctly, even when the document appears visually correct. This results in unreadable or skipped content for users with visual disabilities.

The new Fonts panel in PDF4WCAG Accessibility Checker 1.10 gives users direct access to essential font information that previously required specialized PDF inspection tools. By exposing embedded fonts, font types, subset status, and encoding information, it helps accessibility professionals diagnose problems more quickly and improve the technical quality of accessible PDF documents.

Combined with PDF4WCAG’s validation engine, powered by the veraPDF architecture, the Fonts panel makes version 1.10 a more comprehensive accessibility validation solution.

Together with the new Metadata and Annotations panels introduced in version 1.10 PDF4WCAG, the Fonts panel provides deeper insight into the technical structure of PDF documents and supports more efficient accessibility analysis.

Contact us:

email: info@pdf4wcag.com

website: https://pdf4wcag.com/

Boris Doubrov, CEO of Dual Lab, will participate in PDF Association technical webinar using  new FAQ: Artificial Intelligence and PDF as a jumping-off point.

The webinar will be held on September 9 at 0800 PT / 1100 ET / 1700 CET / 0000 KST.

PDFs are the “document of record” globally, offering high-value, long-context data with higher information density than typical HTML. But for AI and ML engineers, the format remains a notorious challenge, often dismissed as “black magic” due to its binary nature, compression, and encryption.

This discussion is intended for AI & ML engineers, AI research scientists, and data scientists to move beyond basic text extraction and master PDF ingestion for maximum model performance.

What you will learn:

• The Semantic Imperative: Tagged PDF: The alternative to error-prone and computationally expensive Document Layout Analysis (DLA) is to leverage Tagged PDF’s unpaginated logical structure as the most efficient and reliable path to understanding document context, tables, and reading order, thereby avoiding “pagination artifacts”.
• Learn why down-converting PDFs to formats like plain text or Markdown is “inevitably lossy” and an unnecessary “dumbing down” process that actively increases the risk of hallucinations.
• Explore why OCR is unnecessary for most “born digital” PDFs, and why it only recovers text content while missing critical semantics.
• Understand the necessity of ingesting *all* PDF components, including annotations (like digital signatures and text markup) and XMP metadata, which are essential for context and trustworthiness.
• Identify mechanisms that allow your systems to honor publisher rights and TDM preferences for AI mining.

Mastering PDF ingestion is the key to training more accurate and grounded models. Equip your engineering teams with the technical knowledge to unlock the vast, high-quality data trapped within the world’s most pervasive document format.

We look forward to a deep, technical discussion.

The panelists will take live questions. The recording will be made available to those who registered.

Panelists

• Boris Doubrov, Dual Lab
• Matthew Hardy, Adobe
• Jamie Lemon, Artifex

Moderator: Peter Wyatt, PDF Association

Register now!

The webinar will be held on September 9 at 0800 PT / 1100 ET / 1700 CET / 0000 KST.

The registration form includes a way to provide the panel with your question ahead of the webinar.

Register now! 

Annotations  panel

PDF4WCAG Accessibility Checker 1.10 introduces a dedicated Annotations panel that gives users deeper insight into interactive elements critical for accessibility compliance.

The panel inspects all types of PDF annotations relevant to usability evaluation, including:

The importance of  Annotation Inspection 

The Annotations panel provides visibility into the most common accessibility failures related to PDF annotations, including:

• • Untagged links: users can identify untagged links annotations, which lead to  accessibility issues: screen readers treat it as plain text or ignore it entirely.
  • Missing form labels: users can identify forms with missing labels.
  • Incorrect inclusion of annotations into the structure tree: users can identify annotations whose parent tags are missing or not in the correct position within the document structure.
  • Alt text: users can quickly see which annotations have missing or empty alt text.
  • Forbidden annotation types: users  can identify annotation types that are not allowed in the accessible PDF documents.

Annotation error

 Annotation error links

The new annotations panel helps users quickly identify these issues, supporting compliance with WCAG and PDF/UA requirements. 

Persistent Preferences

Configuration settings are now persisted between sessions, meaning any custom filtering or view states the user applies to his annotation checks will be remembered the next time the user opens the tool.

Contact us:

email: info@pdf4wcag.com

website: https://pdf4wcag.com/

TL;DR: This article explains the Privacy Policy of PDF4WCAG. How PDF4WCAG collects, uses, and protects information when a user performs the validation on the website or works with the Desktop version.

Organizations that process PDF documents often face strict requirements for data privacy, confidentiality, and regulatory compliance. To meet different operational needs, PDF4WCAG is available in both Web and Desktop versions giving users the opportunity to choose the deployment that best fits security and workflow requirements.

Privacy is a major concern

PDF accessibility validation involves sensitive content, including corporate reports, legal documents, financial statements, educational materials and government publications. Before selecting PDF accessibility checker, organizations should understand where their documents are processed and what information may be transmitted outside their environment.

PDF4WCAG Web version and privacy policy

The Web version of PDF4WCAG is designed for convenience and accessibility. Users can access the service through a web browser without installing any software. Users access Web versions instantly, regardless of their operating system, making onboarding fast and effortless. Automatic updates mean there is no need to manage versions or worry about outdated functionality.

Document processing in the Web version

Files are saved in the browser and then sent to the PDF4WCAG server, where they are deleted immediately after the end of the session. PDF4WCAG doesn’t send files anywhere else. PDF4WCAG uses files just for analysis in case of problems when a user requests.

Web version integrates with veraPDF validation engine. PDF4WCAG doesn’t store its own cookies in the browser. However, it does utilize Google Analytics and collects cookies required by the Google Agent itself. PDF4WCAG also stores basic application settings in the browser (language, selected profile, document zoom, and whether to open the right-hand panel by default).

Use cases of web version

• Individual accessibility specialists.
• Small and medium-sized organizations.
• Small PDF remediation projects.
• Remote teams requiring browser-based access

PDF4WCAG Desktop version and privacy policy

PDF4WCAG provides Desktop version for all major platforms, offering an identical user experience across operating systems (Windows, Linux, macOS). PDF4WCAG Desktop transfers the functionality of the web-based PDF4WCAG Accessibility Checker into a local environment keeping the same visual experience. It represents a desktop wrapper for the web application, enabling users to perform PDF accessibility validation directly on their computers without relying on an internet connection.

Document processing in Desktop version

Desktop version of PDF4WCAG operates offline. It does not send or collect any data to the Internet or outside. As Web version, the desktop version also integrates with veraPDF validation engine, providing the same error previews, compliance reports, and interactive issue visualization as the online tool.

This approach reduces exposure to third-party infrastructure and supports environments with strict confidentiality requirements.

Use cases of Desktop version

• Government agencies.
• Financial institutions.
• Healthcare organizations.
• Legal firms.
• Enterprises handling confidential or regulated information.

Comparing the two versions

Web Version

• Installation required: No
• Browser access: Yes
• Document storage location: PDF4WCAG server
• Local processing: No
• Sensitive docs: Depends on policies
• Files auto-delete after session: Yes

Desktop Version

• Installation required: Yes
• Browser access: No
• Document storage location: Local directory
• Local processing: Yes
• Sensitive docs: Highly suitable
• Files auto-delete after session: Yes

Conclusion

Both PDF4WCAG Web and Desktop editions deliver powerful PDF accessibility capabilities. The key difference lies in where document processing takes place. Organizations handling confidential, proprietary, or regulated information may prefer the Desktop version for its local-processing architecture, while users seeking flexibility and ease of deployment may find the Web version the more practical choice.

Understanding these privacy distinctions helps organizations select the deployment model that best aligns with their security, compliance, and operational requirements.

Contact us:

email: info@pdf4wcag.com

website: https://pdf4wcag.com/

The webinar covered:

• Why we’re doing this: poor user experience when reading math
• Why PDF 2.0 changes everything
• A (brief!) introduction to MathML
• Relevant standards and the PDF Association’s new guidance
• Implications for publishers and developers

The presentation recording by Boris Doubrov, CEO of Dual Lab, is now available, watch the recording on YouTube.

Download the slides (pdf) (p. 11-12)

PDF documents may include general information, such as the document’s title, author, and creation and modification dates. Such information about the document (as opposed to its content or structure) is called metadata and is intended to assist in cataloguing and searching for documents in external databases.

Metadata plays a tremendous role in modern PDF files, especially in accessibility, document management and AI-based document processing. In PDF files metadata is commonly stored using XMP (Extensible Metadata Platform) package, directly embedded into the document.

Document title and accessibility

Well-Tagged PDF (WTPDF) declarations are metadata, embedded in PDF 2.0 files within the XMP metadata, that assert a document’s conformity with WTPDF 1.0 requirements for accessibility or content reuse. Developed by the PDF Association, these declarations allow software to identify if a file is optimized for assistive technology (similar to PDF/UA-2) or for structured data extraction.

The title helps users understand the purpose of the document before reading its content. Screen readers and other assistive technologies often announce the title when the PDF is opened.

For example:

“Accessibility Report 2026”
“PDF4WCAG PDF Accessibility Checker”

are significantly more useful than:

“doc.pdf”
“pic001.pdf”

PDF/UA identification metadata

In accessible PDFs, XMP metadata may also contain identification information about conformance standards. There are several mechanisms at work here: one used by PDF/UA, another by WCAG. Both are important, as the document may conform to both PDF/UA and PDF/UA, as the latest LaTeX-generated Tagged PDFs do.

This metadata allows validators and accessibility tools to determine whether the document claims compliance with standards such as: PDF/UA and WCAG.

Additional metadata fields

XMP metadata also may contain valuable document information, including: creation and modification date, author or organization, producer and creator tool, language information.

Metadata provides assistive technologies with an initial description of the document before content navigation begins. Without proper metadata, accessible PDFs lose important semantic and usability information.

What PDF4WCAG checks

PDF4WCAG checks:

• dc:title is present and not empty.
• The PDF/UA or WCAG compliance declarations, if the document is validated against PDF/UA or WCAG profiles respectively. These declarations are recommended, but not mandatory for WCAG.
• The XMP package is properly attached to the document catalog.

Accessible PDFs should contain a meaningful dc:title. More advanced workflows should also include standardized identification metadata and descriptive document properties to support both human users and machine processing systems.