DEV Community: Julia

PDF Trends 2026: Structure, Tagging, and Conformance of PDFs

Julia — Fri, 02 Oct 2026 12:29:01 +0000

Dual Lab analyzed the complete June 2026 Common Crawl dataset (CC-MAIN-2026-25), comprising 20,578,394 PDF documents.

In the second part of our PDF Trends analysis, we examined the evolution of the median PDF file size over the past 20 years. In this third part, we examine the semantic structure of Tagged PDF documents.

The analysis focuses on three issues:

How many PDFs contain a structure tree, and how large are those trees
Which PDF structure elements are used most frequently
How often do tagged PDFs conform to the structural requirements defined by PDF standards

These issues are extremely important because PDFs are used not only by human readers but also by assistive technologies, search systems, document-processing software, and AI applications.

1. Gradual growth in Tagged PDF adoption

Figure 1. Share of Tagged PDFs, January 2023–June 2026

In the time series analyzed by Dual Lab, the share of PDFs containing a structural tag tree increased by approximately 1.5 percentage points per year.

A significant milestone occurred in July 2025, when the share exceeded 50%.

This indicates that, within the population measured by this time-series analysis, more than half of the PDFs included structural tagging by mid-2025.

The trend shown on Figure 1 indicates gradual adoption of Tagged PDF and greater availability of machine-readable document structures. However, with the current trend we’ll need to wait 10+ years before at least 70% of PDFs would be Tagged.

However, the presence of Tagged PDFs does not guarantee that the structure is correct.

2. How many structure elements do PDFs contain?

The first measure is the distribution of the number of structure elements per document.

Figure 2. Number of structure elements per document

The distribution peaks at 64–127 structure elements, indicating that PDFs with moderately sized structure trees are common in the analyzed dataset. The number of documents decreases toward both very small and very large structure trees.

Figure 2 also shows that about 2% of the documents have an empty structure tree, which indicates that these documents are not correctly tagged.

However, the number of structure elements alone should not be interpreted as a measure of accessibility or quality. A large structure tree can still contain incorrect relationships or invalid parent-child combinations.

Figure 3. Distribution of structure elements per page

As in case of file sizes (see Part 2), Figure 3 illustrates that the number of structure elements has a log-normal distribution.

The distribution shows that pages most commonly contain 32–63 structure elements, followed by 64–127 and 16–31 elements. Pages with very large structured trees are much less common. This indicates that, at the page level, most Tagged PDFs use a moderate number of structural elements, while the distribution has a long tail toward larger structures.

At the lower end we see the documents which most likely have a fictional Tagged structure: 161,081 documents contain no structure elements, while 23,490 contain one element and 72,733 contain 2–3 elements. It is very unlikely that such a small number of elements would correctly represent a content, which has at least several paragraphs of text.

This distribution shows that the presence of a PDF does not automatically imply the presence of a meaningful logical structure.

3. Structure tree depth

Figure 4. Distribution of structure tree depth

Most structure trees have moderate nesting depth, which reflects a typical linear structure of the documents with occasional tables and lists.

The largest group has the nesting depth of 4–7 levels, representing approximately 4.84 million trees. It is followed by 2–3 levels, with approximately 1.80 million, and 8–15 levels, with approximately 1.04 million.

Very deep structures are rare and most likely indicate very special cases. Approximately 39,000 trees fall into the 16–31 range, only 2,541 have a depth of 32–63 levels, 563 have a depth of 64–127 levels, and 308 exceed 128 levels.

4. Accessibility conformance claims

The next analysis examines explicit conformance categories: UA-only, A-only, and UA+A.

Approximately 0.9% of documents are UA-only, 2.25% are A-only, and 0.07% report both UA and A conformance.

Figure 5. Distribution of PDF Accessibility conformance claims

The distribution shows that explicit accessibility-conformance claims represent only a tiny proportion of the analyzed corpus. A-only claims are more common than UA-only claims, while documents reporting both UA and A conformance are comparatively rare. Yet, the fact that less than 1% of analysed PDFs contains PDF/UA conformance claim compared to about 50% of Tagged PDFs indicates that the many PDF producers started generating Tagged PDFs by default, but do not yet care about PDF/UA compliance.

5. PDF/UA-1 and PDF/UA-2

Figure 6. PDF files by PDF/UA flavour

The analysis distinguishes between PDF/UA-1 and PDF/UA-2.

PDF/UA-1 is defined by ISO 14289-1 for PDF 1.7, while PDF/UA-2 is defined by ISO 14289-2 for PDF 2.0.

Approximately 99.3% of the identified PDF/UA files are PDF/UA-1, while approximately 0.3% are PDF/UA-2.

The figure shows a strong dominance of PDF/UA-1 and very limited adoption of PDF/UA-2 in the analyzed dataset.

PDF/A conformance flavours

Figure 7. PDF/A flavours

