Accessible PDFs: Why Most Fail to Meet Standards

Who is required to comply—and does this also apply to PDFs?

There are two sets of regulations to distinguish between. This article is not legal advice; it explains what is stated in the text of the law.

Private sector: The Accessibility Enhancement Act (BFSG) has been in effect since June 28, 2025, for certain products and services offered to consumers. This includes services in e-commerce, primarily online stores and booking platforms. Micro-enterprises that offer services are exempt: those with fewer than ten employees and an annual turnover or balance sheet total of no more than 2 million euros. A purely B2B website is not covered by the law.

The BFSG does not explicitly mention PDFs. However, in Section 1(4), it excludes “file formats from office applications published before June 28, 2025” from its scope of application. Conversely, there is strong evidence that newer documents are covered, provided they are part of the service—such as product information, contract documents, or order forms. Where exactly the line is drawn has not yet been conclusively clarified. If in doubt, you should discuss this with your legal counsel.

Public Bodies: Government agencies, municipalities, and many of their institutions are subject to EU Directive 2016/2102, the federal BITV 2.0, and state regulations. Documents on their websites are clearly included in this scope. The directive allows an exception for file formats from office applications published before September 23, 2018—but only if they are not used for active administrative procedures. Whether and how this exception applies is regulated differently under federal or state law. An old application form that is still in use today is by no means an legacy document.

What Makes a PDF Accessible

The standard is called PDF/UA (“Universal Accessibility”), standardized as ISO 14289. Part 1 from 2014 is the version commonly used in practice; Part 2 was published in 2024 for PDF 2.0. This standard is based on a few, easily understandable characteristics:

• Tags and structure tree: Headings, paragraphs, lists, and tables are marked up as such. Without tags, a screen reader sees only a sequence of characters.
• Document language: This determines the voice and pronunciation used when the document is read aloud.
• Document title: A meaningful title is specified and displayed in the title bar—instead of the file name scan_0043_final2.pdf.
• Alternative text for images and graphics that convey information.
• Actual text instead of scanned page images.
• Embedded fonts to ensure characters are displayed and read correctly.
• Bookmarks for navigating long documents.
• A logical reading order and sufficient contrast.

Why Most PDFs Fail

The problem rarely lies with the PDF itself; it’s almost always in the process leading up to it.

• Exporting without tags: Word and InDesign can generate tagged PDFs. However, the option must be enabled, and the source document must be built using actual style sheets for headings and lists—not with 14-point bold text.
• “Print as PDF”: The printing process creates an image of the page. Structure, language, and alternative text are lost in the process.
• Scans: A signed document that has been scanned back into a digital file is an image. It does not contain a single letter that assistive technology can read.
• Legacy files: Files from ten or fifteen years ago, created by agencies, print shops, and former colleagues. The source files are often no longer traceable.

On top of that: A PDF looks the same on screen whether it’s tagged or not. The deficiency goes unnoticed by anyone who doesn’t specifically check for it.

What a machine can check—and what it cannot

A large portion of the requirements can be determined automatically. Another portion requires a judgment that only a human can make. The dividing line is important because it determines the value of an audit report.

A clean automated result is therefore a strong indicator, but not a PDF/UA certificate. Conversely, a PDF that fails the automated test is certainly not accessible. This is exactly what makes automated testing so useful for large collections—it serves as a preliminary screening.

Tools for Individual Checks

• PAC (PDF Accessibility Checker) by axes4 in Zurich: free, for Windows, currently available as PAC 2026. Checks against PDF/UA and WCAG and offers a screen reader preview for visual inspection.
• Adobe Acrobat Pro: The built-in accessibility checker identifies technical issues and even points out that certain aspects, such as reading order, need to be checked manually.
• veraPDF: Open-source validator for PDF/A and PDF/UA, also available via the command line. Suitable for anyone who wants to integrate checks into their own workflows.

Hundreds of PDFs: How to Tackle the Workload

Anyone who tries to drag 2,000 files one by one into a validation program will give up after the fiftieth. It makes more sense to follow this sequence:

1. Inventory: Which PDFs exist, where are they located, and which ones are still linked at all? Have the entire collection checked automatically.
2. Prioritize: Based on access counts and importance. The order form and the current price list take precedence over the 2014 trade show report.
3. Delete or replace: Experience shows that a significant portion of the old inventory can simply be discarded. If no one needs it anymore, no one has to fix it.
4. Correct at the source: Fix errors in the Word or InDesign document and re-export; don’t make changes directly in the PDF. Otherwise, the work will be lost in the next version.
5. Offer an HTML alternative: Much of the content is better suited as a standard web page—accessible, searchable, and readable on a smartphone. The PDF then serves only as a print version.
6. Prevent new errors: Check every PDF upon upload. Otherwise, the number of flawed files will grow just as fast as you eliminate them.

Automatic inventory check in TYPO3

For steps 1 and 6, we’ve integrated the check into our TYPO3 extension, nt-ai. It scans all PDFs in the TYPO3 file repository for machine-readable features: tagged PDFs, text layers or scanned pages, document language, title and title display, alternative text, font embedding, and bookmarks.

• A backend module displays a score and the individual findings for each file.
• A nightly run in the TYPO3 Scheduler checks only those files that have been modified.
• If desired, PDFs can be checked in the backend as soon as they are uploaded—either as a warning or to block the upload.
• The documents appear as a separate section in the overall report on the website’s accessibility.
• For PDFs, alternative text suggestions can be generated from the document text. Only this step uses AI; the check itself is pure PHP and incurs no AI costs.

Two real-world examples. In a collection of several thousand PDFs, the automated scan repeatedly found the same few issues: missing language, missing title, and no tags. This is good news, because all three can be corrected at the source with minimal effort. Also: Map-like PDFs with a large number of vector paths can take the analysis an extremely long time. A time limit per file is therefore necessary to prevent a single map from holding up the entire run.

What the extension cannot do is listed in the right-hand column of the table above. It does not replace manual review and does not issue a PDF/UA certificate. It tells you where to start. Learn more on the page AI for TYPO3: Accessibility & Translation.

Conclusion

Accessible PDFs rarely fail due to complex technical issues. They fail because no one pays attention: during export, during upload, or when dealing with legacy content. The most common issues—missing tags, missing language, missing titles—can be detected automatically and quickly resolved at the source. So start by having your existing documents checked automatically, clean them up, and focus your manual review on what really matters: the documents your customers actually need. If you’d like help with this, please contact us.