Figure 7 shows the distribution of PDF/A conformance flavours in the analyzed dataset. PDF/A profiles are designed for long-term preservation and include different conformance levels and versions. The most common profiles in the dataset are PDF/A-1b, PDF/A-1a, PDF/A-3a, and PDF/A-2b.

6. Total occurrences of PDF structure element types. Which structure elements are least used?

Figure 8. Total occurrences of PDF structure element types

Across the analyzed corpus, the most frequently occurring structure element is P (paragraph), with approximately 3.38 billion instances.

It is followed by:

TD (table data cell): approximately 2.46 billion
Span: approximately 1.85 billion
TR: approximately 0.50 billion
LI: approximately 0.21 billion
LBody: approximately 0.21 billion
Sect: approximately 0.18 billion

The distribution is strongly concentrated in a small set of core structure types.This indicates that real-world Tagged PDF documents rely heavily on a relatively small core vocabulary.

The use of specialized elements such as Ruby, Warichu, and BibEntry is almost negligible compared with the most common structure elements.

Zooming to the right side of Figure 8, here is a more detailed view on the least used structure elements.

Figure 9. 20 Less-Frequently Used PDF Structure Element Types

Figure 9 shows 20 less-frequently used structure element types, ranging from Warichu and WT (181 occurrences each) to Form (3,160,795) and H5 (2,961,768).Other elements include BibEntry, Ruby, Index, Annot, BlockQuote, Formula, TOC, Caption, and H6.

The distribution is strongly concentrated among a small set of core structure types.

7. Custom Structure Tags

The analysis also identifies custom structure tags that are mapped to standard structure types. In PDF 2.0, namespaces provide a mechanism for defining additional or domain-specific tag sets.

Figure 10. Custom structure tags by number of documents

The most common custom tags include:

Textbox: approximately 1.51 million documents
Article: approximately 831,000
Story: approximately 804,000
Workbook
Worksheet
Footnote
Slide
NormalParagraphStyle

The prevalence of names such as Textbox, Workbook, Worksheet, Slide, and NormalParagraphStyle is consistent with the influence of word-processing, spreadsheet, presentation, and other document-production software on PDF structure vocabulary.

The important observation is that custom naming does not necessarily indicate richer semantics.

In many cases, the names appear to reflect the terminology used by the producing application.

8. Top20 custom tags when not mapped standard type by docs

Figure 11. Top20 custom tags when not mapped to standard type by docs

The distribution of custom tags shows how frequently PDF documents use non-standard structure types that are not mapped to recognized standard tags. Interestingly, the most common custom tag here is an empty one, which again indicates that something is wrong with the document tagging.

Next most common is TextBox, appearing in 55,733 documents, followed by Artifact (44,333), InlineShape (39,477), and Footnote (35,542). Other frequently observed custom types include Lbody (14,311) - clearly a misprint in one of the implementations, Workbook (13,200), Worksheet (12,658), Strong (11,362), and Article (10,222).

These custom tags with no mapping to the standard PDF tags indicate that Tagged PDF structures are frequently generated using application or workflow specific semantics rather than being consistently mapped to standard PDF structure types.

9. ISO/TS 32005 Violations

ISO/TS 32005:2023 clarifies the rules governing the use of PDF 1.7 and PDF 2.0 structure namespaces in PDF 2.0 documents. The following analysis examines violations of the applicable hierarchical inclusion rules in the analyzed PDF population. The analysis includes only documents for which the ISO/TS 32005 rules are applicable.

Figure 12. Top 20 Failed Rules Under ISO/TS 32005 by Number of Documents

The most frequently affected rule is StructTreeRoot-P, affecting approximately 1.6 million documents. This failed rule means that the document has the P (paragraph) tag as a direct child of the Structure tree root, which is not permitted according to either ISO 32005 or PDF 1.7.

It is followed by:

StructTreeRoot-Figure: approximately 1.1 million
StructTreeRoot-Table: approximately 0.95 million
TR-SPan: approximately 0.86 million

Other frequently failed rules affect hundreds of thousands of documents.

Conclusions

The analysis of more than 20.5 million PDF documents shows increasing adoption of structural tagging, while the quality and validity of that structure remain inconsistent.

The key findings are:

Structure trees are common but highly variable in size.
64–127 structure elements is the most frequent range in the analyzed distribution.
A small core vocabulary accounts for most structure-element occurrences.
Most structure trees have moderate nesting depth.
The share of tagged PDFs has exceeded 50% in the analyzed time series since mid-2025 and continues growing by ~1.5% per year.
Explicit conformance claims remain uncommon. PDF/A is more common than PDF/UA. PDF/UA-1 remains far more prevalent than PDF/UA-2.
Millions of documents contain violations of ISO/TS 32005 schema.
Custom tags frequently reflect producer-specific naming conventions.

Tagging a PDF is not the same as creating a well-structured PDF.

The presence of a structure tree is an important foundation, but it is only the beginning. For accessibility, reuse, automated processing, and AI, the structure must also be meaningful, correctly organized, and conformant with the applicable standards.

As PDF documents increasingly become inputs for machines as well as humans, structure quality will become as important as visual quality.

PDF4WCAG Human Checks: what is covered?

Julia — Mon, 28 Sep 2026 14:55:15 +0000

Automated PDF accessibility validation can check many technical requirements, but some accessibility questions require a different type of analysis: does the existing PDF structure actually match what a user sees and understands in the document?

PDF accessibility cannot always be evaluated by checking whether the required tags are present. A PDF may contain a Structure Tree, but the tags can still be inappropriate for the content they represent.

The WCAG 2.2 Human profile in PDF4WCAG adds checks that look at the relationship between the visual presentation of a PDF and its existing semantic structure. PDF4WCAG performs Document Layout Analysis independently of the existing Structure Tree and then compares the results. This approach is used for what PDF4WCAG calls semantic validation.

Semantic validation of existing structure tree

A Structure Tree describes the semantic structure of a tagged PDF. However, tags can be present but used incorrectly.

For example:

a heading can be tagged as <P>;
a paragraph can be tagged as <H> or <H1>;

PDF4WCAG performs layout analysis and compares the detected content type with the structure element in the PDF. This makes it possible to identify potential semantic mismatches, such as a heading incorrectly tagged as a paragraph or a paragraph incorrectly tagged as a heading.

The Human profile includes checks for <P>, <Span>, headings, lists, tables, captions, and other structural elements.

The important point is that the existence of a Structure Tree does not by itself prove that the structure is semantically correct.

Missing inline semantics

Semantic information can also exist inside a paragraph or another text element.

For example, a document may use:

underlined text;
highlighted text;
a different font;
a different font style;
a different color.

These visual differences can indicate additional meaning. If that meaning is not represented in the Structure Tree, the semantic information may not be available in the same way as assistive technologies.

PDF4WCAG checks for underlined text outside the link context and for text with a visually different presentation that may require an appropriate inline semantic element such as Span.

Table of Contents correctness

A Table of Contents has both visual and navigational information. It is therefore not enough to check that the TOC looks correct. PDF4WCAG Human Checks examine whether TOC items correspond correctly to the document and their navigation destinations.

The checks include:

TOC item text that cannot be found in the document;
TOC item text that is not found on the destination page;
missing interactive links;
incorrect page numbers;
inconsistent TOC numbering;
TOC items pointing to the wrong page.

Empty structure elements

PDF4WCAG also detects empty structure elements that may not provide useful content. The Human validation profile includes checks for empty structural elements such as:

<Title>
<P>
<H>
<H1>–<H6>
<Span>
<TOCI>

Empty paragraphs, headings, and TOC items can create unnecessary structure and may affect how content is interpreted by assistive technologies. PDF4WCAG also documents non-empty structure checks as part of its WCAG validation.

Meaningful descriptions for links

A link should give users enough information to understand its purpose. For example, a link labelled “Click here” provides little information when a user navigates through links without the surrounding visual context. PDF4WCAG checks link descriptions against the WCAG requirement for link purpose and looks for meaningful, descriptive link text rather than generic descriptions.

Repeated spaces used for formatting

Another Human Check looks for repeated space characters used to create visual formatting. Multiple spaces may create visual alignment on the page, but spaces do not provide a semantic relationship between the labels and their values.

This is an example of the difference between visual presentation and document structure. What looks aligned to a person may not have an equivalent semantic representation in the PDF.

Human checks are heuristic-based, not a replacement for human review

PDF4WCAG describes the WCAG 2.2 Machine & Human profile as an experimental heuristic implementation of human checks. The purpose is to identify potential problems that can benefit from human attention. The layout analysis does not turn a visual interpretation into an automatic accessibility decision.

Instead, it provides another layer of evidence:

Machine validation - checks formal, algorithmic requirements

Document layout analysis - analyzes the visual organization independently

Comparison with structure tree - identifies potential semantic inconsistencies

Human review - evaluates the result in context

Conclusion

The PDF4WCAG WCAG 2.2 Human profile currently covers several areas where the relationship between visual presentation and semantic structure is important:

Semantic appropriateness of existing tags
Missing inline semantics
Table of Contents correctness
Empty structure elements
Meaningful link descriptions
Repeated spaces used for formatting

Together, these checks add another layer to PDF accessibility validation: machine-verifiable rules check the technical structure, while the layout analysis helps examine whether that structure corresponds to the document as it is visually presented.

How can AI help PDF?

Julia — Thu, 17 Sep 2026 13:09:00 +0000

PDF is widely used for research papers, reports, manuals, contracts, and other documents. When PDFs become input for AI systems, the question is not only how text is extracted, but also whether the document's visual and semantic structure is preserved.

This is particularly important for PDF accessibility. PDF/UA and WCAG define accessibility requirements, while the Matterhorn Protocol describes many machine-checkable PDF/UA conditions. However, some accessibility checks require understanding the document's visual organization and comparing it with its semantic structure. This is where PDF4WCAG uses AI to support human-oriented accessibility checks.

The article Is PDF a Problem for AI provides an important starting point: PDF itself is not inherently unsuitable for AI. The challenge is that a PDF can contain different layers of information, while an AI ingestion pipeline may preserve some and discard others.

PDF is more than extracted text

PDF is a page-oriented document format designed to preserve content and appearance across systems. Its visual representation does not necessarily describe the semantic role of every element.

A heading may look like a heading to a human but have no corresponding heading tag. A list may appear visually as a list while being represented as ordinary paragraphs. A table may be visually clear but have an incorrect or missing structural representation.

Tagged PDF can provide machine-readable information about headings, paragraphs, lists, tables, figures, reading order, language, and alternative text. However, the presence of a Structure Tree does not guarantee that it correctly represents the document. Tags can be incomplete or incorrectly assigned.

Why Human checks are important

Machine-verifiable rules can check many technical accessibility requirements, but some checks require interpretation of the document's visual organization.

A human reviewer can recognize that:

a large text block is a heading;
several lines form a list;
a group of cells forms a table;
an image is associated with surrounding content;
columns have a particular reading order;
an element belongs to a specific logical section.

Complex layouts make this interpretation more difficult. Multi-column pages, tables, footnotes, sidebars, figures, and content extending across page boundaries can require analysis beyond simple text extraction.

How PDF4WCAG uses AI

PDF4WCAG uses AI for document layout analysis (DLA) to support human-oriented accessibility checks.

The AI analyzes the visual organization of a PDF and identifies elements that appear to correspond to document structure. PDF4WCAG then compares the AI analysis with the existing Structure Tree.

For example, if the visual analysis identifies an apparent heading, paragraph, list, table, or other structural element, PDF4WCAG can compare that result with the corresponding structure in the PDF.

This comparison helps identify potential inconsistencies between the visual layout of the document and its encoded semantic structure.

The process can therefore support part of the analysis normally performed during a human accessibility review: examining the document's visual organization and comparing it with its machine-readable structure.

AI-assisted checks cannot replace Human review

AI analysis does not constitute a formal accessibility-conformance decision and does not replace human judgment. Its role is to help identify potential issues that may require further review.

This is relevant because the size or presence of a Structure Tree alone does not indicate its quality. Dual Lab's analysis of 20,578,394 PDFs found that structure trees are widespread, while large structure trees can still contain incorrect relationships or invalid parent-child combinations.

Tagged PDF is not automatically a correctly structured PDF.

Conclusion

PDF is not inherently a problem for AI. The structure of a PDF needs to correspond to the content and organization presented to the user.

PDF4WCAG uses AI for document layout analysis and comparison with the existing Structure Tree. This provides additional evidence for human-oriented accessibility checks and helps identify potential inconsistencies between visual layout and semantic structure.

The purpose is to use AI to support the analysis of PDF accessibility, particularly where understanding the document's visual organization is required.

https://pdf4wcag.com/company/

info@pdf4wcag.com

Is PDF a problem for AI?

Julia — Thu, 10 Sep 2026 06:10:18 +0000

Boris Doubrov, CEO of Dual Lab sprl, has written the article exploring the relationship between PDF and AI for the PDF Association.

Every organization relies on documents: contracts, financial reports, research papers, compliance filings, insurance policies, technical manuals, and government records. Many of these documents are PDFs.

But what happens when these documents become input for AI?

An AI system may have access to a PDF, but it does not necessarily receive all the information contained in it. During ingestion, a document can be reduced to plain text, processed with OCR, analyzed page by page, or converted to Markdown. Tables can lose their relationships, reading order can change, annotations can disappear, and metadata or semantic structure can be ignored.

The result is a gap between what the PDF contains and what the AI system actually understands.

This is the real PDF problem for AI.

But there is an important distinction: PDF itself is not inherently a bad format for AI. The problem is often the way PDF is created, interpreted, and ingested.

Why PDF can be challenging for AI

PDF is a page-oriented document format designed to preserve content and appearance across systems. But a standard PDF does not necessarily contain the semantic information that tells a machine what every piece of content means.

This creates several challenges:

Visual structure does not always equal semantic structure: PDF can describe text and graphics as positioned objects, but a visually obvious heading, list, or table is not necessarily represented with its logical meaning. Tagged PDF can provide additional information about logical reading order, headings, lists, tables, language, and alternative text, but not all PDF files are tagged.
Scanned documents may contain no usable text layer.

OCR may be necessary, but it introduces another recognition step and can produce errors.
Complex layouts require interpretation.

Multi-column pages, tables, footnotes, sidebars, figures, and content spanning page boundaries can be difficult to reconstruct from raw text.
Text encoding can create problems.

Poor Unicode mappings or malformed PDFs can make otherwise visible text difficult to extract reliably.
More than visual rendering.

PDF also contains metadata, bookmarks, digital signatures, attachments and other supplementary information which may be crucial for a user workflow, but is often ignored by AI.

So PDF is not “unreadable by machines.”

Rather, PDF can contain several layers of information, and AI systems do not always extract all of them.

The PDF AI actually receives may not be the PDF you created

This is one of the most important points in the PDF Association FAQ.

Different AI systems use different PDF ingestion strategies. Some systems may ignore bookmarks, layers, annotations, metadata, or Structure Tree. Others may apply OCR even when the PDF already contains extractable text. Some reduce the entire document to a stream of plain text.

If the ingestion pipeline extracts only visible characters, the AI receives only a part of the document. That means two AI systems can receive the same PDF but effectively process different documents.

This can explain why one AI tool answers a question correctly while another misses a table, misunderstands reading order, or produces an incorrect answer.

Tagged PDF can give AI a structural advantage

Tagged PDF gives AI important structural information, including headings, paragraphs, lists, tables, and figures. However, a structure tree does not guarantee perfect semantics; tags can be incomplete or incorrect.

This is similar to HTML, where semantic structure may also require additional technologies and guidance such as WAI-ARIA and WCAG. In PDF, standards such as WTPDF and PDF/UA provide additional requirements for the quality of structured and accessible PDF documents.

Still, the fact that PDF creators added Tagged structure is a step forward and provides a potential source of valuable information for AI.

OCR is not the universal solution

A common PDF-to-AI pipeline looks like this:

PDF → OCR → text → LLM

But, as the PDF Association says in its FAQ, not every PDF needs OCR.

Most born-digital PDFs already contain extractable text. For these documents, native text extraction is generally preferable to OCR. OCR is slower, more costly, and can introduce recognition errors. It also recovers only visible text and does not replace other PDF information such as annotations, metadata, semantic structure, or embedded content.

Native PDF extraction can also access information that OCR cannot reliably recover, including intended Unicode mappings, intended textual representations of images (ActualText), and text contained in annotations or other non-page content.

OCR remains important for scanned documents and situations where PDF text cannot be reliably extracted.

A better workflow is therefore:

Detect → Extract native content → Analyze → OCR only when necessary

OCR should be a fallback, not an automatic first step.

Converting PDF to Markdown is not always better

Another popular workflow is:

PDF → Markdown → LLM

Markdown is easy for developers and language models, but converting every PDF into Markdown can be counterproductive.

The PDF Association describes conversion to simpler formats as potentially lossy because PDF contains features that do not have direct equivalents in Markdown or HTML. Complex tables, merged cells, digital signatures, layers, annotations, and other semantics can be simplified or lost during conversion.

For a simple document, Markdown may be an excellent intermediate representation. But for a complex PDF, less structure does not necessarily mean better AI understanding.

The goal should not be to make the document as simple as possible. The goal should be to create a machine-readable representation while preserving meaningful information and relationships.

Page-by-Page processing can lose context

PDF is paginated, but the logical document is not necessarily organized around pages.

A sentence can continue onto the next page, or even several pages ahead. A table can span several pages, both vertically and horizontally. A heading can appear at the bottom of one page while its content begins on another.

The PDF Association therefore advises against treating each PDF page as an independent AI input. Page isolation can reduce context and increase the risk of incorrect interpretation.

However, page information remains important for attribution and verification. A good AI system should preserve both logical document structure and physical page references.

This is especially important in RAG systems, where users need to verify where an answer came from.

Metadata, Annotations and Attachments Matter

A PDF ingestion system should not automatically discard metadata.

The PDF Association specifically recommends that AI systems make use of PDF metadata because it can contribute context and potentially reduce processing requirements.

Annotations are also important.They can represent comments, markup, links, digital signatures, multimedia, attachments, or proposed changes to document content. Ignoring them can mean ignoring information relevant to the document's context.

Attachments need not be referenced by annotations but are nonetheless part of the document; these must also be considered.

Redaction is a special AI risk

There is also an important security issue.

A correctly redacted PDF has the sensitive information removed. But a PDF containing redaction annotations may represent an incomplete redaction workflow; the underlying information may still exist in the file. A PDF may also contain other types of annotations that mask (but do not remove) text; a very common type of redaction failure.

An AI system processing such a file could potentially ingest information that the author believed had already been removed.

Visual appearance is not the same as document state.

Very large, old, or invalid PDFs create additional challenges

PDF is designed to be backward-compatible, so even very old PDF documents can potentially be processed by modern systems. But malformed, truncated, or corrupted PDFs can behave differently depending on the software used to recover and interpret them. Different AI systems may therefore recover different information from the same damaged file.

AI processing can also be slower for PDFs than for HTML because PDFs are frequently long, multi-page documents. Unnecessary OCR adds additional processing overhead.

This is another reason that PDF-aware preprocessing matters.

So, is PDF actually a problem for AI?

Yes but !! not in the way it is usually described.

PDF itself is not inherently unsuitable for AI.

In fact, PDF is valuable precisely because it often contains high-density, long-form, persistent information that organizations need AI to understand.

The real challenge lies in PDF ingestion processes.

If an AI system converts a complex PDF into an incomplete stream of text, it may discard the very information needed to interpret the document correctly.

Conclusion

PDF is not the enemy of AI. PDF should not be automatically OCR-processed or converted into a simpler format just because image recognition is available or Markdown and plain text are easier to process. Such conversion can discard semantics, structure, and context.

The better approach is PDF-aware AI ingestion: preserve native text where available, use structural information such as Tagged PDF, retain relevant metadata and annotations, maintain page references, and use OCR only when necessary.

The goal is not simply to extract text from a PDF but to preserve all information within the document and all relationships that make the document meaningful.

Contact:
info@pdf4wcag.com

pdf4wcag.com

Dual Lab releases PDF4WCAG Accessibility Checker 1.12

Julia — Fri, 04 Sep 2026 05:42:05 +0000

Dual Lab announces the release of PDF4WCAG Accessibility Checker 1.12. The release introduces improvements to accessibility and keyboard navigation, error visualization, validation accuracy, localization to Korean language and application stability.

PDF4WCAG Accessibility Checker is designed to help organizations evaluate PDF documents against PDF/UA, WCAG, and WTPDF accessibility requirements. The solution is powered by the veraPDF validation architecture and provides machine-verifiable checks based on the PDF/UA and WTPDF validation profiles.

What’s new in PDF4WCAG 1.12

Improved accessibility and user experience

Version 1.12 improves the PDF4WCAG interface and makes the application easier to navigate and use.

Key improvements include:

Enhanced accessibility and keyboard navigation.

Better error visualization

PDF4WCAG 1.12 improves the way validation errors are presented and connected to the relevant elements in a PDF.

The release includes:

Improved handling of annotation-related errors, including missing highlights and corresponding properties in the annotation panel.
Support for displaying metadata errors.
Improved highlighting of errors related to missing language identification.

Validation improvements

The new release includes several updates designed to improve the accuracy and consistency of validation results.

Version 1.12:

Fixes reporting for ISO 14289-2:2024 8.2.5.20 (Link annotations targeting different locations)
Fixed LaTeX specific errors in human checks.
Removes selected WCAG rules that are no longer applicable to the validation workflow.

These changes help provide more precise and actionable validation results for PDF accessibility professionals.

Localization updates

PDF4WCAG 1.12 expands localization with the addition of the Korean language.

The release includes:

Korean interface translations.
Korean translations for validation error messages.
Support of CJK fonts in PDF reports.
Translated documentation.

The localization updates make PDF accessibility testing more accessible to Korean-speaking users and organizations.

Application improvements

Additional application improvements include:

Improved veraPDF log and warning reporting to users.
Updated and clarified error messages.
Improvements to the verapdf-js-viewer documentation.
Improved session management.

Supporting PDF accessibility and compliance

The combination of machine-verifiable validation, detailed error reporting, and an interactive interface helps accessibility teams, developers, document creators, and compliance professionals identify and address PDF accessibility problems more efficiently.

PDF4WCAG 1.12 continues Dual Lab’s focus on making PDF accessibility validation more accurate, transparent, and practical for organizations working toward PDF/UA, WCAG, and WTPDF compliance.

Contact us:

pdf4wcag.com

info@duallab.com

info@pdf4wcag.com

Dual Lab releases PDF4WCAG Accessibility Checker 1.12

Julia — Wed, 02 Sep 2026 11:15:55 +0000

What’s new in PDF4WCAG 1.12

Improved accessibility and user experience

Version 1.12 improves the PDF4WCAG interface and makes the application easier to navigate and use.

Key improvements include:

Enhanced accessibility and keyboard navigation.

Better error visualization

PDF4WCAG 1.12 improves the way validation errors are presented and connected to the relevant elements in a PDF.

The release includes:

Improved handling of annotation-related errors, including missing highlights and corresponding properties in the annotation panel.
Support for displaying metadata errors.
Improved highlighting of errors related to missing language identification.

Validation improvements

The new release includes several updates designed to improve the accuracy and consistency of validation results.

Version 1.12:

Fixes reporting for ISO 14289-2:2024 8.2.5.20 (Link annotations targeting different locations)
Fixed LaTeX specific errors in human checks.
Removes selected WCAG rules that are no longer applicable to the validation workflow.

These changes help provide more precise and actionable validation results for PDF accessibility professionals.

Localization updates

PDF4WCAG 1.12 expands localization with the addition of the Korean language.

The release includes:

Korean interface translations.
Korean translations for validation error messages.
Support of CJK fonts in PDF reports.
Translated documentation.

The localization updates make PDF accessibility testing more accessible to Korean-speaking users and organizations.

Application improvements

Additional application improvements include:

Improved veraPDF log and warning reporting to users.
Updated and clarified error messages.
Improvements to the verapdf-js-viewer documentation.
Improved session management.

Supporting PDF accessibility and compliance

Contact us:

pdf4wcag.com

info@duallab.com

info@pdf4wcag.com

Analysis of PDF file size for 2006-2025 by Dual Lab

Julia — Fri, 21 Aug 2026 07:55:59 +0000

Analysis of PDF file size for 2006-2025 by Dual Lab

Dual Lab analyzed the complete June 2026 Common Crawl dataset (CC-MAIN-2026-25), comprising 20,578,394 PDF documents. In the second part of the analysis we analyze the evolution of the median PDF file size over the past 20 years.

Executive Summary

One of the reasons for the ongoing development of the Brotli compression in PDF format is the growing size of modern documents. It would be reasonable to assume, therefore, that PDF files are growing substantially larger. However, our analysis indicates otherwise.

Brotli compression has been introduced into the PDF specification to improve compression efficiency and reduce file sizes, particularly for modern workflows that embed large amounts of data and resources.

Despite these technological advances, our analysis tells a different story about the actual size of PDF documents published on the web.

This publication in no way diminishes the importance of Brotli. We fully recognize its value, while noting that PDF archive sizes remain an important consideration for storage, transfer, and processing efficiency.

Use median instead of arithmetic mean

Because PDF file sizes span several orders of magnitude, the arithmetic mean can be strongly affected by a relatively small number of exceptionally large files.

Figure 1 below compares the mean with the median file size per each month for the past 20 years. It shows that the monthly mean is roughly 3-5 times the median for much of the period. More importantly, the mean has large isolated excursions, most dramatically around 2012-2013, where it jumps to almost 5 MiB, while the median hardly reacts.

Figure 1. Arithmetic mean versus median

Figure 2 quantifies this particularly well: the largest 1% of PDFs account for roughly 25-35% of all bytes in a typical month, with occasional values around 40%. One percent of observations contributing around one third of the quantity being averaged means the arithmetic mean is inherently highly sensitive to that 1%.

Figure 2. Share of largest 1% of PDFs

To account for the skewed distribution and the influence of outliers, we complement the mean with the median, 25th–75th percentiles (interquartile range), and 10th–90th percentiles. This combination distinguishes changes in the overall average file size from changes in the size of a typical PDF.

Use Logarithmic scale for PDF File sizes

PDF document sizes vary by several orders of magnitude, from small text documents to publications containing thousands of pages and high-resolution images. To understand this distribution, Figure 3 presents PDF file sizes using exponentially increasing bins (powers of two).

Figure 3. Size of PDF files

Using powers of 2 for the bins reveals an approximately log-normal distribution, making logarithmic scales more suitable than linear ones for analyzing PDF file sizes. Since file sizes grow multiplicatively, this approach provides a more accurate view of the distribution across the full range of document sizes.

This again reconfirms the reason why we use the mean to examine overall changes in average file size, and the median and quartiles to assess long-term changes in typical PDF size.

Evolution of monthly median and quartiles

Based on the above reasons, we perform long term analysis of the median file size together with the 25th–75th percentiles (interquartile range).

Figure 4. Monthly PDF file size distribution

Figure 4 shows the monthly evolution of PDF file sizes over the past 20 years using the median and the 25-75 quartiles on a logarithmic scale. The median and interquartile range provide a more robust representation of typical PDF sizes and their variation over time.

Use quadratic regression instead of linear

Figure 4 suggests that the growth in median PDF file size is nonlinear. The increase was most pronounced between 2006 and 2016, after which the trend gradually flattened and even showed a slight decline in recent years. To model this behavior more accurately, we fitted a quadratic regression using the formula

log_median ~ years + years^2

The standard regression analysis shows that both the linear and quadratic terms are highly statistically significant (p < 0.001), confirming that the evolution of PDF file sizes cannot be adequately described by a simple linear trend. The regression results are presented in Figure 5.

Figure 5. Regression results

Figure 6 illustrates the monthly median PDF file size together with the fitted quadratic trend. The gray line shows the observed monthly median values, while the blue curve represents the fitted regression model.

Despite noticeable month-to-month variation, the long-term trend is clear. The monthly median PDF file size increased steadily from approximately 0.20 MB in 2006 to just over 0.40 MB around 2021–2022, after which the trend leveled off and began to decline slightly. This suggests that the continuous growth in PDF file sizes observed over the previous decade has slowed, indicating that the typical size of PDF documents published on the web has stabilized in recent years.

Figure 6. Trends in PDF file-size median

Annual growth of median file size in values (percentage)

The quadratic regression model also reveals a clear slowdown in the annual growth of median PDF file size. The median increased by approximately 9.2% between 2006 and 2007, but the annual growth rate gradually declined over time, falling below 1% by 2020–2021. Since 2022, the trend has become slightly negative, indicating that the median PDF file size has stabilized and is beginning to decrease modestly. These results suggest that the long-term growth in PDF file sizes observed during the 2000s and 2010s has largely reached a plateau.

Annual increase of median file size (percentage):

2006-2007: 9.21%
2007-2008: 8.59%
2008-2009: 7.97%
2009-2010: 7.36%
2010-2011: 6.75%
2011-2012: 6.14%
2012-2013: 5.54%
2013-2014: 4.94%
2014-2015: 4.34%
2015-2016: 3.75%
2016-2017: 3.16%
2017-2018: 2.57%
2018-2019: 1.99%
2019-2020: 1.41%
2020-2021: 0.83%
2021-2022: 0.26%
2022-2023: -0.31%
2023-2024: -0.88%
2024-2025: -1.44%
2025-2026: -2.00%

Median file size of Tagged vs. Untagged PDFs

During the reserch we have analyzed the median file size of Tagged versus Untagged PDFs. Initial guess was that Tagged PDFs should be larger in average, as PDF structure tree adds more objects to the document. However, this turned completely wrong! Figure 7 shows that Tagged PDFs are systematically smaller than Untagged ones.

Figure 7. Tagged vs Untagged PDFs

To be absolutely sure, we applied the Wilcoxon signed-rank test, a non‑parametric statistical test, which shows statistically significant difference in median file sizes between tagged and untagged PDFs per month (P-value = 1.65875e-13).

It is not clear why Tagged PDFs turn out to be smaller in average. One of the conjectures is that Tagged PDFs are mostly digitally born and do not include scanned files, which tend to be larger. We shall analyze this conjecture in the next parts of our analysis report.

Conclusions

Analysis of more than 20.5 million PDF documents from June 2026 Common Crawl collection leads to several key findings.

PDF file sizes follow an approximately log-normal distribution, making logarithmic visualization and median-based statistics more appropriate than arithmetic averages.
Median file size increased steadily until approximately 2021, after which growth flattened and became slightly negative.
Quadratic regression confirms that this slowdown is highly statistically significant.
The evidence suggests that the typical PDF published on the web has not become substantially larger over time.
Despite initial guesses, Tagged PDFs turn out to be smaller in average than Untagged ones.

These findings demonstrate the value of large-scale empirical analysis. Although technologies such as Brotli address the needs of increasingly sophisticated PDF documents, the overall characteristics of publicly available PDFs have remained remarkably stable.

In the next parts of our PDF analysis we shall discuss distribution of PDFs by Producer and the statistics on the use of structure elements and the validity of the structure tree against schemas defined in PDF standards.
Contact us : info@duallab.com

Website:

https://pdf4wcag.com/company/

https://duallab.com/

Your LLM is not a PDF parser: use OpenDataLoader first

Julia — Tue, 11 Aug 2026 11:29:53 +0000

Large Language Models (LLMs) have become remarkably powerful at understanding documents. Many modern AI platforms can accept PDF files directly, creating the impression that PDFs are ready-to-use inputs for AI workflows.

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:

import opendataloader_pdf opendataloader_pdf.convert( input_path=["document.pdf"], output_dir="output/", format="json,html,pdf,markdown" )

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.

Contact us

Website: https://opendataloader.org/docs
GitHub: https://github.com/opendataloader-project/opendataloader-pdf

PDF trends 2026Q2 by Dual Lab company

Julia — Mon, 03 Aug 2026 14:38:16 +0000

PDF trends 2026Q2 by Dual Lab company

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.

Structure Tree in PDF4WCAG Accessibility Checker

Julia — Fri, 24 Jul 2026 05:38:50 +0000

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.

The Fonts Panel in PDF4WCAG: supporting PDF accessibility and compliance

Julia — Thu, 16 Jul 2026 13:07:31 +0000

When it comes to PDF accessibility, fonts are far more than a design choice. They are an important technical component that affects how text is represented and interpreted by assistive technologies. One of the key additions in PDF4WCAG Accessibility Checker 1.10 is the new Fonts inspection panel, which provides a detailed analysis of embedded fonts, font types and subsets, and encoding information.

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.

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/

New Annotations Panel in PDF4WCAG

Julia — Thu, 09 Jul 2026 13:00:29 +0000

Annotations are a general mechanism for adding an interactive layer to PDF documents. They include elements such as links, comments, interactive form fields, multimedia, and more. Like all other content, annotations may or may not be accessible. PDF4WCAG checks also cover a number of PDF/UA and WCAG requirements on annotations.

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:

Comments – user notes and markup
Hyperlinks – navigation and reference links
Form controls – interactive form fields
Other interactive elements – additional dynamic content

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.

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.

email: info@pdf4wcag.com

website: https://pdf4wcag.com/

accessibility #pdf #duallab #dev